PAYATHON 2026

POS 如何决定生成 ISO 8583 100 或 200 消息

支付小周

明确结论

POS 不能只根据卡片数据决定发送 0100 还是 0200。消息类型取决于收单机构或支付网络规定的交易处理模型,以及本次交易的类型和状态:

  • 0100(Authorization Request)通常用于“双消息”流程,也就是先授权,再清算。授权成功只代表额度获批,之后还要进行完成、撤销或清算处理。
  • 0200(Financial Transaction Request)通常用于“单消息”流程,一次请求同时表达授权和财务记账。
  • 同一种消费交易,在不同收单行、卡组织、国家、受理环境或终端配置中,可能采用不同的 MTI。
  • POS 是否提示输入 PIN,主要由持卡人验证方法(CVM)的选择结果决定,与使用 0100 还是 0200 没有直接关系。

严格来说,ISO 8583 使用四位 MTI,所以应写成 0100 和 0200。日常交流中的“100 message”和“200 message”通常只是省略了前导零。

0100 与 0200 的选择依据

1. 收单系统采用单消息还是双消息模型

这是首要判断条件。

双消息模型通常分为以下阶段:

  1. POS 或收单系统发送 0100 授权请求。
  2. 发卡方返回 0110。
  3. 交易完成后,商户通过批结算、清算文件或其他 completion/advice 消息提交最终金额。

酒店、租车、自助加油和部分餐饮业务需要先预授权,再确定最终金额,因此经常采用这种模式。

单消息模型通常按以下方式处理:

  1. POS 发送 0200 财务交易请求。
  2. 发卡方或收单主机返回 0210。
  3. 该请求本身已经包含财务记账含义,无须再发送一笔独立的授权请求。

不过,不能据此认为 0200 成功后一定没有后续处理。系统仍可能进行批次汇总、冲正、对账和网络清算,具体流程由收单规范规定。

2. 交易类型

POS 通常先识别业务类型,再按照收单机构的消息映射表选择 MTI。常见业务包括:

  • 普通消费
  • 预授权
  • 预授权完成
  • 退款
  • 现金支取
  • 消费撤销
  • 余额查询
  • 离线交易上送
  • 冲正
  • 技术确认或 advice

交易类型通常还会反映在 Processing Code、功能码或网络私有字段中。仅凭 MTI 无法判断完整的业务含义。

下面的映射只用于说明设计方式,并不是通用标准:

业务可能的消息
预授权0100 / 0110
单消息消费0200 / 0210
冲正0400、0420 或网络定义的其他消息
网络管理0800 / 0810

实际使用的 MTI、Processing Code 和字段组合,必须以所接入收单主机的接口规范为准。

3. 卡产品和受理网络

终端读取卡片后,通常会结合以下信息选择路由和交易规则:

  • PAN 对应的 BIN/IIN
  • EMV Application Identifier(AID)
  • 磁条 Service Code
  • 借记、贷记或预付产品
  • 国内网络或国际卡组织
  • 商户类别码(MCC)
  • 终端能力和受理环境
  • 币种、金额及交易类型
  • 收单机构下发的参数

这些数据可能间接影响消息类型,但其中没有一个全球通用的开关,可以直接决定生成 0100 或 0200。最终仍要应用收单方配置的路由表和接口规则。

4. 终端不一定直接生成最终 ISO 8583 消息

在不少系统架构中,POS 只负责生成终端协议报文,最终的 ISO 8583 消息则由以下组件转换产生:

  • POS gateway
  • 支付中间件
  • 收单前置系统
  • Payment switch
  • Terminal management/payment application

排查消息类型时,应先确认协议边界,弄清楚究竟是 POS 应用直接选择 MTI,还是收单前置系统把 POS 请求映射成 0100 或 0200。

POS 如何决定是否提示输入 PIN

输入 PIN 属于 CVM 决策,与 MTI 没有直接对应关系。0100 和 0200 都可以携带 PIN。

EMV 芯片接触式交易

在接触式 EMV 交易中,终端和卡片共同执行 CVM Processing,主要输入包括:

  • 卡片的 CVM List
  • 终端支持的 CVM 能力
  • 交易金额
  • CVM 金额条件
  • 交易类型
  • 终端类型
  • 发卡方在卡片中配置的规则
  • 前一次 CVM 失败后的回退规则

CVM List 可能包含:

  • Offline plaintext PIN
  • Offline enciphered PIN
  • Online PIN
  • Signature
  • No CVM
  • Fail CVM processing

终端按照 EMV 规则,从中选择第一个满足条件且卡片和终端都支持的方法。只有选择结果为 Online PIN 或 Offline PIN 时,才应显示 PIN 输入界面。

Offline PIN 由芯片卡验证,通常不会将 PIN Block 发送给发卡方。Online PIN 则要由安全 PIN Pad 生成加密 PIN Block,再通过收单网络发送。

非接触式交易

非接触式交易还要遵循所选卡组织内核的规则,涉及:

  • Reader CVM Required Limit
  • 交易金额
  • Consumer Device CVM(CDCVM)
  • Online PIN
  • Signature
  • No CVM
  • 设备和内核支持能力

手机钱包已经完成 CDCVM,例如通过设备解锁或生物识别完成验证,并不代表 POS 还要提示输入 PIN。最终处理结果应由对应的非接触内核和网络规则确定,不能只看交易金额。

磁条交易

磁条没有 EMV CVM List。是否要求 Online PIN,通常取决于:

  • 磁条 Service Code
  • 卡产品及交易网络
  • 借记路由规则
  • 终端 PIN 能力
  • 金额或交易类型
  • 收单机构参数
  • 当地监管及网络规定

Service Code 只是规则输入之一,不能单独用来证明交易一定需要或不需要 PIN。

手工输入和无卡交易

手工输入 PAN、邮购、电话订购或其他 Card-Not-Present 场景,通常不使用实体卡 PIN,而是采用支付网络规定的其他验证和风险控制机制。具体要求取决于交易渠道和卡组织规范。

推荐的实现步骤

1. 将业务决策与报文组包分开

先生成规范化的交易上下文:

TransactionContext
├── transactionType
├── amount
├── currency
├── entryMode
├── selectedAID
├── cardProduct
├── cvmResult
├── terminalCapabilities
├── acquirerProfile
└── routingNetwork

再分别完成以下处理:

  1. 选择路由和处理模型。
  2. 执行 CVM 处理。
  3. 映射 MTI 与 Processing Code。
  4. 组装 ISO 8583 字段。
  5. 校验字段组合和安全要求。

不要在业务代码中直接写死“金额超过某值就发送 0100”或“借记卡就发送 0200”,除非收单规范明确要求这样处理。

2. 使用可配置的收单配置文件

以下伪代码只用于说明结构,具体值必须替换成实际收单规范中的定义:

ProcessingModel model =
    acquirerProfile.resolveProcessingModel(
        transaction.getType(),
        transaction.getEntryMode(),
        transaction.getSelectedAid(),
        transaction.getRoutingNetwork()
    );

String mti;

switch (model) {
    case DUAL_MESSAGE_AUTHORIZATION:
        mti = "0100";
        break;

    case SINGLE_MESSAGE_FINANCIAL:
        mti = "0200";
        break;

    default:
        throw new UnsupportedOperationException(
            "No ISO 8583 processing model configured for this transaction"
        );
}

String processingCode =
    acquirerProfile.resolveProcessingCode(transaction.getType());

IsoMessage message = new IsoMessage(mti);
message.setField(3, processingCode);
message.setField(4, formatAmount(transaction.getAmount()));
message.setField(22, buildPosEntryMode(transaction));
message.setField(25, resolvePosConditionCode(transaction));

不同 ISO 8583 版本和网络实现使用的字段编号可能不同。即使字段编号相同,编码、长度和业务含义也可能经过网络规范扩展。

3. 让 EMV 内核返回 CVM 结果

POS 应直接使用内核输出,不要自行重新推导 EMV CVM:

CvmResult cvm = emvKernel.performCvmProcessing(
    cardData,
    terminalCapabilities,
    transaction.getAmount(),
    transaction.getType()
);

switch (cvm.getMethod()) {
    case ONLINE_PIN:
        EncryptedPinBlock pinBlock =
            securePinPad.captureOnlinePin(cardData.getPan());
        transaction.setEncryptedPinBlock(pinBlock);
        break;

    case OFFLINE_PLAINTEXT_PIN:
    case OFFLINE_ENCIPHERED_PIN:
        securePinPad.performOfflinePinVerification(cvm);
        break;

    case SIGNATURE:
        ui.requestSignature();
        break;

    case CDCVM:
    case NO_CVM:
        break;

    case CVM_FAILED:
        declineOrContinueAccordingToKernelResult();
        break;
}

这段代码同样只是结构示例。在生产系统中,明文 PIN 不应进入普通应用的内存、日志或调试输出。PIN 捕获、PIN Block 生成和密钥处理都应在通过认证的安全设备中完成。

4. 正确填写 CVM 和终端数据

EMV 交易通常需要把内核生成的数据写入 ISO 8583 的芯片数据字段,例如网络常用的 ICC/System Related Data 字段。相关数据可能包括:

  • Terminal Verification Results(TVR)
  • Transaction Status Information(TSI)
  • Cardholder Verification Method Results(CVM Results)
  • Cryptogram Information Data(CID)
  • Application Cryptogram
  • Terminal Capabilities
  • Amount、currency、transaction date
  • Unpredictable Number

具体的 TLV 标签、ISO 字段位置和封装方式由收单机构或卡组织的接口规范规定,不能假定所有网络都采用相同的 Field 55 格式。

容易出错的地方

不要根据 PIN 判断 MTI

“需要 PIN,所以发送 0200”没有通用依据。PIN 是持卡人验证方式,MTI 描述消息功能,两者是不同的维度。

不要把授权成功当作交易一定完成

0110 返回批准,通常只代表授权已经获批。在双消息流程中,仍要按照规范完成 capture、completion、clearing 或批结算,否则可能出现额度已经占用,但商户没有完成请款的情况。

超时后不要盲目重发

支付请求超时并不代表原请求没有被主机处理。POS 应按规范使用唯一的 STAN、RRN、终端流水号和冲正机制。直接换一个新流水号重发,可能造成重复扣款。

PIN 数据必须按安全规范处理

Online PIN 通常以加密 PIN Block 的形式传输。实际格式可能采用 ISO 9564 定义的格式,也可能使用支付网络指定的格式,并受 PCI PIN、密钥管理和硬件安全模块要求约束。系统不能记录明文 PIN,也不应在普通软件中自行实现 PIN 加密。

“ISO 8583 兼容”不等于能够直接互联

ISO 8583 只提供消息结构框架。要实现真正的互联,双方还要对以下内容达成一致:

  • ISO 8583 版本
  • 位图格式
  • 字段定义和编码
  • ASCII、EBCDIC、BCD 或二进制编码
  • 变长字段长度头
  • TPDU 或网络头
  • MAC 算法和密钥体系
  • Processing Code
  • 响应码
  • 冲正、重发和对账规则
  • EMV TLV 封装方式
  • 网络私有字段

因此,实现时最需要依据的并不是一份通用的 ISO 8583 字段表,而是收单机构提供的 Host Interface Specification 和终端认证测试案例。

可参考的规范

建议按照以下优先级获取资料:

  1. 收单机构或支付处理商的 POS/Host Interface Specification
    这是确定 0100、0200、Processing Code、字段编码、超时和冲正规则的直接依据。

  2. ISO 8583
    用于理解金融交易卡消息中的 MTI、位图和数据元素框架。不同网络可能采用 ISO 8583

    、1993、2003 或私有变体,需要确认实际版本。

  3. EMV Integrated Circuit Card Specifications for Payment Systems
    接触式芯片交易主要参考:

    • Book 3:Application Specification
    • Book 4:Cardholder, Attendant, and Acquirer Interface Requirements
  4. EMV Contactless Specifications 和对应支付网络内核规范
    用于确认非接触式交易中的 CVM Limit、Online PIN、No CVM 和 CDCVM 规则。

  5. ISO 9564
    用于了解 PIN 管理和 PIN Block 的标准框架。实际使用的格式仍要遵循收单网络的要求。

  6. PCI PIN Security Requirements 与 PCI PTS POI Requirements
    用于确定 PIN 处理、密钥管理和 PIN 输入设备的安全要求。

  7. 具体卡组织或国内支付网络规范
    Visa、Mastercard、银联及其他支付网络都有各自的消息接口、EMV 数据和终端认证要求。这些资料通常需要通过收单机构、会员门户或认证项目获取。

最终可执行的判断规则,应由“交易类型 + 受理网络 + 收单配置 + EMV/CVM 结果”共同决定,不能只根据卡号、金额或是否输入 PIN 来推导。

备注:内容仅供参考。