土法炼钢兴趣小组的算法知识备份

【金融科技工程】07 卡组织收单链路：银联/Visa/Mastercard、ISO 8583、ISO 20022 迁移

2026-04-22 · architecture · fintech · #iso8583 #iso20022 #card-payment #authorization #3ds #chargeback #emv #pci-dss #visa #mastercard #unionpay

文章导航

分类入口
architecturefintech
标签入口
#iso8583#iso20022#card-payment#authorization#3ds#chargeback#emv#pci-dss#visa#mastercard#unionpay

目录

引言

如果把支付世界按”谁在清算”切一刀，卡组织（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”三方打过交道还一头雾水的同学。我们不会堆合规条款，而是把”协议字段 ↔︎ 业务语义 ↔︎ 工程坑”三层打通。

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

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

一、参与方与角色

1.1 四方模型与三方模型

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

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 角色拆解

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

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

1.3 一张角色对应表

角色 典型代表（国际） 典型代表（中国） 主要职责
Scheme Visa、Mastercard、Amex 银联 UnionPay、网联 NetsUnion（线上支付） 维护交换网络、制定规则、分配 BIN
Acquirer JPMC Merchant Services、Worldpay 工行、建行收单部、通联、拉卡拉、银盛 签约商户、承担资金垫付
Issuer Chase、BoA、汇丰 工行、招行、中信等发卡行 发卡、授权、风险承担
Processor Fiserv、FIS、TSYS、Adyen 银联数据、银联商务、易宝 技术处理、对账、风控
Gateway Stripe、Adyen、Braintree 连连、PingPong、Airwallex 前端接入、加密、路由

二、卡号结构与安全要素

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

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 还带：

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

2.3 Tokenization：网络 Token 与支付 Token

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

持卡人 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：所有人都想替换它，但线路上跑的主流依旧是它。原因很简单：

4.2 MTI（Message Type Indicator）

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

位置 含义 常见值
第 1 位 版本 0 = 1987、1 = 1993、2 = 2003
第 2 位 消息类别 1 授权、2 金融、3 文件、4 冲正、5 对账、6 管理、7 费用、8 网络管理、9 保留
第 3 位 功能 0 请求、1 请求响应、2 通知、3 通知确认、4 指令、5 指令响应
第 4 位 来源 0 收单方、1 收单代理、2 发卡方、3 发卡代理、4 其他

常用 MTI 速查表：

MTI 场景 说明
0100 授权请求 金额先冻结不扣款（如酒店预授权）
0110 授权响应 带响应码 DE39
0120 授权建议 已在离线授权后通知发卡行
0200 金融请求 含金额立即扣款（ATM 取现、借记卡消费）
0210 金融响应
0220 金融建议 Presentment 批次里的单笔
0400 冲正请求 由收单发起，撤销先前的 0100/0200
0420 冲正建议 处理机超时后单向冲正
0430 冲正响应
0800 网络管理请求 签到、密钥交换、回声测试（Echo）
0810 网络管理响应

4.3 Bitmap 与 Data Element

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

高频字段速查：

DE 名称 类型 示例
2 PAN（Primary Account Number） LLVAR n..19 16 + 4539158427694203
3 Processing Code n6 000000 消费、010000 ATM 取现、200000 退货
4 交易金额 n12 000000010000 = 100.00（2 位小数）
7 传输时间 GMT n10 MMDDhhmmss
11 STAN（System Trace Audit Number） n6 收单方序号，循环使用
12 本地交易时间 n6 hhmmss
13 本地交易日期 n4 MMDD
14 有效期 n4 YYMM
18 MCC（Merchant Category Code） n4 5411 超市、5812 餐厅
22 POS Entry Mode n3 051 芯片接触、071 NFC、012 磁道、010 手工
25 POS Condition Code n2 00 正常、08 Mail/Telephone
32 Acquirer Institution ID LLVAR n..11
35 Track 2 Data LLVAR z..37 PAN=YYMMservicecodeCVV1discretionary
37 RRN（Retrieval Reference Number） an12 全生命周期追踪号
38 Authorization Code an6 发卡行返回的 6 位授权码
39 Response Code an2 00 approved、05 do not honor、51 insufficient funds、54 expired、55 PIN 错
41 Terminal ID ans8
42 Merchant ID ans15
43 Merchant Name/Location ans40
49 Transaction Currency n3 156 人民币、840 美元、978 欧元
52 PIN Data b64 加密后 PIN Block
55 ICC Data LLLVAR b..999 EMV 芯片 TLV
62 Reserved Private 私有 各 Scheme 自定义，Visa/UPI 均占用
64 MAC b64 报文认证码

响应码（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）

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

4.7 AVS 与 CVV2 校验

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

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

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

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

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

4.9 响应码与自动重试策略

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

响应码 含义 建议动作
00 成功 入账
01 Refer to Issuer 提示持卡人联系发卡行，不重试
05 Do Not Honor 通用拒绝，不要重试，部分场景引导换卡
14 Invalid Card Number 前置校验失败，不重试
41 / 43 Lost / Stolen 报警给风控、不重试
51 Insufficient Funds 不自动重试，可提示分期
54 Expired Card 引导换卡；若商户有 Account Updater 服务可用新卡续扣
57 Transaction not permitted 通常 MCC 限制，不重试
65 Exceeds Withdrawal Limit 对订阅可降低金额重试
91 Issuer Inoperative Scheme/发卡行宕机，允许 1–2 次指数退避重试
96 System Malfunction 同上

订阅业务踩坑：对 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）引入三大改变：

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 载体，也有若干豁免：

中国网联侧并不强制 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：

工程上，商户 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 为例：

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（结算）

结算是资金层面的转移：

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 大类：

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

7.3 关键时限

阶段 Visa Mastercard
Chargeback 发起窗口 通常 120 天，Fraud 最长 540 天 120 天，部分 540 天
商户举证（Representment）窗口 30 天 45 天
Pre-arbitration 30 天 45 天
Arbitration 裁决 由 Scheme 受理后 10–30 天 类似

工程上最容易踩的坑：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)
);

关键建议：

7.6 VCR / MCRS 自动化接入

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

工程实现上，建议：

八、ISO 20022 迁移

8.1 为什么要迁移

ISO 8583 的痛点：

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

8.2 常见消息

一条 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，但”清算批处理文件”是迁移重点。映射示例：

ISO 8583 ISO 20022 含义
DE2 PAN CardDtls/PlainCardData/PAN 主账号
DE4 Amount TxAmt/Amt Ccy= 交易金额 + 币种
DE11 STAN TxId 追踪号
DE37 RRN EndToEndId 端到端引用
DE39 Resp TxSts (ACCP/RJCT) + reason 响应码
DE42 MID MrchntId 商户号

迁移必踩的坑：

九、安全与合规

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 交易。

但历史上仍有几类绕过：

9.3 HSM 在链路中的位置

常见 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。

工程优势：

部署坑：

9.5 EMV 交易中的密文家族

一笔 EMV 芯片交易中会生成多个 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 月）。

工程教训：

10.2 Capital One AWS 事件（2019）

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

教训：

这事件虽然不涉及在线授权链路，但涉及 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 年开通以来，支付通道经历了若干次升级：

工程价值：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 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 风控与合规

12.3 可观测性

12.4 容量规划参考

场景 TPS 量级 HSM 数量 ISO 8583 连接
区域中小收单（< 500 商户） 10–100 2（主备） Scheme 单连
全国收单 / PayFac 1k–10k 4–8，HA 集群 Scheme 多连 + STP
双十一级网关 50k+ 峰值 16+ + 软 HSM 离线签名 多活多路由

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

十三、交叉引用

十四、参考资料

上一篇：《支付系统全景：收单、发卡、聚合、跨境、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 作为后续清算、冲正、退款、争议的唯一追踪键。

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-22 · architecture / fintech

【金融科技工程】金融科技工程全景：从支付到交易所的系统分类与读图

金融科技（FinTech）不是普通后端加一张账户表。钱的原子性、监管的硬边界、一个小数点的代价，把这个领域推进到工程强度最高的那一档。本文是【金融科技工程】25 篇的总目录与阅读地图：先交代为什么它比一般业务系统更难，再给出对账体、支付体、交易体、风控合规体四维分类，把后续 24 篇挂到骨架上，最后给出一份绿地项目的落地顺序建议。

By .