引言

如果把支付世界按”谁在清算”切一刀，卡组织（Card Scheme）网络是最古老、也是目前规模最大的一块。截至 2025 年底，全球 Visa、Mastercard、银联（UnionPay）、American Express、JCB、Discover 六大卡组织年处理交易笔数超过 6000 亿笔，单日峰值（如美国黑色星期五、中国双十一）可达 10 亿笔级别。一笔看似只有 3 秒钟的 POS 刷卡，背后要穿越至少 5 个系统、走完 6 个阶段、满足数十条 ISO 标准与 PCI 合规条款。

这一篇我们把这条链路”解剖”给你看：从 POS 机读芯片的那一刻起，一笔 ISO 8583 报文是怎样在收单行、卡组织交换网络（VisaNet、Banknet、CUPS）、发卡行核心之间打一个来回；又怎样在 T+1 凌晨被批处理成清算文件、在央行大额系统完成资金净额结算；最后在 120 天窗口内可能经历 Chargeback 再杀一个回马枪。在本系列 《支付系统全景》 已经把支付生态画成一张全景图，本文则聚焦”卡”这条最复杂、标准化程度也最高的路径。

读者画像：支付网关研发、收单系统接入工程师、卡组织认证工程师、风控/对账系统开发者、以及所有和”发卡行/收单行/Scheme”三方打过交道还一头雾水的同学。我们不会堆合规条款，而是把”协议字段 ↔︎ 业务语义 ↔︎ 工程坑”三层打通。

在进入正题前，先用两个数字标定这套系统的边界：

• 延迟预算：商户希望持卡人点击”支付”到收到响应 < 3 秒；去掉前端渲染、Scheme 网络两段，真正留给收单 Processor + Scheme + 发卡行的处理时间通常 < 1.2 秒，其中发卡行核心耗时多在 400–800 ms。这迫使授权链路的每一跳都要做极致优化：连接池预热、二进制编码、HSM 旁路、风控异步化。
• 可用性预算：一家中等收单每年 0.01% 不可用（≈ 53 分钟）就会导致数千万元损失。Visa/Mastercard 的 SLA 对接入方是 99.99%，银联为 99.995%。这意味着 Scheme 端做不到”完美可用”，收单和发卡都必须设计 STIP（Stand-In）和本地降级。

卡组织链路还有一个反直觉的特点：它是”先 commit 后持久化”的系统。授权阶段发卡行只”预扣”额度，资金真正转移要等 24–72 小时后的清算与结算。这让整个链路在 T 到 T+2 的窗口内同时存在”已承诺但未结算”的多份真相，工程上必须显式建模这个时间轴，否则对账永远对不上。

一、参与方与角色

1.1 四方模型与三方模型

卡组织收单有两种经典模型：

• 四方模型（Four-Party Model）：持卡人（Cardholder）、商户（Merchant）、收单行（Acquirer）、发卡行（Issuer），中间由卡组织（Scheme）承担交换网络。Visa、Mastercard、银联、JCB 都属于这一类。收益由 Interchange Fee（发卡行收取）、Scheme Fee（卡组织收取）、Acquirer Markup（收单行收取）三段组成，形成俗称 MDR（Merchant Discount Rate）的商户手续费。
• 三方模型（Three-Party Model）：American Express、Discover 自己既发卡又收单，无独立 Scheme，收益内化。现在 Amex 也开了部分银行作为发卡行、合作收单机构，边界在模糊。

flowchart LR
    CH[持卡人 Cardholder] -->|刷卡/NFC/在线| M[商户 Merchant]
    M --> PG[支付网关/POS Processor]
    PG --> ACQ[收单行 Acquirer]
    ACQ --> SCH[卡组织 Scheme<br/>VisaNet / Banknet / CUPS]
    SCH --> ISS[发卡行 Issuer]
    ISS -->|授权响应| SCH
    SCH -->|授权响应| ACQ
    ACQ -->|授权响应| PG
    PG -->|响应| M
    M -->|小票| CH

    style SCH fill:#388bfd,color:#fff
    style ISS fill:#3fb950,color:#fff
    style ACQ fill:#f0883e,color:#fff

1.2 Processor、ISO、PF 角色拆解

在上图”收单行”这一块其实还有三种可能叠加的角色：

• Processor（处理商）：如 FIS、Fiserv（First Data）、TSYS、Worldpay，提供技术侧的报文接入、授权路由、清算文件处理。多数中小收单行不会自建 ISO 8583 网关，而是把处理业务外包给 Processor。
• ISO（Independent Sales Organization）：收单行授权的外部销售机构，负责商户开发、线下部署 POS，不直接持有收单牌照。
• Payment Facilitator / PayFac：如 Stripe、Square，通过”大商户号 + 子商户”模式把自己挂在某个 Acquirer 下，给 SaaS 型客户极简的入驻体验；监管责任由 PayFac 承担。

发卡行一侧也有类似的层次：Issuer Processor（如 Marqeta、TSYS）承担发卡技术；BIN Sponsor 把 BIN 段租给金融科技公司（参考 2023 年美国 Synapse/Evolve 崩溃事件暴露的问题）。

1.3 一张角色对应表

二、卡号结构与安全要素

2.1 PAN、BIN、校验位

主账号（PAN，Primary Account Number）通常为 13–19 位数字。ISO/IEC 7812 定义其结构：

4  5 3 9 1 5  8 4 2 7 6 9 4 2 0 3
^  ^^^^^^^^^  ^^^^^^^^^^^^^^^^  ^
MII BIN/IIN   Account Identifier  Check

• MII（Major Industry Identifier）：首位数字，1–2 航空、3 旅行娱乐（Amex/Diners）、4 银行金融（Visa）、5 银行金融（Mastercard）、6 商品/金融（Discover、银联）、7 石油、8 医疗通信、9 国家指派。
• BIN / IIN（Bank Identification Number / Issuer Identification Number）：前 6 位（2022 年 4 月起 ISO 标准扩展至 8 位），用于识别发卡行与卡组织。收单行和网关路由、费率计算、反欺诈都依赖 BIN 数据库。
• 账户标识：由发卡行自主分配，长度可变。
• 校验位：最后一位，由 Luhn 算法生成。

Luhn 算法（Mod-10）示例：

def luhn_checksum(card_num: str) -> bool:
    digits = [int(c) for c in card_num if c.isdigit()]
    checksum = 0
    for i, d in enumerate(reversed(digits)):
        if i % 2 == 1:
            d *= 2
            if d > 9:
                d -= 9
        checksum += d
    return checksum % 10 == 0

assert luhn_checksum("4539158427694203")  # Visa 测试号段

注意：Luhn 只是防止打字错误的轻校验，不是安全机制；任何以 Luhn 通过做授权前置的 Processor 都要同时配合 BIN 白名单和 PAN 段过滤，否则会被”卡号枚举”攻击刷流量。

2.2 有效期、服务代码、CVV 家族

磁道数据（Track 1/Track 2）除了 PAN 还带：

• Expiry Date：YYMM，4 位，授权时必校验。
• Service Code：Track 2 上 3 位，定义卡的地理限制、认证方式、允许交易类型。例如 201 表示允许国际、需要 IC 优先、允许所有交易；101 常见于纯磁条老卡。
• CVV 家族：
  • CVV1（写在磁条里，POS 刷卡才能读出）
  • CVV2 / CVC2 / CID（印在卡背面/正面，用于 CNP 电商交易）
  • iCVV（写在 IC 芯片中）
  • dCVV（dynamic CVV，代币化或 HCE 动态生成）

这些 CVV 全部由发卡行基于 PAN + 有效期 + 服务代码 + Issuer Master Key 通过 3DES/AES HSM 计算而来；收单侧绝不允许存储 CVV2，这是 PCI DSS 最被频繁违规的一条。

2.3 Tokenization：网络 Token 与支付 Token

为了减少 PAN 暴露，2014 年 EMVCo 发布《EMV Payment Tokenisation Specification》：

• Network Token（网络令牌）：由卡组织 TSP（Token Service Provider）签发，和 PAN 一对一（或一对多）绑定；格式仍是 16 位”卡号”但 BIN 落在专门的 Token BIN Range。Apple Pay/Google Pay/Samsung Pay 都使用 DPAN（Device PAN）即网络 Token。
• Acquirer Token / Payment Token：Stripe、Adyen 等网关自己生成的字符串，仅在其系统内有效，商户侧保存 token 而非 PAN，用于订阅扣款、一键支付。这种 token 不能跨网关使用。

持卡人 PAN:  4539 1584 2769 4203
Apple Pay DPAN:  4911 **** **** 1357 （真实卡号不出设备）
Stripe customer token: cus_Nf12ab..., payment method pm_1N...

tokenization 对风控链路影响巨大：fraud 检测模型要以 PAN + DPAN 作为同一主体去聚合行为。

三、六个阶段：一笔交易的完整生命周期

一笔”刷卡成功”背后的六个阶段，是卡组织工程师必须背下的基础框架：

1. Authorization（授权）：实时在线询问发卡行是否同意扣款。
2. Authentication（认证）：以 3D Secure 为代表的持卡人身份验证，通常在 CNP 场景叠加在授权之前。
3. Clearing（清算）：T+1 批处理，收单行把当日所有授权提交到 Scheme，Scheme 发给各发卡行。
4. Settlement（结算）：基于清算文件产生的净额，在央行大额支付系统完成银行间资金划拨。
5. Dispute / Chargeback（争议与拒付）：120 天乃至 540 天窗口内持卡人可发起拒付，走规则引擎裁决。
6. Reconciliation（对账）：商户、收单行、卡组织、发卡行四方对每一笔交易的状态与金额逐条核验。

sequenceDiagram
    autonumber
    participant CH as 持卡人
    participant POS as POS / 网关
    participant ACQ as 收单行 Processor
    participant SCH as 卡组织 Scheme
    participant ISS as 发卡行 Issuer
    participant CB as 央行/清算所

    Note over CH,ISS: 阶段1 Authorization（实时）
    CH->>POS: 插卡/碰 NFC/输入卡号
    POS->>ACQ: 0100 Authorization Request (ISO 8583)
    ACQ->>SCH: 0100 转发（附 Acquirer BIN）
    SCH->>ISS: 0100 转发到发卡行
    ISS->>ISS: 风险打分 + 余额检查 + 冻结额度
    ISS-->>SCH: 0110 Response (Approval / Decline)
    SCH-->>ACQ: 0110 Response
    ACQ-->>POS: 0110 Response
    POS-->>CH: 打印小票 / 前端 success

    Note over ACQ,ISS: 阶段2 Authentication（3DS，在线交易前置）
    Note over ACQ,CB: 阶段3 Clearing（T+1 批量 0220/0225）
    ACQ->>SCH: Presentment 文件（TC 批处理）
    SCH->>ISS: Incoming Presentment
    ISS-->>SCH: 接受/拒收
    Note over SCH,CB: 阶段4 Settlement（净额 RTGS）
    SCH->>CB: 结算指令（各成员行净额）
    CB-->>ACQ: 贷记
    CB-->>ISS: 借记
    Note over CH,ISS: 阶段5 Dispute（持卡人发起 Chargeback，120 天内）
    Note over CH,ISS: 阶段6 Reconciliation（四方对账）

接下来的章节我们依次拆这六个阶段的报文与工程细节。

四、Authorization 授权：ISO 8583 详解

4.1 为什么还是 ISO 8583

ISO 8583 第一版发布于 1987 年，几乎是金融报文的 IPv4：所有人都想替换它，但线路上跑的主流依旧是它。原因很简单：

• 极度紧凑：一笔授权 200–400 字节，卫星链路、GPRS POS、老 X.25 网关都能跑。
• 全球 Scheme 的核心网均已基于 8583 演进（Visa Base I/Base II、Mastercard MDS、银联 UICS、JCB、Amex），改造代价巨大。
• 芯片卡、3DS、tokenization 都能通过新增 DE（Data Element）或 Subfield 扩展，不必换协议。

4.2 MTI（Message Type Indicator）

MTI 是 4 位数字，按”版本 + 类别 + 功能 + 来源”编码：

常用 MTI 速查表：

4.3 Bitmap 与 Data Element

ISO 8583 把 128 个字段组织为两层 Bitmap：

• Primary Bitmap：必带，64 位（8 字节二进制或 16 字节十六进制 ASCII），第 N 位为 1 表示 DE-N 存在。Bit 1 置 1 表示存在 Secondary Bitmap（DE65–DE128）。
• Secondary Bitmap：可选，用于覆盖 DE65–DE128。

高频字段速查：

响应码（DE39）是支付网关必须全表覆盖的”痛苦之源”：Visa、Mastercard、银联的码表虽然大部分一致，但 05/57/61/62/65 等细节语义在不同 Scheme 下略有差异，风控路由要做”原始码 → 标准化码 → 业务码”三层映射。

4.4 Python 构造 0100 报文示例

下面的代码演示最基础的 0100 授权请求构造。生产代码推荐使用成熟库如 iso8583（Python）、jpos（Java）、goiso8583（Go），以下为说明原理的最小实现：

from datetime import datetime, timezone

def encode_lvar(value: str, ll: int) -> str:
    return str(len(value)).zfill(ll) + value

def build_bitmap(fields: dict) -> str:
    bits = ['0'] * 128
    if any(k > 64 for k in fields):
        bits[0] = '1'   # 启用 Secondary Bitmap
    for k in fields:
        bits[k - 1] = '1'
    hex_map = ''
    for i in range(0, 128, 4):
        nibble = int(''.join(bits[i:i+4]), 2)
        hex_map += f'{nibble:X}'
    return hex_map[:16] if bits[0] == '0' else hex_map

def build_0100(pan: str, amount_cents: int, stan: int,
               expiry: str, mcc: str, tid: str, mid: str,
               currency: str = '156') -> bytes:
    mti = '0100'
    now = datetime.now(timezone.utc)
    fields = {
        2:  encode_lvar(pan, 2),
        3:  '000000',
        4:  str(amount_cents).zfill(12),
        7:  now.strftime('%m%d%H%M%S'),
        11: str(stan).zfill(6),
        12: now.strftime('%H%M%S'),
        13: now.strftime('%m%d'),
        14: expiry,                  # YYMM
        18: mcc,
        22: '051',                   # chip contact
        25: '00',
        41: tid.ljust(8),
        42: mid.ljust(15),
        49: currency,
    }
    bitmap = build_bitmap(fields)
    body = ''.join(fields[k] for k in sorted(fields))
    message = mti + bitmap + body
    # 实际传输前通常再加 2 字节长度头（Big-Endian）
    raw = message.encode('ascii')
    return len(raw).to_bytes(2, 'big') + raw

pkt = build_0100(
    pan='4539158427694203',
    amount_cents=12800,            # 128.00 CNY
    stan=123456,
    expiry='2812',
    mcc='5812',
    tid='T0000001',
    mid='M000000000001',
)
print(pkt.hex())

输出的 hex 是面向教学的”ASCII 拼接版”；真实 VisaNet/Banknet 多为 EBCDIC 或混合二进制编码，STAN/DE4/DE49 用压缩 BCD，Bitmap 也用二进制 8 字节。

4.5 Go 版本：强调 PAN 脱敏与 HSM 封装

package iso8583

import (
    "encoding/hex"
    "fmt"
    "strings"
    "time"
)

type AuthRequest struct {
    PAN         string // 16 digits
    AmountCents int64
    STAN        int
    ExpiryYYMM  string
    MCC         string
    TerminalID  string
    MerchantID  string
    Currency    string // "156"
    ICCData     []byte // EMV TLV, DE55
}

// Build0100 构造授权请求报文；真实系统中 PAN 必须来自 HSM tokenization 层
func Build0100(r AuthRequest) ([]byte, error) {
    if len(r.PAN) < 13 || len(r.PAN) > 19 {
        return nil, fmt.Errorf("invalid PAN length")
    }
    now := time.Now().UTC()
    fields := map[int]string{
        2:  fmt.Sprintf("%02d%s", len(r.PAN), r.PAN),
        3:  "000000",
        4:  fmt.Sprintf("%012d", r.AmountCents),
        7:  now.Format("0102150405"),
        11: fmt.Sprintf("%06d", r.STAN),
        12: now.Format("150405"),
        13: now.Format("0102"),
        14: r.ExpiryYYMM,
        18: r.MCC,
        22: "051",
        25: "00",
        41: padRight(r.TerminalID, 8),
        42: padRight(r.MerchantID, 15),
        49: r.Currency,
    }
    if len(r.ICCData) > 0 {
        fields[55] = fmt.Sprintf("%03d%s", len(r.ICCData), hex.EncodeToString(r.ICCData))
    }
    bitmap := buildBitmap(fields)
    var body strings.Builder
    for _, k := range sortedKeys(fields) {
        body.WriteString(fields[k])
    }
    msg := "0100" + bitmap + body.String()
    raw := []byte(msg)
    hdr := []byte{byte(len(raw) >> 8), byte(len(raw) & 0xFF)}
    return append(hdr, raw...), nil
}

4.6 预授权、完成、撤销、冲正（Reversal）

同一笔业务可能涉及多条报文：

• 预授权（Pre-auth） = 0100，典型场景：酒店入住冻结押金、加油站预估金额；仅冻结额度不入账。
• 预授权完成（Pre-auth Completion） = 0220/0200，退房时提交实际金额，可大于或小于预授权（超过一定百分比需重新授权）。
• 撤销（Void/Cancel） = 0400 或 0420，日切前撤销尚未清算的授权。
• 冲正（Reversal） 分两类：
  • 在线冲正：收单在收到 Timeout（如 60 秒无响应）或端用户取消时，主动发 0400 把先前 0100 回滚。冲正必须幂等，因为网络抖动会让发卡行两边都看到”授权成功”。
  • 批量冲正：批处理异常时，对整批次回滚。

4.7 AVS 与 CVV2 校验

在 CNP（Card Not Present，无卡交易，如电商）场景，发卡行除了扣款还做两项软校验：

• AVS（Address Verification System）：比对持卡人输入的邮编/地址与发卡行档案。响应码有 Y（完全匹配）、Z（仅邮编匹配）、N（不匹配）、U（无法校验，非美系卡行常见）。
• CVV2 校验：发卡行用 HSM 基于 PAN + 有效期 + Service Code 计算 CVV2，和商户提交的比对。

AVS/CVV 仅影响授权决策，不提供 Liability Shift（责任转移）——这需要 3DS。

4.8 双离线（Store-and-Forward）与 Stand-In

如果收单终端临时失联（POS 无网、机舱、海上邮轮、偏远山区），Scheme 规则允许在一定金额、一定交易类型下采用 Store-and-Forward（双离线）：

• POS 本地用芯片 Offline Data Authentication（SDA/DDA/CDA）校验卡的”真伪”与卡端余额。
• 生成 TC（Transaction Certificate）而非 ARQC，存储在终端。
• 联网后补发 0120（Authorization Advice），发卡行此时”被动接受”。

Stand-In Processing（STIP）则是反向：发卡行不可用时，Scheme 代为授权（基于预设规则：金额阈值、黑名单、速率限制）。Visa STIP、Mastercard STAN、银联 STIP 都支持。代为授权的交易会在发卡行恢复后以 0220 Advice 通知，发卡行一般不能再拒绝。这种”强制成功”的机制需要收单和发卡在风险上事先签署协议，否则极易成为欺诈套现通道。

4.9 响应码与自动重试策略

收到 DE39 后，收单侧不能无差别”直接返回失败给商户”。工程建议的处理矩阵：

订阅业务踩坑：对 05/14/54/57 继续每日重试会被发卡行风控打标”Aggressive Retry”，导致整条 MID 被标记并降低所有合法交易通过率。Visa 2022 年专门发文禁止对硬拒绝码的盲目重试，违规会被罚款。

五、Authentication：EMV 3D Secure 2

5.1 从 3DS 1 到 EMV 3DS

3D Secure 1（2001）依赖浏览器跳转到发卡行 ACS 页面输入静态密码，转化率损失高达 20%–30%，被戏称”wrecker of conversions”。

EMV 3DS 2.x（2016 起，2022 年 2.3.1）引入三大改变：

• 丰富数据（Data Sharing）：商户在 AReq（Authentication Request）中附带 100+ 设备、行为、历史字段（IP、UA、device fingerprint、previous transactions）。
• 无感（Frictionless）流：发卡行 ACS 基于 RBA（Risk-Based Authentication）直接返回成功，不弹任何 challenge。目前国际市场 frictionless 率约 75%–85%。
• App-based 原生支持：通过 3DS SDK 嵌入 App，不再依赖 WebView 跳转。

5.2 报文流程

sequenceDiagram
    participant APP as 商户 App/Web
    participant 3DS as 3DS Server
    participant DS as Directory Server (Scheme)
    participant ACS as 发卡行 ACS

    APP->>3DS: 初始化 + 设备数据
    3DS->>DS: AReq (Authentication Request)
    DS->>ACS: AReq
    ACS-->>DS: ARes (Frictionless / Challenge)
    DS-->>3DS: ARes
    alt Frictionless
        3DS-->>APP: Authentication Value (CAVV/AAV)
    else Challenge
        3DS-->>APP: Challenge URL
        APP->>ACS: CReq (OTP/生物识别/App 通知)
        ACS-->>APP: CRes (成功/失败)
        3DS->>DS: RReq/RRes（最终结果）
    end

拿到的 CAVV（Cardholder Authentication Verification Value）/AAV 会放入后续 0100 报文的 DE48 子字段（或 Visa 私有 DE126），发卡行校验通过后授权，同时责任从商户转移至发卡行；即 fraud chargeback（Reason Code Visa 10.x 系列）不再能追到商户。

5.3 Strong Customer Authentication 与 PSD2

欧盟 PSD2 要求所有电子支付完成 SCA（Strong Customer Authentication），即三要素两满足：Knowledge（密码/PIN）、Possession（手机/卡）、Inherence（指纹/面容）。3DS 2 是最主流的 SCA 载体，也有若干豁免：

• 低值交易（单笔 ≤ €30，累计 ≤ €100 或 5 次）
• TRA（Transaction Risk Analysis）豁免：收单商欺诈率低于阈值（如 < 0.06% 对应 ≤ €500）
• 白名单（Trusted Beneficiaries）
• 企业采购卡
• 订阅续费（首笔 SCA 后的扣款）

中国网联侧并不强制 3DS，但涉外卡仍需按 Scheme 规则做 3DS。

5.4 device fingerprint 与 RBA 工程

AReq 中最关键的一组字段是 Browser Info（browserAcceptHeader、browserColorDepth、browserIP、browserLanguage、browserScreenHeight/Width、browserTZ、browserUserAgent、browserJavaEnabled）和 SDK Info（sdkAppID、sdkEphemPubKey、sdkReferenceNumber、sdkTransID、sdkMaxTimeout）。发卡行 ACS 基于这些 100+ 字段做 RBA：

• 高信任路径：设备历史匹配 + IP 与账单地址同国 + 金额 < 平均 2σ → Frictionless Approved。
• 中信任：设备陌生但风险评分中等 → 发 OTP Challenge 或 推送到银行 App 确认。
• 低信任：设备匹配黑名单或金额异常 → 直接 Decline（ARes transStatus=R）。

工程上，商户 SDK 必须在”用户点击支付”之前就开始 fingerprint 采集（典型在商品详情页加载 SDK），否则 ACS 收到的数据不足会被迫走 challenge，降低转化。Airlines、OTA 类高客单价商户通常在 SDK 采集上投入最大。

5.5 3RI 与非交互式场景

订阅续费、押金解冻、MIT（Merchant-Initiated Transaction）类无用户在线场景通过 3RI（3DS Requestor Initiated） 走认证，threeDSRequestorAuthenticationInd 填 02（Recurring）、03（Installment）、04（Add Card）等；这些场景通常 frictionless，不走 challenge。

六、Clearing 与 Settlement：批处理与净额

6.1 Presentment 与 Clearing File

授权只是”冻结”，真正要把钱转过来需要清算批处理。以 Visa 为例：

• 收单行在日切（Cutover，通常 UTC-8 次日 03:00 或各区域时区）前把当日所有已完成的交易汇总为 TC（Transaction Component）记录，打包为 VSS（Visa Settlement Service） 格式的 Base II 文件（现向 Visa Resolve Online/VCMS 平台逐步迁移）。
• 文件通过 VisaNet EDIT 或 VCF（Visa Commercial Format）推送到 Visa。Visa 完成 Scheme 层扣费（Interchange、Assessment、Scheme Fee）后，把属于各发卡行的 TC 分发过去，称为 Incoming Presentment。
• 发卡行收到后进行”入账处理”，同时向 Scheme 回确认；争议窗口开始计时。

Mastercard 的类似流程称为 IPM（Integrated Product Messages），走 GCMS（Global Clearing Management System）；银联走 UICS Clearing Batch，文件通过 UPCOMB 专线传输。

6.2 Interchange Fee 计算

Interchange 是四方模型中最复杂的一块：费率按 MCC × 卡种 × 交易类型 × 跨境/本地 × 商户分级等维度做百+行矩阵。例如 Visa US 零售借记卡 Tier 1（大商户）约 0.05% + $0.22/笔；跨境金卡可能 1.60% + $0.10/笔。

Scheme 还收 Scheme Fee（如 Visa Assessment ~0.13%、Mastercard ~0.1375%）。

商户看到的 MDR = Interchange + Scheme Fee + Acquirer Markup + 风险准备金。“Interchange Plus” 定价会把三段拆开展示给大商户，小商户多为”Blended”打包费率。

6.3 Settlement（结算）

结算是资金层面的转移：

• 净额（Net Settlement）：Scheme 汇总所有成员行当日的收付差额，向一家清算行（Settlement Bank，如 Wells Fargo for Visa USD、JPMC for Mastercard USD）发出指令，由清算行在央行 RTGS（美国 Fedwire、欧洲 TARGET2、中国 HVPS）完成行间划拨。
• 结算币种：跨境交易先由 Scheme 在自己的账户体系做币种转换，收单行收到的通常是记账币种（如 USD、EUR、RMB）。
• 商户到账：收单行扣除 MDR 后在 T+1（或 T+N）入账到商户结算账户；PayFac 模式可能做 T+0 实时结算（垫资）。

6.4 日切与”24 小时窗口”

日切时间差异在跨国收单里最容易”结算少一天”：Visa Cutover 基于发卡区域，Mastercard 按 CST（Central Standard Time），银联以北京时间 00:00 为边界。国际大商户在计算当日 GMV、对账时要先把”本地交易时间 DE12/13”映射到 Scheme 的 processing date，再映射到商户记账日期，否则就会出现”T+0 少一笔、T+1 多一笔”的对账差异。

6.5 TCR 记录格式示例（Visa Base II）

Visa 清算批文件由若干 TC（Transaction Component） 组成，每条由 TCR0（主记录）和若干 TCRn 扩展记录构成，定长 ASCII。一笔简单的零售销售 TC05（First Presentment/1700）：

TCR0: TC=05 AC=1700 RecNum=0001 PAN=4539********4203 TransactionCode=00
       TransactionCurrency=840 SourceCurrency=156
       Amount=000000012800 RRN=611203000001 Auth=123456
       TID=T0000001 MID=M000000000001 Acquirer BIN=455555
       MCC=5812 DestCountry=840 ...
TCR1: POS Entry Mode=051 POS Condition=00 AVS=Y CAVV=... ECI=05 ...
TCR5: Fee Collection Details ...
TCR7: Currency Conversion Rate ...

Mastercard IPM 也是类似的定长 + 嵌入式 PDS（Private Data Subelement）结构；PDS-0158、PDS-0023 是常用字段。银联 UICS 的清算文件为定长 TXT，每批次带 Header/Trailer，以 BATCH 记录分割。

6.6 Funding 与商户结算

商户拿到的是收单行的”结算款”，不是 Scheme 的原始金额。典型路径：

1. Scheme Net Settlement → 收单行 Nostro 账户（T+1 早 8 点前）。
2. 收单行按商户合同计算应付金额 = Σ(Authorized & Captured) - MDR - 退款 - Chargeback 预扣 - 保证金。
3. T+1 晚 / T+2 通过银企直连（中国）或 ACH（美国）/ SEPA（欧洲）划拨到商户收款账户。
4. 大商户会在 T+1 前要求”next day funding”、甚至通过预付资金池做”T+0”，但收单行要垫资。

工程关键是 funding 通知与实际到账可能不一致：商户系统必须对账”收单方通知的结算单 ↔︎ 商户银行账户流水”，差异超过阈值（如 500 元 / 0.1%）立刻挂起人工。

七、争议与拒付（Chargeback）

7.1 生命周期

stateDiagram-v2
    [*] --> 交易完成
    交易完成 --> 持卡人投诉: 120~540 天内
    持卡人投诉 --> 第一次拒付: Chargeback
    第一次拒付 --> 商户接受: Accept
    第一次拒付 --> 商户申诉: Representment
    商户申诉 --> Pre-arbitration: 发卡行再次挑战
    Pre-arbitration --> Arbitration: 提交给 Scheme 仲裁
    Arbitration --> 败诉方买单
    商户接受 --> [*]
    败诉方买单 --> [*]

7.2 Reason Code

Visa 于 2018 年推出 VCR（Visa Claims Resolution），把近 30 个 reason code 压缩到 4 大类：

• 10 Fraud（持卡人否认交易）
• 11 Authorization（未授权或授权过期）
• 12 Processing Errors（重复扣款、金额错）
• 13 Consumer Disputes（货不对板、未收到、退款未处理）

Mastercard MCRS（Mastercard Com System） 类似，reason code 如 4837 Fraud-No Cardholder Authorization、4853 Cardholder Disputes-Defective/Not as Described。

7.3 关键时限

工程上最容易踩的坑：Chargeback 对应的原始交易可能已在商户数据库 archived，必须做 180 天”热在线、540 天温归档”的数据保留策略，否则举证时找不到 3DS AAV、IP、物流号等关键证据。

7.4 Chargeback 率与 VAMP / EMP

Visa 2023 年推出 VAMP（Visa Acquirer Monitoring Program），统一替换原 VDMP/VFMP：若商户月度 fraud 拒付率 > 0.9% 或笔数 > 100，会被罚款并进入观察名单；超过 1.8% 或笔数 > 1000 进入 Excessive 档位，罚款可达每笔 $10。Mastercard 对应 EMP（Excessive Chargeback Merchant），阈值 1.5%。

这对高风险行业（订阅、游戏、成人内容、博彩）是生死线：一家商户 chargeback 率超标往往是被收单行清退的直接触发条件。

7.5 Chargeback 数据模型示例

工程实现中，“争议 + 证据 + 通讯” 三张表结构大致如下（TiDB/Postgres 兼容语法）：

CREATE TABLE chargeback (
    id              BIGINT PRIMARY KEY,
    scheme          VARCHAR(16) NOT NULL,          -- VISA / MC / UPI
    case_id         VARCHAR(64) NOT NULL,          -- Scheme 侧 case
    rrn             VARCHAR(12) NOT NULL,
    original_txn_id BIGINT NOT NULL,
    reason_code     VARCHAR(8)  NOT NULL,
    amount_cents    BIGINT      NOT NULL,
    currency        CHAR(3)     NOT NULL,
    status          VARCHAR(16) NOT NULL,          -- RECEIVED / ACCEPTED / REPRESENTED / WON / LOST
    received_at     TIMESTAMP   NOT NULL,
    respond_due_at  TIMESTAMP   NOT NULL,
    merchant_id     VARCHAR(32) NOT NULL,
    INDEX idx_rrn (rrn),
    INDEX idx_due (respond_due_at, status)
);

CREATE TABLE chargeback_evidence (
    cb_id          BIGINT NOT NULL,
    kind           VARCHAR(32) NOT NULL,           -- 3DS_AAV / IP / DEVICE / AVS / TRACKING / RECEIPT
    value          TEXT        NOT NULL,
    collected_at   TIMESTAMP   NOT NULL,
    PRIMARY KEY (cb_id, kind)
);

CREATE TABLE chargeback_timeline (
    cb_id      BIGINT NOT NULL,
    seq        INT    NOT NULL,
    actor      VARCHAR(32) NOT NULL,               -- ISSUER / ACQUIRER / MERCHANT / SCHEME
    event      VARCHAR(32) NOT NULL,
    payload    JSON,
    created_at TIMESTAMP NOT NULL,
    PRIMARY KEY (cb_id, seq)
);

关键建议：

• respond_due_at 自动从 Scheme 规则推算，临期（< 5 天）系统必须向运营/商户强提醒。
• chargeback_evidence 按 kind 规范化，在代表举证时自动组装 PDF/ZIP 上传。
• 所有 payload JSON 保留 Scheme 原始字段，便于未来规则变更回溯。

7.6 VCR / MCRS 自动化接入

Visa 于 2019 年启用 VROL（Visa Resolve Online） 作为全球争议受理平台，收单行通过 REST API 拉取 case、上传证据。Mastercard 对应 MCRS（Mastercard Chargeback Resolution System），仍走 IPM 批文件。

工程实现上，建议：

• VROL 每 5 分钟轮询新 case；到期前 48 小时自动生成证据包。
• 证据包结构（Visa 建议）：Cover Letter（PDF）、Transaction Details、3DS Result、Customer Communications、Delivery Confirmation、Product/Service Description。
• 对”小额 + 举证成本 > 交易金额”的 case 直接 Accept，由规则引擎自动决策。

8.1 为什么要迁移

ISO 8583 的痛点：

• 字段语义依赖 DE/subfield，自描述性差；新增业务字段需 Scheme 发规则手册，生态割裂。
• 二进制 Bitmap + 固定长度编码不易调试。
• 跨境支付场景下，卡组织报文和 SWIFT 报文语义无法直接对齐。

ISO 20022（UNIFI）是 2004 年起 ISO 基于 XML（后扩展 JSON、ASN.1）定义的金融业务数据字典，已覆盖 700+ 消息。迁移节奏：

• SWIFT：MT → MX 迁移，2023 年 3 月启动，原计划 2025 年 11 月全部切完，延期至 2025 年 11 月，由 SWIFT CBPR+ 规则书监督，2025 年后 MT 103/202/202COV 逐步下线。
• 央行大额：美国 Fedwire 2025 年 3 月 CHIPS ISO 20022、欧洲 T2 2022 年 3 月、中国 CNAPS 2021 年改造 HVPS.08 兼容 20022。
• 卡组织：Mastercard（MDES、MAP 已 20022 化，IPM 计划中）、Visa（CMS 2020 平台）、银联（UICS 3.0 向 20022 兼容）。

8.2 常见消息

• pacs.008 FIToFICustomerCreditTransfer：客户汇款
• pacs.002 FIToFIPaymentStatusReport：状态回执
• pacs.004 PaymentReturn：退汇
• pain.001 CustomerCreditTransferInitiation：企业发起的批量付款
• camt.053 BankToCustomerStatement：对账单
• camt.054 BankToCustomerDebitCreditNotification：入账通知

一条 pacs.008 骨架示例：

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.10">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>MSG20260422-0001</MsgId>
      <CreDtTm>2026-04-22T03:14:00+00:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf><SttlmMtd>CLRG</SttlmMtd></SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId><EndToEndId>E2E-00123</EndToEndId><TxId>UETR-0a1b...</TxId></PmtId>
      <IntrBkSttlmAmt Ccy="EUR">1280.00</IntrBkSttlmAmt>
      <ChrgBr>SHAR</ChrgBr>
      <Dbtr><Nm>Alice</Nm></Dbtr>
      <DbtrAcct><Id><IBAN>DE89370400440532013000</IBAN></Id></DbtrAcct>
      <DbtrAgt><FinInstnId><BICFI>COBADEFFXXX</BICFI></FinInstnId></DbtrAgt>
      <CdtrAgt><FinInstnId><BICFI>BOFAUS3NXXX</BICFI></FinInstnId></CdtrAgt>
      <Cdtr><Nm>Bob</Nm></Cdtr>
      <CdtrAcct><Id><Othr><Id>98765432</Id></Othr></Id></CdtrAcct>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>

8.3 8583 → 20022 字段映射

卡交易本身短期仍会保留 8583，但”清算批处理文件”是迁移重点。映射示例：

迁移必踩的坑：

• XML 大小比 8583 大 10–20 倍，卫星/GPRS POS 无法直接跑；因此终端-收单仍会保留 8583，只在”收单-Scheme-发卡”后段用 20022。
• UETR（Unique End-to-end Transaction Reference） 是 SWIFT gpi 引入的 36 位 UUID，任何跨境消息都要保留，链路追踪的”主键”。
• time zone / truncation：pacs.008 要求 ISO 8601 带时区，很多旧系统写为”本地时间”，迁移时必须重写时间函数。

九、安全与合规

9.1 PCI DSS 四个要点

PCI DSS（Payment Card Industry Data Security Standard）当前版本 4.0.1（2024 年 6 月生效），围绕”持卡人数据环境（CDE，Cardholder Data Environment）“组织 12 项控制。工程落地最常见的四招：

1. 缩小 CDE：通过 tokenization 把 PAN 留在 vault，业务系统只接触 token，合规审计范围从 500 台服务器缩到 30 台。
2. P2PE（Point-to-Point Encryption）：POS 读出的磁道/芯片数据在设备侧用硬件密钥（DUKPT）加密，解密只在 HSM 发生，商户和网关中间环节看不到明文。
3. Key 管理：所有发卡/收单密钥在 HSM 内生成、存储，分量（Key Component）人员分离、Dual Control、Split Knowledge，符合 FIPS 140-2 Level 3。中国监管对应 GM/T 0028 与银联《支付卡 IC 卡密钥管理规范》。
4. 网络分段 + 日志：CDE 与办公网/OA 物理/逻辑隔离，所有 access 日志保留 ≥ 1 年（热存储 3 个月）。

9.2 EMV 芯片的攻击面

EMV（Europay/Mastercard/Visa）标准让卡片在交易时生成 ARQC（Authorization Request Cryptogram）：基于卡内 Master Key 派生的 session key 对交易数据签名，发卡行 HSM 验签。ARQC 一次一密，磁道被复制也无法伪造 IC 交易。

但历史上仍有几类绕过：

• PreAuth Replay / Shimming：在 POS 芯片读卡槽塞薄片窃听芯片-终端间明文。
• Terminal Downgrade：诱导终端降级到磁道模式（Fallback），再用复制磁道消费。EMVCo 近年要求 Fallback 率 < 0.5%，超过将由发卡行承担责任。
• Contactless Limit Abuse：NFC 小额免密额度内无 PIN 校验，丢失卡风险。

9.3 HSM 在链路中的位置

• 发卡侧 HSM：PIN 验证（Zone PIN Key / Terminal Master Key）、ARQC 验签、CVV/CVV2 计算、Token 发行。
• 收单侧 HSM：终端密钥（TMK/TPK）下发（Remote Key Loading）、PIN Block 翻译（从 TPK 加密翻译为 ZPK 加密）、MAC 计算。
• Scheme HSM：Zone Key 管理、跨成员方密钥翻译。

常见 HSM：Thales payShield 10K、Utimaco Atalla、Entrust nShield、国密 HSM（如江南天安）。

9.4 P2PE 与 DUKPT 密钥派生

DUKPT（Derived Unique Key Per Transaction）是 ANSI X9.24 标准的”一次一密”方案：终端出厂时注入 BDK 派生的 IPEK（Initial PIN Encryption Key），每笔交易用 KSN（Key Serial Number，10 字节，含 Device ID + Counter）派生出唯一 Session Key，加密 PIN Block 或磁道数据。收单侧 HSM 根据 KSN 能反推出相同 Session Key 解密，但无法反推 BDK。

工程优势：

• 单台终端被攻破最多泄露”本机历史 + 未来 N 笔”的 Session Key，不影响 BDK 和其他终端。
• KSN Counter 21 bit，理论上单终端 200 万笔后需换 IPEK；实际绝大多数终端生命周期用不完。

部署坑：

• KSN 同步：如果终端断电重启导致 counter 回滚，收单侧 HSM 会拒绝（防重放）；需要”终端每次上电做 0800 签到并同步 counter”。
• Remote Key Injection（RKI）：传统 IPEK 需在安全房手工注入，RKI 通过非对称加密（RSA/ECC）远程下发 IPEK，必须严格使用 Scheme 认证的 RKI 方案（如 Thales RKMS、Futurex KMES），自研会过不了 PCI PIN 审计。

9.5 EMV 交易中的密文家族

一笔 EMV 芯片交易中会生成多个 Cryptogram：

• ARQC（Authorization Request Cryptogram）：终端发起授权时生成，发卡行验签。
• ARPC（Authorization Response Cryptogram）：发卡行返回响应里包含，终端验签后才认为”真的是发卡行回的”。
• TC（Transaction Certificate）：终端在交易结束时生成，作为”已完成”的证据，用于后续清算或离线场景。
• AAC（Application Authentication Cryptogram）：交易被拒绝时的”拒绝证据”。

这些密文的生成使用卡内 Session Key（由 Master Key + ATC 计数器 + 其他数据派生），ATC（Application Transaction Counter）单调递增，这就是”不可重放”的核心。对账系统在复原一笔交易时建议把 ATC、ARQC、ARPC 一并落盘保留 ≥ 540 天。

十、真实事件与教训

10.1 Target 数据泄露（2013）

2013 年 11–12 月，美国零售商 Target 被攻击者通过 HVAC 外包供应商凭证进入内网，横向移动到 POS 系统，安装内存抓取恶意软件（BlackPOS/Kaptoxa），在 POS 读卡后 RAM 中抓取 Track 2 明文数据。约 4000 万 PAN + 7000 万客户 PII 外泄，Target 总损失估计超过 $2.9 亿，促成美国加速 EMV Liability Shift（2015 年 10 月）。

工程教训：

• CDE 分段失败：HVAC 供应商本不该能访问 POS 网段。
• RAM Scraping 攻击的根源是 POS 没有启用 P2PE；启用后终端内存中也只有密文。
• 监控失效：FireEye 告警被忽略了 12 天。

10.2 Capital One AWS 事件（2019）

2019 年，前 AWS 员工利用 Capital One 一台错配的 WAF（SSRF 漏洞）拿到 EC2 IAM 角色凭证，访问 S3 bucket，窃取 1.06 亿信用卡申请信息（PAN 仅一部分，多数为姓名、SSN 后 4 位、信用评分）。Capital One 被罚 $8000 万。

教训：

• IAM 角色权限过宽（bucket s3:ListBucket + s3:GetObject 对整账号）。
• WAF 未启用 IMDSv2，攻击者能直接读 metadata endpoint。
• 日志异常检测延迟 4 个月才发现。

这事件虽然不涉及在线授权链路，但涉及 PCI 持卡人数据环境的云上扩展，是所有把 PAN/PII 上公有云项目的教学案例。

10.3 Knight Capital（2012）

2012 年 8 月 1 日，美国做市商 Knight Capital 上线新 SMARS 路由代码，工程师漏部署 1/8 台服务器，旧代码的一段死代码（“Power Peg”）被重新激活，45 分钟内向 NYSE 发出数百万笔错单，亏损 $4.6 亿，公司次月被收购。

虽然它是股票交易事件，但给卡组织工程师的教训同样重要：报文发送系统一旦出错，规模损失是 O(QPS × 时长)。ISO 8583 授权系统同样存在”老代码被重新激活”的回滚风险，灰度部署必须”全部节点可回滚”而不仅仅是”前几个节点成功”。

10.4 12306 支付升级

中国铁路 12306 自 2012 年开通以来，支付通道经历了若干次升级：

• 2012 年：仅工商银行网银（B2C Gateway）；高峰并发崩溃。
• 2014–2016 年：接入银联在线支付、支付宝、微信支付；引入异步通知队列、订单超时释放。
• 2019 年起：支持 Apple Pay（银联 Token）、云闪付 SDK、数字人民币（2022 年试点）。
• 2023 年春运单日支付峰值 3000 万笔，网联/银联双路由，SLA 要求 99.99%。

工程价值：12306 是国内最典型的”超高瞬时并发 + 强一致性（座位库存）+ 多通道聚合”场景，其支付部分把 授权-扣款-座位锁-失败回退 建模成 SAGA（参考 《幂等、事务与一致性》）。

10.5 British Airways / Magecart（2018）

2018 年 BA 官网和 App 被注入 Magecart 脚本（22 行 JS），用户在支付页面输入卡号时被并发上传到攻击者 CDN，约 38 万持卡人数据泄露。BA 最初被 ICO 罚款 £1.83 亿（基于 GDPR 4% 全球营收），最终降至 £2000 万。

工程教训：

• 支付表单必须在 PCI DSS scope 内的独立 iframe 或由 PSP 托管的 Hosted Fields，商户页面不直接接触 PAN。
• 第三方脚本（分析、广告、AB 测试）不得与支付域共享 DOM；CSP（Content Security Policy）严格限制。
• SRI（Subresource Integrity）校验所有外部 JS。

PCI DSS 4.0 专门新增了 6.4.3、11.6.1 两条要求，强制商户监控支付页面脚本变更。

10.6 银联 “62 开头” BIN 迁移

银联 BIN 主要落在 62（2002 年 ISO 分配）；2016 年起银联把部分卡迁移到 81（2016 年 ISO 分配），国际上部分老终端 BIN 表只识别 62，导致持卡人在海外 ATM 被拒。这是”BIN 表必须热更新”最经典的现实案例——收单、发卡、Token 化系统的 BIN 数据库需要周级甚至日级更新机制，靠硬编码必死。

十一、工程坑点

1. DE39 响应码映射表不可”按需追加”：必须在接入前一次性枚举完整 Scheme 规则书的全部响应码，统一映射到业务层 ApproveStatus/DeclineReason；否则遇到罕见 57/61/62 码时风控策略会走错分支。
2. 冲正必须幂等且最多重试 3 次：超过 3 次 Scheme 会自动退回给发卡行人工处理，继续无效重试只会增加响应码噪声。
3. STAN（DE11）6 位循环复用：一天 QPS 过万的 Terminal 一天就可能把 STAN 轮一圈；因此”追踪唯一 key”必须是 RRN(DE37) + Terminal(DE41) + Date 组合，不能用 STAN 单字段。
4. 时间字段三套：DE7 是 GMT、DE12+DE13 是本地时间、报文到达时间是收单服务器时间；对账 SQL 必须显式声明使用哪个字段，建议全部转为 UTC 存储 + TZ 字段另存。
5. PAN/Track 落盘要 0 容忍：PCI DSS 4.0 要求日志、APM、trace 里的 PAN 至少做 BIN(6)+last4 脱敏，磁道数据绝不能落盘。代码里用 String(pan) 作为 trace span attribute 是最常见的事故。
6. 3DS AAV/CAVV 要与授权报文绑定：发卡行看到 Auth 带 CAVV 才会做 Liability Shift；若 3DS 成功但 AAV 没传进 DE48/126，责任仍在商户。
7. Chargeback 证据 180 天内必须能 O(1) 查出：设计 chargeback_evidence 表，字段覆盖 3DS Result、device fingerprint、IP、物流号、发货照片、客户确认签名；索引以 rrn 为主键。
8. Clearing 文件缺笔 > 重复笔：从授权到清算的延迟要监控（Pending Authorization 大于 T+3 视为异常），否则出现 auth 成功但 clearing 漏提交，商户钱拿不到。
9. ISO 20022 引入后的双轨期：同一笔交易可能在 8583 和 20022 两份”真相”同时存在，必须以 UETR / RRN 对齐并建立 reconciliation 规则。
10. HSM 单点：支付链路每一跳都要过 HSM，TPS 瓶颈常在此；生产需要主备 HSM + 本地软 HSM fallback（仅签名非敏感字段）+ 性能监控。
11. Acquirer / Issuer 时钟漂移：0800 Echo Test 携带时间戳，两侧差异 > 5 秒就会出现”交易时间比到达时间还晚”的诡异日志；生产必须统一 NTP 源（如 pool.ntp.org + 国家授时中心）。
12. 双消息（Dual Message）vs 单消息（Single Message）：传统 Visa Credit 是 Dual Message（0100 Auth + 0220 Clearing 分开），部分 Debit、PIN Debit 是 Single Message（0200 直接扣款）。系统必须按卡种路由到不同的处理流程，否则借记卡会出现”二次扣款”。
13. 退款路径不对称：退款不是 0100 Reversal，而是新的 0200/0220 with Processing Code=200000；它走的是独立的授权与清算链路，发卡行可能延迟 1–5 天才入账。客服系统必须说明”退款与撤销的差异”，否则客诉雪崩。
14. Token 过期与 Card Lifecycle Management：卡片到期、挂失、补卡会触发 Scheme 的 Account Updater（Visa VAU、Mastercard ABU）推送新卡号。订阅商户必须订阅 AU 服务并每日应用，否则续费失败率在第 12–36 个月会突然飙升。

十二、选型与落地清单

12.1 新建卡组织接入项目

1. 先确定是”直连 Scheme”还是”经由 Processor”。体量 < 百万笔/日的通常走 Processor（Fiserv、Adyen、银联商务）；百万笔/日以上可考虑直连。
2. 选择 ISO 8583 库：Java 选 jPOS（老牌、OSS）、Python 选 iso8583 或 pyjpos、Go 选 moov-io/iso8583。自研只在”有深度定制需求”时再考虑。
3. 密钥/HSM 从第一天就上：别用软件 keystore 过 demo 期，后期换 HSM 重构成本极高。
4. 搭建 Scheme 模拟器：Visa VTS、Mastercard MTF、银联测试环境必须对接，CI 每夜跑 200+ 用例回归。
5. 对账文件先行：在 Go-Live 前 4 周就能跑通 End-of-Day 批处理，否则 T+1 就会出”钱少了”的故事。

12.2 风控与合规

• PCI DSS 4.0 自评（SAQ D）+ QSA 年审。
• 网络 Token 化：与 Visa VTS / Mastercard MDES / 银联 Token 对接，减少 PAN 在自建系统的停留。
• 3DS 2 SDK + RBA：尽量提升 frictionless 率，同时保留 challenge 兜底。
• Chargeback 监控看板：日级 fraud rate、RDR（Rapid Dispute Resolution，Visa）/RDR（Ethoca for Mastercard）联动退款。

12.3 可观测性

• 全链路追踪以 UETR / RRN / STAN + Terminal 为 trace id。
• 指标：Auth TPS、Response Time P99、DE39 分布、冲正率、3DS frictionless 率、Chargeback 率、Clearing 提交延迟。
• 告警：单 Issuer 拒绝率 >5× baseline、STAN 重复冲突、HSM 队列堆积。

12.4 容量规划参考

Visa 直连建议至少 3 条 VAP（Visa Access Point）接入，跨地域 + 双运营商。银联直连接入需要专线到总行（上海浦东）并与异地灾备节点建立永备通道，生产环境 RPO ≈ 0、RTO < 5 分钟。

十三、交叉引用

• 本文聚焦”卡”这条路径；更广的支付生态见 《支付系统全景》。
• 幂等、冲正背后的事务模型详见 《幂等、事务与一致性》。
• 清算与结算的资金侧细节，以及 CNAPS/CIPS/Fedwire 会在 《清算 vs 结算 vs 资金归集》 和 《央行支付系统》 展开。
• 对账工程会在 《对账系统工程》 深入。
• 支付宝/微信作为账户类（非卡）通道，在 《支付宝、微信支付接入》。
• 网关设计见 《支付网关设计》。

十四、参考资料

• ISO 8583:2003 Financial transaction card originated messages — Interchange message specifications，ISO 官方标准
• ISO 20022 Message Definitions，https://www.iso20022.org/
• Visa Core Rules and Visa Product and Service Rules（定期发布），https://www.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf
• Mastercard Rules，https://www.mastercard.us/en-us/business/overview/support/rules.html
• 中国银联《银联卡业务运作规章》《UICS 报文规范》，https://cn.unionpay.com/
• EMVCo Specifications（Contact/Contactless/3DS/Tokenisation），https://www.emvco.com/specifications/
• PCI DSS v4.0.1，https://www.pcisecuritystandards.org/
• SWIFT CBPR+ Guidelines for ISO 20022 Migration，https://www.swift.com/standards/iso-20022-programme
• Verizon 2014 PCI Compliance Report（含 Target 事件分析）
• US Senate Report on Target Data Breach，https://www.commerce.senate.gov/
• SEC Knight Capital Order，Release No. 70694（2013-10-16）
• jPOS 文档，http://jpos.org/doc
• moov-io/iso8583，https://github.com/moov-io/iso8583
• Stripe Radar & Chargeback Protection 文档，https://stripe.com/docs/disputes

上一篇：《支付系统全景：收单、发卡、聚合、跨境、B2B、C2C》

下一篇：《支付宝、微信支付接入：服务商模式、预授权、分账、退款、对账》

附录 A：ISO 8583 0100/0110 样例对照

下面这对请求/响应是一笔”在北京某餐厅用中信银行 Visa 卡消费 128 元”的授权交易（示例数据，非真实卡）：

0100 Request（收单 → 发卡）关键字段：

MTI      : 0100
DE2  PAN : 4539158427694203
DE3  PC  : 000000            （消费）
DE4  AMT : 000000012800       （¥128.00）
DE7  GMT : 0422071500         （04-22 07:15:00 UTC）
DE11 STAN: 123456
DE12 LTM : 151500             （北京 15:15:00）
DE13 LDT : 0422
DE14 EXP : 2812
DE18 MCC : 5812
DE22 PEM : 051                （芯片接触）
DE25 PCC : 00
DE32 AIB : 622848             （收单行 BIN）
DE37 RRN : 611203000001
DE41 TID : T0000001
DE42 MID : M00000000000001
DE43     : BEIJING RESTAURANT  BEIJING CN
DE49 CUR : 156                （CNY）
DE55 ICC : 9F26088A... (EMV TLV)
DE64 MAC : 0A1B2C3D4E5F6789

0110 Response（发卡 → 收单）关键字段：

MTI       : 0110
DE2  PAN  : 4539158427694203
DE3  PC   : 000000
DE4  AMT  : 000000012800
DE11 STAN : 123456
DE37 RRN  : 611203000001
DE38 AUTH : 123456
DE39 RSP  : 00                 （Approved）
DE41 TID  : T0000001
DE42 MID  : M00000000000001
DE55 ICC  : 9F27... (ARPC)     （发卡行响应密文）
DE64 MAC  : FE DC BA 98 76 54 32 10

收单方拿到 DE39=00 + DE38 授权码后，终端打印小票，同时把 RRN 作为后续清算、冲正、退款、争议的唯一追踪键。