第 1 章 全球餐饮支付全景

1.1 手册的使用目标

支付方案不是“接一个付款按钮”或“配一台终端”。对餐饮商户而言，它至少同时影响顾客结账体验、门店履约节奏、资金到账、手续费、退款处理、日结对账和合规责任。本手册应在方案讨论开始时回答以下五个问题：

1. 顾客在什么餐饮场景、以什么方式支付？
2. 哪些系统和角色发起、执行、确认和记录交易？
3. 钱从顾客到商户的路径、扣费时点、结算周期和异常责任分别是什么？
4. 平台需要提供哪些标准能力，哪些应由国家或服务商配置？
5. 上线后用什么交易、结算、账单和银行证据证明方案可运行？

1.2 支付对象与责任关系

flowchart LR
    C[顾客] -->|付款授权或确认| P[支付终端/线上收银台]
    P -->|支付请求| PSP[支付服务商/收单方]
    PSP <-->|审批与清算| N[支付网络、钱包或银行]
    PSP -->|同步结果、异步通知、结算文件| S[SaaS支付编排/对账服务]
    S -->|支付状态与凭证| O[餐饮订单/POS]
    PSP -->|净额或毛额结算| BA[商户结算银行账户]
    O -->|订单、退款、日结数据| F[门店与财务]

图示表达的是通用信息和资金关系：订单系统应接收支付状态与凭证，支付服务商负责其合同中约定的交易和结算行为，财务以结算文件和银行入账完成核对。实际资金路径、信息路径、签约主体和数据边界必须在每个服务商合同与接口方案中单独确认。

1.3 五类关系必须分别确认

同一机构可以承担多个角色，但不得因为其自称“支付伙伴”“ISV”或“收单方”而推定其全部责任。

第 2 章 支付专业知识基础

2.1 支付方式与餐饮场景分类

“门店内支付”并不必然属于卡在场（CP）；“扫码”也不必然是线上或卡不在场（CNP）。支付服务商应按实际支付方式、终端类型、认证方式和其网络规则说明交易分类、费用和争议影响。

2.2 交易生命周期与关键控制点

sequenceDiagram
    participant POS as POS/点餐系统
    participant PAY as 支付终端或收银台
    participant PSP as 支付服务商
    participant C as 顾客
    POS->>PAY: 创建支付会话(订单、金额、幂等键)
    PAY->>C: 展示金额并请求付款
    C->>PAY: 认证/确认支付
    PAY->>PSP: 提交支付交易
    PSP-->>PAY: 同步受理结果
    PSP-->>POS: 异步通知或可查询状态
    POS->>PSP: 结果未知、超时或冲突时主动查询
    PSP-->>POS: 最终可确认交易状态
    POS->>POS: 更新支付单、订单、凭证与审计记录

控制原则如下：

• 创建支付单时锁定或校验待付金额；订单、支付单、支付方式、币种和金额必须可追溯。
• 同一笔业务支付以幂等键和支付单号防重；终端重试、回调重复、人工再次点击均不可造成重复扣款。
• 同步回执只能表示当前响应；网络、超时、终端故障或回调丢失时必须主动查询。
• 终端显示成功不自动等于餐饮订单已完成；订单更新以支付服务商可确认的最终状态及平台规则为准。
• 授权、扣款、撤销、退款、结算和银行到账都应保持独立记录。

2.3 支付、清算、结算和对账

2.4 支付服务商报价模型与费用结构

支付服务商报价不是“交易费率”一个数字，而是一组把交易处理、收单、终端、资金结算、风险和运营服务打包或拆开的商业条款。产品、商务和财务首先要判断报价属于哪一种模型，再比较相同业务量下的总成本、资金可用性和经营约束。

IC++ 只是“成本加成/透明拆分”模型的一种常见表达，不是全球默认方案，也不是服务商费用的全部。 无论使用哪种模型，都不能只问“费率多少”，而要将每笔交易、每台设备、每个结算周期和每项异常服务的费用还原到可验证的账单口径。

2.5 解读报价时必须拆开的六层

1. 交易层：百分比费、固定单笔费、最低收费、拒绝交易是否收费，以及线下、线上、扫码、转账、钱包等是否分别计价。
2. 网络与支付方式层：卡种、卡组织/网络、发卡地、币种、跨境属性、A2A、本地二维码或钱包是否影响费用与可用性。
3. 硬件与接入层：终端采购/租赁、ECR/网关、SIM 或网络、认证、安装、维修、换机和 API/报表费用。
4. 资金与结算层：毛额或净额结算、扣费时点、结算频率、最低结算额、提现/加急、失败打款、准备金和风险留存。
5. 异常与风险层：撤销、退款、部分退款、拒付、争议申诉、欺诈筛查、人工审核、冻结和证据服务是否额外收费。
6. 合同与商业层：起止日期、最低月费或交易承诺、涨价机制、自动续约、提前解约、服务等级、地域/门店扩展和白标分润条款。

2.6 报价比较的最小输入与输出

在未取得正式报价附件、费率定义、结算规则和至少一份脱敏账单样例前，平台不能将“低费率”“快速到账”或“免费终端”写入对商户的方案承诺。比较必须以同一组输入完成：

• 目标门店数、收银点和终端数量；
• 月交易额、交易笔数、客单价及高低峰特征；
• 现金、银行卡、钱包、二维码、转账、储值和线上支付的预计占比；
• 堂食、桌边、外带、自助机、扫码点餐、预订订金和外卖的交易结构；
• 退款率、争议率、跨境/外币比例及所需支持等级；
• 商户、服务商和平台分别承担或获得的费用、补贴和分润。

输出不能只是一张费率对比表，而应至少包括：年度总成本区间、费用波动来源、资金可用时间、设备与合同锁定成本、异常处理成本、责任方，以及尚未被合同或账单证据覆盖的风险项。

第 3 章 餐饮行业支付场景地图

3.1 场景优先于支付方式

支付方案首先按餐饮动作确认，不按“支付渠道列表”直接落地。每个场景至少记录：参与角色、发起时点、应付金额构成、允许的支付方式、终端/线上入口、成功后业务动作、失败与未知结果处理、退款方式、票据、对账归属。

3.2 混合支付的金额守恒

一笔餐饮账单可能由商品、折扣、税费、服务费、小费、舍入和订金抵扣共同组成。平台应能保留每个金额事件及其来源，至少满足：

应收总额 = 商品金额 - 折扣 + 税费 + 服务费 + 小费 ± 舍入 - 可抵扣预付款

应收总额 = 各支付方式成功金额 + 合法挂账金额 + 合法余额抵扣金额

具体税费、服务费、小费和舍入是否参与计费、是否可退款、能否由顾客承担，均是国家、合同和商户配置问题，不能设为全球默认。

3.3 场景的最小异常集

每一场景至少演练：

• 顾客取消或超时；
• 已扣款/已授权但POS未得到结果；
• 回调延迟或重复；
• 顾客再次支付导致潜在重复扣款；
• 订单金额在支付前后变化；
• 网络中断、终端故障或支付方式切换；
• 部分退款、全额退款、原支付方式不可用；
• 门店营业日切换、终端批次和服务商结算批次不一致。

第 4 章 餐饮支付方案设计

4.1 当前平台支付网关方案与边界

我们作为餐饮 SaaS 软件模板商，提供统一的支付网关能力：餐饮服务商可将支付能力作为其软件方案的一部分销售和运营，而平台负责标准化订单、支付单、交易状态、查询、退款、对账和审计边界。

当前能力不是让每个门店分别直连支付服务商，也不是由 POS 按支付方式自由挑选渠道；而是以餐饮服务商为支付合作配置与运营主体。

当前方案的核心是：服务商级多 PSP 候选配置 + 服务商级生效 PSP 切换 + 伙伴平台进件与支付方式管理 + SaaS 统一交易编排。

推荐的最小实施顺序是：

1. 标准化订单、支付单、退款、对账对象和状态；
2. 建立服务商与支付服务商的一对多配置，以及当前生效服务商的版本化切换；
3. 打通伙伴平台的商户进件状态、商户标识和支付方式开关；
4. 接入首期支付服务商的终端或线上支付能力，并按原服务商保留历史交易查询与退款路径；
5. 后续再建设按支付方式、币种、场景或故障策略进行多渠道路由的网关编排能力。

4.2 线上线下一体化设计准则

• 同一订单可关联多笔支付、退款和调整，但所有关联关系必须可追溯。
• 线上、收银台、桌边、自助机可以使用不同入口；统一的是支付单、状态、凭证、退款和对账规则，而不是强制同一终端。
• 支付成功不自动代表出餐、配送完成、发票已开或会员权益已发；各业务事件应独立触发并可补偿。
• 当前支付合作方选择以服务商范围配置和切换为准；商户进件与支付方式开关以伙伴平台的已确认状态为准。未来若开放按支付方式、币种、场景或故障策略的多渠道路由，应新增独立配置模型和验收，不得复用当前服务商级切换语义。

第 5 章 费用、定价与商户收益

5.1 费用确认框架

与支付服务商讨论费用时，应要求一张“费用地图”，而非只拿到一个百分比报价。

5.2 商户方案比较方法

比较方案应基于商户真实或预估结构：月交易额、交易笔数、客单价、支付方式占比、线上线下占比、退款/争议率、门店与终端数、结算币种、服务支持要求。输出应同时包含：

• 费用测算的输入和假设；
• 不同支付方式下的单笔和总成本；
• 资金到账、运营复杂度和顾客体验差异；
• 不能从报价中确认的项目及待索取账单证据；
• 服务商、平台与商户各自承担的费用和收入。

5.3 顾客附加收费的处理

是否可将特定支付成本、服务费或现金折扣展示给顾客，涉及本地法律、支付网络规则、商户合同和消费者沟通。平台仅提供可配置的金额、展示、票据和审计能力；启用条件必须由目标国家的合规负责人、支付服务商和商户共同确认。

第 6 章 资金流、结算与财务对账

6.1 先问清“钱什么时候归谁”

结算表述需统一使用约定的营业日、时区、截单时间和工作日口径。T+N 本身不足以说明资金何时可用；必须补充起算点、节假日规则、结算频率、准备金、打款失败处理和结算币种。

6.2 餐饮日结与支付结算不能混同

• 门店班次/营业日日结：门店按班次或营业日汇总订单、现金、终端交易和人工差异。
• 支付终端批次：终端或服务商可能按其批次归集交易。
• 服务商结算批次：支付服务商按合同规则扣费和打款。
• 银行到账日：商户银行实际入账时间。
• 财务关账：财务以规则确认收入、费用、退款、税费和差异。

这些批次可不同。产品需要能在同一笔交易上同时记录营业日、交易时间、终端批次、服务商结算批次和银行到账参考。

6.3 对账最小闭环

对账至少覆盖订单、支付、退款、结算、银行流水和费用账单六类来源。差异应按金额、状态、时间、币种、门店、支付方式、渠道参考号和结算批次定位；每条差异记录应有责任方、处理动作、证据附件和关闭结论。

第 7 章 退款、撤销、拒付与异常处理

7.1 撤销和退款的业务边界

退款不仅是支付动作，还应明确影响订单、税费、服务费、小费、优惠分摊、库存、会员权益、票据/发票和报表。任何自动退款规则都应有金额上限、审批权限和审计日志。

7.2 拒付与争议

拒付/争议是支付方或顾客对已发生交易提出异议并按网络或服务商规则处理的过程。餐饮系统至少应保留可定位的订单、金额、时间、门店、桌台/取餐/配送信息、支付凭证、退款记录、员工操作和顾客沟通记录。实际证据要求、时限和资金影响必须以目标支付服务商规则为准。

7.3 结果未知和重复支付处置

当收银台、终端、网关或网络任何一方出现超时，系统不得直接推断失败后重新扣款。标准处置如下：

1. 将支付单标记为“结果未知/待确认”，锁定其与订单的关联。
2. 基于支付单号、幂等键、终端流水或渠道参考号查询支付服务商最终状态。
3. 若已成功，补写支付凭证并完成订单支付状态。
4. 若已失败或已撤销，按权限允许顾客改用其他方式支付。
5. 若短期仍无法确定，生成异常任务；人工根据服务商结果和顾客证明处理。
6. 若确认重复扣款，先确定原交易和重复交易，再按合同与商户规则撤销或退款，完整记录原因和证据。

7.4 本章交接

• 给第 8 章：系统需支持支付单、幂等、回调、主动查询、原始状态、终端流水、退款和对账批次。
• 给第 9—11 章：国家/支付服务商访谈必须逐项确认支付方式、资金流、费用、结算、退款、争议、终端和数据责任。
• 给第 12—13 章：能力应按平台标准/国家配置/服务商定制划分；上线验收必须覆盖支付成功、结果未知、撤销、退款、结算和对账。

附录 A：支付术语表（摘要）

附录 C：餐饮支付场景编号体系

场景编号用于需求、接口测试、上线验收和问题单关联；编号不代表支付服务商能力已经具备。

附录 F：资金流、结算流、信息流确认样例

本部分承接第 1—7 章已定义的参与方、支付生命周期、金额事件与主状态，说明平台应如何把支付能力接入餐饮订单、终端、线上点餐和财务运营流程。本文中的接口、字段、事件与测试项为平台基线；支付服务商的具体协议、原生状态、认证流程和支持边界均应以其书面材料为准。

第 8 章 系统、设备与接口对接

8.1 落地结论：以“订单—支付单—渠道交易”三层模型承接全部支付

平台不应把“订单已支付”直接写入订单记录，也不应以终端页面提示或单次接口响应作为唯一事实来源。建议至少保留以下三层对象，并使用稳定的关联编号：

关键规则

1. 支付单的应付金额、已支付金额、可退金额和未结金额应可独立计算，避免由订单总状态反推金额。
2. 订单可处于“部分支付”或“待补款”等业务状态；这不改变统一支付主状态的语义，具体映射由订单域定义。
3. 一笔渠道支付成功不自动表示订单可以出餐、发票可以开具或商户已经结算；这些事件应由各自的业务规则决定。
4. 对现金、挂账、礼品卡等非网关方式，也应创建可追溯的支付单；但其凭证类型、审批和对账证据可与电子支付不同。

8.2 参考系统边界与事件闭环

sequenceDiagram
    participant C as 顾客
    participant P as POS/点餐端
    participant O as 订单与支付平台
    participant G as 支付网关/服务商
    participant T as 支付终端或支付页
    participant R as 对账与运营台

    C->>P: 确认支付方式与金额
    P->>O: 创建或复用支付单
    O->>G: 发起支付尝试
    G->>T: 展示或执行支付
    T-->>G: 终端/顾客操作结果
    G-->>O: 同步结果或受理回执
    alt 已获得明确结果
        O-->>P: 更新支付主状态
    else 超时、回调缺失或结果不完整
        O-->>P: 标记结果未知，禁止再次扣款
        O->>G: 按渠道交易号主动查询
        G-->>O: 返回最终或仍待处理状态
        O-->>P: 更新状态或进入人工处理
    end
    G-->>O: 异步通知、退款或结算信息
    O->>R: 留存事件、差异和待处理项

• POS/点餐端负责展示可操作状态和防止用户重复发起；订单与支付平台负责幂等、状态映射、金额守恒及审计留痕。
• 支付终端、支付页或服务商同步响应只构成一个证据来源。缺少最终结果、回调未到达或响应冲突时，平台必须标记“结果未知”并查询闭环。
• 支付服务商负责其已约定的渠道执行、状态查询和事件通知；其具体 SLA、离线能力、终端连接方式及字段以合同和接口文档为准。
• 此图不表达资金结算关系；清分、商户结算和银行到账应沿用第 6 章的独立状态与证据。

8.3 终端、POS 与点餐端的集成规则

8.3.1 终端集成模式与待确认边界

8.3.2 终端成功不等于订单最终确认

终端显示成功、打印签购单、终端返回批准码，均可能是重要证据，但不应绕过平台支付状态机。平台应同时满足：

• 终端请求必须携带或可回查到支付单号、订单号、金额、币种、门店和终端标识。
• 平台收到明确成功时，先校验金额、币种、关联关系和幂等键，再写入“已支付”或“已授权”等主状态。
• 终端成功但平台未拿到可验证结果时，支付单进入“结果未知”；收银员界面显示“请等待确认/联系门店处理”，而不是提示再次付款。
• 终端失败不必然说明顾客未被扣款；若存在超时、断网或渠道响应不完整，也应按“结果未知”处理并查询。
• 终端交易凭证、签名/持卡人验证信息的留存范围、可见性和保存期限，应由支付服务商合同及适用合规要求确认；平台不应自行存储不必要的敏感支付数据。

8.3.3 设备和门店管理最小控制项

8.4 接口、事件与状态一致性

8.4.1 支付接口的最小能力集合

接口名称仅描述逻辑能力，不预设任何支付服务商的实际 API 路径或字段。

8.4.2 事件处理规则

1. 先验证身份与完整性：通知来源、签名或约定认证方式不通过时，不更新支付状态；记录安全事件并进入可处理队列。
2. 按事件去重：以渠道事件标识、渠道交易号、事件类型和有效载荷摘要等组合识别重复通知；具体主键以渠道文档为准。
3. 允许乱序到达：不能以“最后收到的消息”覆盖更终态的结果。平台应按状态转换规则、事件发生时间和渠道版本号（如有）判定。
4. 保存原始证据：保存原始状态码、事件时间、接收时间、请求/响应追踪号和脱敏后的关键载荷摘要，供对账和争议处理使用。
5. 结果未知优先查询：超时、网络错误、回调缺失、金额不匹配或状态冲突时，禁止通过再次扣款“解决”问题；先查询，仍不能确定时转人工。
6. 业务副作用后置：出餐、积分发放、发票开具、交付完成等动作应订阅已确认的业务事件，且必须具备幂等控制。

8.5 安全、数据与权限边界

平台设计的目标是最小化接触支付敏感数据，而不是自行解释或替代适用的支付合规要求。具体卡数据环境、责任分配、审计范围、数据保留期和跨境处理限制，均为待支付服务商、合同和适用法规确认项。

8.6 第 8 章验收证据最小包

在接入一个支付渠道、终端集成方式或线上支付方式前，至少收集以下证据，不以“接口已联调”替代实际可运营证明：

本章交接

• 供第 12 章复用：订单—支付单—渠道交易三层模型，及“标准能力/配置/定制”应分别落在支付单、渠道路由、设备和权限层的原则。
• 供第 13 章及附录 I 复用：结果未知查询闭环、事件去重与乱序处理、终端与门店绑定、退款金额上限、对账文件导入均为必验场景。
• 供第 9—11 章外部确认复用：终端集成模式、通知/查询能力、结算文件字段、安全责任和支持边界均须向支付服务商逐项确认。
• 待确认项：具体支付方式的原生状态映射、终端联网/离线机制、回调重试语义、敏感数据边界、设备认证和运维责任。

第 12 章 平台能力边界与配置模型

12.1 落地结论：稳定内核标准化，市场规则和商业合作关系参数化

全球餐饮支付平台不应将单一国家、单一收单方或单一服务商的做法写成平台默认。推荐采用四层边界：

边界判定规则

1. 如果变更会改变交易状态、金额守恒、审计或租户隔离，优先作为平台标准能力治理，不允许由门店临时覆盖。
2. 如果变更依据是国家法规、市场习惯、支付渠道或币种限制，应建模为国家/地区配置，并附证据状态与适用范围，不能在代码中硬编码。
3. 如果变更来自服务商合同、支持模式或白标商业选择，应建模为服务商定制能力；是否可售、可见、可配置须受租户权限约束。
4. 如果变更仅影响个别商户/门店的日常经营，应由商户/门店配置承接，并支持生效时间、审批和回滚策略。

12.2 配置对象与继承优先级

建议采用显式覆盖关系：平台默认 → 国家/地区 → 服务商 → 品牌/商户 → 门店 → 订单/支付单快照。支付单创建后，关键配置应快照化，避免后续改配置追溯不清。

12.3 多租户、白标与权限边界

12.4 支付配置上线前的决策记录

每次新增国家、服务商、渠道、支付方式或终端集成，均应形成一条可审计的配置决策记录。

本章交接

• 供第 13 章复用：每项上线能力应按平台标准、国家/地区配置、服务商定制、商户/门店运营配置四层验收，并验证配置快照和回滚。
• 供第 9—11 章外部确认复用：国家与服务商差异的所有事实均应进入配置记录，且附合同、接口、账单、监管资料或测试证据，而非作为默认规则。
• 供附录 H 复用：支付单应保存路由、金额、终端、文案和权限相关关键配置快照；历史交易不可被后续配置覆盖。
• 待确认项：国家配置来源与维护责任、服务商可自行配置的边界、配置审核人、紧急停用渠道的授权流程。

第 13 章 实施、验收与上线运营

13.1 落地结论：上线以“可收款、可恢复、可退款、可对账、可运营”为完成条件

支付方案上线不是完成一次接口调用，也不是终端出现成功页面。任何渠道或门店组合，至少应证明以下五项闭环：

1. 顾客可在目标餐饮场景完成支付，且订单与支付金额关联正确。
2. 超时、断网、回调缺失或重复操作时，平台不会重复扣款，并能将“结果未知”查询至明确结果或人工处理。
3. 授权、扣款/确认、撤销、退款等适用交易动作能被正确记录、限制和追溯。
4. 交易、退款、结算和费用信息可进入对账流程；支付成功、商户结算、银行到账和财务对账不混为同一状态。
5. 门店、服务商、支付服务商和平台的支持责任、权限、证据和升级路径已被演练。

13.2 分阶段实施门禁

13.3 支付状态机与运营闭环

stateDiagram-v2
    [*] --> 待支付
    待支付 --> 处理中: 发起支付尝试
    处理中 --> 已授权: 获得授权结果
    已授权 --> 已支付: 扣款或确认成功
    处理中 --> 已支付: 直接确认成功
    处理中 --> 失败: 明确失败
    处理中 --> 结果未知: 超时、断网或响应不完整
    结果未知 --> 处理中: 查询仍在处理
    结果未知 --> 已授权: 查询确认授权
    结果未知 --> 已支付: 查询确认成功
    结果未知 --> 失败: 查询确认失败
    已授权 --> 已撤销: 撤销成功
    已支付 --> 部分退款: 部分退款成功
    已支付 --> 全额退款: 全额退款成功
    部分退款 --> 部分退款: 再次部分退款
    部分退款 --> 全额退款: 累计退款达到已支付金额
    已支付 --> 待结算: 接收或导入待结算信息
    待结算 --> 已结算: 结算记录确认
    已结算 --> 对账差异: 对账发现不一致
    待结算 --> 对账差异: 对账发现不一致
    已支付 --> 争议中: 接收争议或拒付事件
    已结算 --> 争议中: 接收争议或拒付事件

• 图中主状态沿用第 2 章定义；渠道原始状态必须原样保留并映射，不能用平台状态替代渠道事实。
• “待结算”“已结算”“对账差异”“争议中”是支付后的独立运营状态；它们不回写或抹除“已支付”“部分退款”等金额事实。
• “结果未知”只能通过渠道查询、后续可信通知或授权人工处理转移；不能以重试扣款或超时自动失败替代。
• 状态转换是否适用于某支付方式、撤销窗口、退款能力和争议事件格式，均待以支付服务商的书面材料验证。

13.4 测试设计：从餐饮动作验证到可审计证据

测试用例应首先以餐饮经营动作组织，再映射至支付方式、订单状态和技术事件。每个用例至少保留输入、预期支付状态、预期订单影响、原始渠道证据、平台日志和责任人。

13.5 上线运营责任与异常分级

13.6 监控与经营指标

指标用于发现问题和评估运营效果，不应用于反推未确认的市场结论。指标口径须按支付方式、入口、门店、租户、币种、时间区间和渠道版本可切分。

13.7 发布、回滚与变更治理

1. 发布前冻结本次适用的渠道版本、配置包、终端清单、权限矩阵和验收用例；任何缺项必须明确风险接受人。
2. 试点应限制在可支持、可观察、可回滚的门店与场景范围内。扩面前应复核真实交易、异常、退款和对账证据。
3. 紧急停用支付方式或渠道时，应保留在途支付、结果未知交易和待退款交易的查询与处理路径；不能仅隐藏前端入口。
4. 回滚配置后，历史支付单仍按创建时快照解释；不得让新配置改变已发生交易的金额、路由或权限事实。
5. 每次变更都应更新配置决策记录、验收结果、异常复盘和服务商/支付服务商沟通项，保持当前基线一致。

本章交接

• 供附录 B 复用：状态机的允许转换、结果未知查询原则、结算/对账/争议与支付主状态分离原则。
• 供附录 H 复用：端到端追踪依赖订单号、支付单号、支付尝试号、渠道交易号、终端流水号、退款单号和结算批次号。
• 供附录 I 复用：按“可收款、可恢复、可退款、可对账、可运营”编排上线验收，且每项均要求证据与责任人。
• 供第 9—11 章外部确认复用：合同、接口、终端测试、结算文件、支持 SLA 和异常升级路径是上线放行的必要外部输入。
• 待确认项：试点规模、上线门禁阈值、告警阈值、支持时限、各角色的实际值班与升级安排。

附录 B：交易状态机与状态转换规则

本附录给出平台统一主状态及其转换规则。渠道原生状态、错误码和时间戳应同时保存；不能因映射而丢失原始信息。

B.1 主状态定义与最小字段

B.2 允许转换与处理表

B.3 状态机实现约束

附录 H：支付对接接口字段与交易流水号规范

本附录定义平台对接时建议使用的逻辑字段和编号关系。字段名可按内部命名规范调整，但语义、唯一性和关联规则不应改变。

H.1 核心对象及编号

H.2 创建支付单与发起支付尝试字段模板

H.3 渠道结果、通知与查询字段模板

H.4 退款、撤销与结算字段模板

H.5 关联与留存校验表

附录 I：支付上线验收清单

I.1 使用说明

每一行均应填写“结果、证据链接/编号、责任人、验证环境或门店、验证日期”。“通过”仅表示该条在约定范围内已验证，不表示其他国家、支付方式、终端型号或商户配置已自动覆盖。

I.2 上线基本信息表

I.3 方案、配置与权限验收

I.4 支付、撤销与退款验收

I.5 终端、线上入口与异常恢复验收

I.6 对账、安全与运营验收

I.7 上线放行结论

本章交接

• 本子稿已交付第 8、12、13 章及附录 B/H/I，可由总控按《01-章节总目录与拼装顺序》直接插入。
• 可复用的统一基线：订单—支付单—渠道交易三层对象；“结果未知必须查询闭环”；支付、结算、银行到账、对账状态分离；配置快照和多租户隔离。
• 需要与第 9—11 章联动补齐的外部证据：目标国家/地区资料、支付服务商合同与接口文档、商户账单/结算文件、终端测试资料、支持 SLA 与责任矩阵。
• 合并前核对：不得将本附录中的“待确认”“如适用”改写为服务商或国家既定能力；术语和主状态须与第 2 章保持一致。

第 9 章 国家/地区支付档案

9.1 本章结论与使用边界

国家/地区支付档案不是“支付方式百科”，而是每次进入市场、选择支付合作方或为服务商部署白标方案前的准入材料。档案必须回答四类可执行问题：

1. 门店和顾客在具体餐饮场景中需要什么支付能力；
2. 支付服务商可在何种合同、资金、终端和数据边界下提供该能力；
3. 平台需要哪些可配置字段，不能把哪些本地差异写死为全球默认；
4. 哪些结论已有证据，哪些结论尚不能用于报价、签约或上线承诺。

档案以“市场 × 服务商 × 商户主体 × 支付产品”作为最小核验单元。即使同一国家内，不同商户类型、合同主体、卡种或支付产品也可能适用不同能力、费用、结算和限制；不得将一个商户或一个报价单的结论外推到全市场。

本章只定义档案方法、目录与核验问题。术语、资金和费用概念见第 2、5、6 章；平台配置和系统实施见第 12、13 章。

9.2 档案建立流程

flowchart LR
    A[明确目标市场与商户主体] --> B[收集经营场景和支付需求]
    B --> C[收集监管、合同、接口和账单证据]
    C --> D[填写市场档案与差异清单]
    D --> E[确认合同、资金、数据责任]
    E --> F[输出配置清单和待验证项]
    F --> G[进入技术验证与上线验收]

• 服务商负责提供目标市场、商户组织、经营流程和本地运营约束；支付服务商负责提供合同、能力、结算、费用和合规证据。
• 平台负责将已确认差异转成配置需求、角色权限和数据留痕要求；平台不得仅根据口头说明开启支付能力。
• 图中的“技术验证与上线验收”由第 8、13 章承接；本章输出的是验证输入和责任边界，不替代接口或终端验收。

9.3 国家/地区支付档案卡

每个档案应有唯一编号、适用版本和证据索引。以下字段为必填字段；字段值可以为“待验证”，但不得留空。

9.3.1 证据优先级

支付档案中，优先采用可追溯的一手材料；同一事项出现冲突时，以适用范围明确、版本更新且由责任主体出具的材料为准。

1. 适用监管机构公开文件、适用法律意见或税务顾问书面意见；
2. 已签署合同、费率附件、数据处理协议、结算规则；
3. 支付服务商正式接口文档、终端部署手册、合规证明；
4. 已脱敏的账单、结算单、银行入账记录、交易和退款样本；
5. 服务商书面确认、试点记录和会议纪要；
6. 市场宣传页、口头说明或非适用市场案例（仅可作为线索，不可作为上线结论）。

9.3.2 证据状态标记

9.4 市场目录与建档优先级

以下是建档目录，不表示所列市场存在特定支付偏好、支付法规、服务商覆盖或可用能力。

建档优先级不应按国家数量排序，而应按“已签约服务商或明确商机—首期门店数和交易规模—关键能力缺口—合规和资金风险—可验证资料可得性”排序。高风险市场必须先完成合同、资金、数据和票据链路的证据核验，再进入产品排期。

9.5 多租户、白标与责任映射

国家档案必须明确以下粒度，避免把某服务商或品牌的支付配置泄露、复制或误用于其他租户：

所有档案变更均应明确：变更发起人、适用层级、影响对象、生效条件、回滚方式和需重新取得的证据。

9.6 本章交接

• 向第 10 章提供：服务商访谈需确认的市场范围、门店场景、商户组织、部署责任和证据缺口。
• 向第 11 章提供：支付服务商需确认的合同主体、资金/费用/结算、终端、接口、数据与合规问题。
• 向第 12 章提供：经证实的国家、服务商、品牌和门店配置字段；未验证字段不得设为默认值。
• 向第 13 章提供：每项能力对应的合同、接口、账单、结算单、终端或试点证据，作为验收输入。

9.7 首批国家档案阅读说明

本组国家卡承接第 9.1—9.6 的建档方法，并沿用第 2、5、6 章对授权、支付、退款、清算、商户结算与对账的定义。其作用是帮助白标餐饮 SaaS 在首次沟通时识别应核验的本地支付轨道、签约与资金边界，而非替代当地法律意见、收单合同或商户部署验证。

9.8 美国

1. 国家卡摘要与证据状态

• 适用范围：美国境内餐饮商户的卡受理、即时账户到账候选轨道，以及借记卡相关规则核验。
• 证据状态：已验证联邦支付基础设施与借记卡规则范围；已验证一份卡网络面向快餐商户的受理资料。未验证任何州级规则、餐厅实际支付偏好、特定 PSP 覆盖、费率或商户结算安排。

2. 已验证的支付与监管基础

• 美国联邦储备系统说明，FedNow 是供美国存款类金融机构使用的即时支付服务；其提供银行间清算和结算，支持通过参与机构账户发起的即时付款。它不是由联邦储备系统直接向消费者或商户提供的支付 App。来源：Federal Reserve — FedNow Service（访问：2026 年 10 月 9 日）。
• 美国《Regulation II》涵盖电子借记卡交易的交换费标准及网络排他/路由限制；联邦储备系统明确说明，规则禁止发行方或网络将可处理交易的非关联网络数量限制在少于两个，并禁止妨碍商户在已启用网络中选择路由。来源：Federal Reserve — Regulation II（访问：2026 年 10 月 9 日）。
• Visa 面向美国快餐商户的官方受理指南将实体到店的磁条、芯片和非接触交易，与电商、电话订购及移动 App 等非实体卡场景分开说明；该资料也覆盖授权、欺诈和争议风险。此为卡网络资料，仅证明该网络的受理指引，不证明任一餐厅或收单方已支持全部方式。来源：Visa — Payment Acceptance for U.S. Quick-Service Restaurants（访问：2026 年 10 月 9 日）。

3. 餐饮支付场景含义

• 已验证的餐饮直接材料：Visa 的快餐商户指南可支持把柜台/自助点餐的卡在场受理，与线上自取、支付链接或 App 的卡不在场受理分别建模；授权、支付结果、退款和争议证据不能共用一个“已支付”字段。
• 候选场景，不构成可用性结论：FedNow 可作为账户到账型付款的本地轨道候选，但公开资料不证明餐饮 POS、桌码或外卖订单可直接接入，也不证明顾客或商户的金融机构均已开通。
• 待验证：餐桌边终端、拆账、小费、订金/预授权、外卖代收、离线支付及州级消费者/附加费规则。

4. 平台配置与集成影响

• 平台应将卡在场、卡不在场、账户到账和人工确认付款分为不同支付方式及证据链；订单支付状态必须保留渠道交易号、终端流水号或账户到账参考号。
• 对借记卡收单方案，应将“可用网络、路由责任、收单方和处理方”保留为收单配置与合同字段，不能用一家 PSP 的路由实现推导为全国能力。
• 对账户到账型候选方式，应设计“付款指令已创建—支付方确认—渠道查询成功—订单可履约”的查询闭环；不得把顾客提交付款意图直接记为收款成功。

5. 与服务商/PSP 的确认问题

• 合同与资金：餐饮商户、服务商、收单方和平台各自是否为签约主体、收款主体、退款责任主体；资金是毛额还是净额结算。
• 卡受理：柜台、手持桌边、自助机、桌码和线上自取分别支持哪些卡在场/卡不在场方式；终端是否支持芯片、非接触与小费输入。
• 借记卡：具体收单产品的网络路由处理、账单拆分、退款及争议资料如何提供；是否受 Regulation II 适用范围影响，应由合规/收单方确认。
• 即时账户到账：是否实际接入 FedNow 或其他轨道、商户和付款人金融机构覆盖、交易状态查询、退回/退款处理及对账文件。
• 餐饮流程：分单、拆账、预授权、订金抵扣、缺货部分退款、外卖取消的可用性与证据字段。

6. 来源与证据边界

• Federal Reserve — FedNow Service（访问：2026 年 10 月 9 日）：证明 FedNow 的机构级即时清算结算定位，不证明特定银行、商户或 POS 已可用。
• Federal Reserve — Regulation II（访问：2026 年 10 月 9 日）：证明电子借记卡交易规则范围，不构成具体交易成本、路由结果或合同报价。
• Visa — Payment Acceptance for U.S. Quick-Service Restaurants（访问：2026 年 10 月 9 日）：证明 Visa 指引所述快餐受理场景，不代表所有卡网络、收单方和餐厅的实际支持。

9.9 加拿大

1. 国家卡摘要与证据状态

• 适用范围：加拿大零售支付服务商监管边界、全国支付清算基础设施，以及餐饮商户对接时的账户与支付服务核验。
• 证据状态：已验证 PSP 登记监管信息与 Payments Canada 公布的系统范围。未验证餐饮业支付偏好、特定借记网络受理、双语界面义务、各省经营规则、费用和结算安排。

2. 已验证的支付与监管基础

• 加拿大银行说明，受《Retail Payment Activities Act》约束的 PSP 必须向其登记；登记表中的 PSP 受风险监管与执法，但加拿大银行明确表示，登记不等同于对 PSP 的许可或背书。来源：Bank of Canada — Registry of payment service providers（访问：2026 年 10 月 9 日）。
• Payments Canada 说明其拥有并运营加拿大的支付清算与结算基础设施及相关规则/标准；其公开目录列出零售批量支付系统 ACSS、加拿大元高价值支付系统 Lynx，并说明 Real-Time Rail 是拟支持全天候、数据丰富付款的全国实时支付系统。来源：Payments Canada — Payment systems（访问：2026 年 10 月 9 日）。

3. 餐饮支付场景含义

• 以上资料不提供餐饮商户、POS 终端、桌边支付或二维码支付的直接运营证据。因此，柜台、桌边、自助点餐、扫码点餐、预订订金和外卖场景均须与候选收单方/PSP 逐项验证。
• 若服务商拟接触顾客资金、代商户收款或提供支付服务，不能仅依据“已在加拿大经营”判断其监管状态；需按实际业务模式核验是否在 RPAA 范围及登记状态。

4. 平台配置与集成影响

• 支付合作方主数据应记录法定主体、监管/登记查询证据、适用省份、支付产品、资金责任和结算账户，而不将 PSP 名称视为能力标签。
• 平台应允许按门店和支付渠道配置收单方；线上支付、终端支付与手工转账入账应使用统一支付单，但保留不同的渠道参考号和查询接口。
• 对加拿大实时支付或批量支付相关能力，状态机必须区分“顾客/付款方结果”“机构间清算结算”“商户合同结算”，不得因基础设施存在而预置到账时效。

5. 与服务商/PSP 的确认问题

• 是否属于 RPAA 登记主体，或由何主体提供、持有和监管支付服务；登记状态、商号与合同主体如何核验。
• 是否支持餐饮收银台、桌边、自助机、线上自取、预订订金、外卖及混合支付；每个场景各自的终端、API 和退款边界。
• 对实时、批量或账户到账方式，具体参与机构、付款状态、退回/退款、通知、查询、结算文件和银行到账如何处理。
• 是否有英语/法语顾客支付页、收据和客服要求；适用范围由服务商与当地合规负责人确认。

6. 来源与证据边界

• Bank of Canada — Registry of payment service providers（访问：2026 年 10 月 9 日）：证明登记与监管边界，不证明 PSP 获得执照、商户能力或产品适配。
• Payments Canada — Payment systems（访问：2026 年 10 月 9 日）：证明该机构公开列示的基础设施范围，不证明任一餐厅可直接使用相应系统。

9.10 巴西

1. 国家卡摘要与证据状态

• 适用范围：巴西 Pix 即时支付体系、SPI 清算结算基础设施，以及二维码收款在实体与线上候选餐饮场景中的集成边界。
• 证据状态：已验证由巴西中央银行发布的 Pix、SPI、参与者和商户收款资料。未验证特定 PSP、餐饮门店、终端或外卖平台的签约资格、费率、结算合同和税务票据处理。

2. 已验证的支付与监管基础

• 巴西中央银行说明，Pix 是由其创建的即时支付方案，支持个人、企业和政府实体在任意时段进行秒级资金转移；Pix 交易可通过别名或静态/动态二维码发起，并覆盖个人对企业（P2B）等交易类型。来源：Banco Central do Brasil — Pix（访问：2026 年 10 月 9 日）。
• 巴西中央银行说明，SPI 是其运营的跨支付服务提供方即时支付集中结算基础设施；其为 RTGS，交易一经结算即具终局性且不可撤销。来源：Banco Central do Brasil — Instant Payment System (SPI)（访问：2026 年 10 月 9 日）。
• 巴西中央银行面向商户的说明称，Pix Cobrança 可通过二维码或 Copy-and-Paste 用于实体销售点和电商的即时收款；该页同时说明，参与 Pix 的金融/支付机构必须支持二维码或 Copy-and-Paste 发起的即时 Pix Cobrança。来源：Banco Central do Brasil — Pix and businesses（访问：2026 年 10 月 9 日）。

3. 餐饮支付场景含义

• 已验证的直接适用范围：Pix Cobrança 的官方说明已覆盖实体销售点和电商即时收款。因此，柜台、桌码支付、线上自取或支付链接式收款可列为需与参与机构验证的候选场景。
• 平台不能把 Pix 的结算终局性等同于餐饮订单已履约、商户已完成合同结算或税务票据已成功开具；这些仍是独立状态。
• 待验证：桌边终端、自动拆账、多人追加点餐、预订订金、外卖平台代收、部分退款的具体 PSP 接口能力及餐饮运营规则。

4. 平台配置与集成影响

• 应支持静态二维码和动态二维码两种候选收款模式，并区分“二维码展示/支付请求创建”“付款通知”“主动查询”“支付确认”“退回或退款”事件。
• 支付单需保存 Pix 交易参考号、订单号、门店/桌台和付款金额；动态二维码应由支付服务商确定其有效期、金额锁定和重复支付处理方式。
• 对 Pix 接入，平台宜提供通知与查询双重确认，并将退款/退回规则做成渠道能力项；不得假定所有参与方支持相同的退回管理接口。

5. 与服务商/PSP 的确认问题

• 合同与资格：候选 PSP 是 Pix 的何类参与者、通过何主体提供商户收款，餐饮商户的开户/KYC 与本地收款账户要求是什么。
• 二维码与 API：实体 POS、桌码、线上收款分别使用静态或动态码；支付结果通知、主动查询、过期、取消、金额变更和幂等如何处理。
• 退款与对账：是否提供 Pix 收款、退回/退款、日交易明细、结算文件和异常查询；订单、Pix 交易、退款和银行流水如何关联。
• 餐饮场景：多人支付、服务费/小费、订金抵扣、缺货部分退款、外卖取消是否支持，及其状态与资金处理规则。
• 税务与票据：支付凭证、收据、电子发票及税务义务是否分开处理，由当地税务资料和服务商书面确认。

6. 来源与证据边界

• Banco Central do Brasil — Pix（访问：2026 年 10 月 9 日）：证明 Pix 的官方支付方案和二维码/交易类型，不证明所有商户或 PSP 已开通。
• Banco Central do Brasil — Instant Payment System (SPI)（访问：2026 年 10 月 9 日）：证明机构间清算结算架构和终局性，不证明商户结算周期。
• Banco Central do Brasil — Pix and businesses（访问：2026 年 10 月 9 日）：证明官方所述的实体与电商收款候选范围，不证明餐饮专属功能或某 PSP 的接口实现。

9.11 英国

1. 国家卡摘要与证据状态

• 适用范围：英国支付服务监管边界、账户到账型 Faster Payments 基础设施，以及餐饮 SaaS 在代收、预订或线上付款模式下的责任核验。
• 证据状态：已验证 FCA 对支付服务/商户收单的监管说明和 Pay.UK 的 FPS 基础设施资料。未验证英国餐饮支付偏好、费率、商户结算、具体开放银行/账户到账产品或任何 PSP 能力。

2. 已验证的支付与监管基础

• FCA 说明，英国《Payment Services Regulations 2017》所列支付服务包括支付交易执行、卡支付、支付工具发行、商户收单、汇款、账户信息服务及支付发起服务；以经常性业务提供这些服务的主体通常需要申请相应授权或登记。来源：FCA — Payment Services Regulations 2017 and Electronic Money Regulations 2011（访问：2026 年 10 月 9 日）。
• FCA 特别提示，线上平台、撮合卖方与客户的业务或预订服务，若以自身名义先收顾客资金再转给卖方，可能属于支付服务；该页要求存在疑义时寻求独立法律或合规意见。来源：FCA — Consider if you provide payment services（访问：2026 年 10 月 9 日）。
• Pay.UK 的公开原则文件将 Faster Payments System（FPS）描述为英国 24×7 实时支付系统，支持英国银行账户之间向企业、个人等付款；其标准资料另说明 FPS 相关规范可供技术和 API 设计参考。来源：Pay.UK — Faster Payments System Principles（访问：2026 年 10 月 9 日）；Pay.UK — Accessing Standards（访问：2026 年 10 月 9 日）。

3. 餐饮支付场景含义

• 已验证的责任提示：若餐饮 SaaS、服务商或预订平台代餐厅持有顾客订金、餐费或退款资金，不能仅按“软件服务”处理；应先核验 FCA 监管边界和实际合同/资金路径。
• FPS 是账户到账型候选支付基础设施。其基础设施资料不直接证明餐厅柜台、桌边支付、扫码点餐或预订订金可通过特定 PSP 接入，亦不证明商户资金结算安排。
• 待验证：餐厅的卡、钱包、账户到账、二维码、分单、小费、预授权、外卖和取消退款实践，以及服务费/附加费与票据规则。

4. 平台配置与集成影响

• 预订订金、外卖代收、平台代管资金等模式，应以“合同主体—顾客资金持有者—受益商户—退款责任方—监管判断”建模；不可只用订单归属代替资金归属。
• 对账户到账方式，平台应保留付款人确认、支付服务商状态、参考号、入账确认和退款/回款处理的分层状态；不得把客户提交银行付款立即等同订单已支付。
• 英国 PSP 配置需将授权/登记主体、商户收单与支付发起产品、适用渠道、通知/查询和对账文件作为独立可配置项。

5. 与服务商/PSP 的确认问题

• 是否存在平台或服务商先收后付、资金池、预订代收、外卖代收或退款代付；对应 FCA 监管分析、签约主体与资金保护安排是什么。
• 是否支持柜台、手持终端、自助机、桌码、支付链接、线上自取和预订订金；各渠道是卡、账户到账或其他产品。
• 对 FPS/账户到账候选方案，支付发起、付款确认、误付处理、退款、查询、通知、订单关联和结算报表如何实现。
• 对餐饮高频异常，重复支付、顾客取消、缺货、部分退款、拆账、小费与服务费分别如何处理并对账。

6. 来源与证据边界

• FCA — Payment Services Regulations 2017 and Electronic Money Regulations 2011（访问：2026 年 10 月 9 日）：证明监管定义和主体范围，不替代针对业务模式的法律意见。
• FCA — Consider if you provide payment services（访问：2026 年 10 月 9 日）：证明平台/预订业务存在监管判断点，不直接判定本平台属于受监管主体。
• Pay.UK — Faster Payments System Principles（访问：2026 年 10 月 9 日）：证明 FPS 的系统定位，不证明任一餐厅或 PSP 已连接。

9.12 德国

1. 国家卡摘要与证据状态

• 适用范围：德国零售支付基础设施、SEPA 技术标识与支付机构监管语境的初步核验。
• 证据状态：已验证德国联邦银行对零售支付系统、SEPA 清算和德国 IBAN 结构的官方说明；已验证 BaFin 资料对 ZAG 支付机构术语的引用。未验证餐厅受理偏好、girocard 受理、具体收单/钱包覆盖、费率、结算或税务票据。

2. 已验证的支付与监管基础

• 德国联邦银行说明，其 Retail Payment System（RPS）是处理非紧急付款的平台，包括 SEPA-Clearer；该清算服务处理欧元计价的境内和跨境转账、直接借记和卡支付。来源：Deutsche Bundesbank — RPS Retail Payment System（访问：2026 年 10 月 9 日）。
• 德国联邦银行说明，SEPA 的支付处理遵循欧洲支付委员会的规则簿与实施指南，并以 ISO 20022 XML 报文为技术基础；德国 IBAN 为 22 位。来源：Deutsche Bundesbank — The technical standard in SEPA（访问：2026 年 10 月 9 日）。
• BaFin 的英文反洗钱解释文件将支付机构和电子货币机构表述为《Payment Services Supervision Act》（ZAG）所定义的机构。该资料仅支持术语与监管语境，不是对某候选 PSP 的许可确认。来源：BaFin — Anti-Money Laundering Act interpretation (English PDF)（访问：2026 年 10 月 9 日）。

3. 餐饮支付场景含义

• 以上一手资料不直接说明德国餐厅的支付偏好或特定卡网络/钱包受理。因此，柜台、桌边、自助机、桌码、预订订金、外卖和线上支付的实际方式及可用性均为待验证项。
• 对需要以银行账户收款、退款或结算的方案，德国 IBAN 长度及 SEPA 标识/报文要求应作为支付服务商和结算账户校验的输入，而不是前端自由文本假设。
• 不应从“RPS 处理卡支付”推导任意餐饮 POS 已支持某一支付方式，更不能据此推导费率或到账天数。

4. 平台配置与集成影响

• 结算账户模型需要支持 ISO 国家码校验、德国 22 位 IBAN 格式和按 PSP 返回的账户验证结果；不应仅使用本地账号字段。
• 银行转账、直接借记与卡支付必须保留不同的支付方式、渠道状态与对账参考；相同的 SEPA 基础设施并不意味着商户端支付确认语义相同。
• 候选 PSP 配置中应分开记录其受监管主体、收单产品、线上/线下接入、退款能力、账单/结算文件与数据处理地点。

5. 与服务商/PSP 的确认问题

• 具体合同主体在德国/EEA 的许可、护照或代理安排如何核验；谁是商户收单、支付发起、资金持有和退款责任主体。
• 柜台、桌边、自助机、线上自取和预订是否分别支持卡、账户到账、直接借记或其他方式；终端/SDK 和回调能力分别是什么。
• 商户结算账户是否必须使用何种验证/IBAN 格式；入账、退款、退回、拒付和对账参考号如何提供。
• 餐饮特有流程（多支付方式、拆账、小费、服务费、订金抵扣、部分退款）是否有合同与接口支持证据。

6. 来源与证据边界

• Deutsche Bundesbank — RPS Retail Payment System（访问：2026 年 10 月 9 日）：证明 RPS/SEPA-Clearer 所述处理范围，不证明商户端受理能力。
• Deutsche Bundesbank — The technical standard in SEPA（访问：2026 年 10 月 9 日）：证明 SEPA 技术基础及德国 IBAN 结构，不证明结算时效或接口可用性。
• BaFin — Anti-Money Laundering Act interpretation (English PDF)（访问：2026 年 10 月 9 日）：只支持 ZAG 相关术语语境；候选 PSP 许可必须通过适用登记/监管资料另行核验。

9.13 阿拉伯联合酋长国

1. 国家卡摘要与证据状态

• 适用范围：阿联酋零售支付服务/卡组织监管类别，以及 Aani 即时支付在商户二维码收款中的公开范围。
• 证据状态：已验证 CBUAE 的零售支付服务和卡组织监管类别，以及由其子公司运营的 Aani 面向商户的公开说明。未验证餐饮门店的实际受理覆盖、特定收单方、旅游餐饮的多币种结算、费率或结算安排。

2. 已验证的支付与监管基础

• CBUAE《Retail Payment Services and Card Schemes Regulation》说明，零售支付服务受许可框架约束；公开列示的类别包括支付账户发行、支付工具发行、商户收单、支付聚合、境内/跨境资金转移、支付代币、支付发起和账户信息服务，卡组织亦需取得许可。来源：CBUAE Rulebook — Retail Payment Services and Card Schemes Regulation（访问：2026 年 10 月 9 日）。
• Al Etihad Payments（AEP）说明，Aani 由其运营，AEP 是 CBUAE 子公司；Aani 通过持牌金融机构和 PSP 提供即时支付。其面向小商户/个体经营者的公开资料称，客户可以通过静态或动态二维码、Request to Pay 或商户标识完成付款。来源：Al Etihad Payments — Aani Help（访问：2026 年 10 月 9 日）。
• CBUAE 的公告说明 AEP 作为 CBUAE 子公司推出 Aani，且该平台由持牌金融机构和 PSP 面向市场提供。来源：CBUAE — Aani launch announcement（访问：2026 年 10 月 9 日）。

3. 餐饮支付场景含义

• 已验证的候选商户场景：Aani 官方资料已明确小商户/个体经营者的静态/动态二维码、Request to Pay 和商户标识付款。餐饮柜台或桌码可将这些列入候选方案，但是否适用于具体餐厅类型、法人和收单产品，仍须通过 PSP 和试点确认。
• CBUAE 的监管分类表明，商户收单与支付聚合是需要按许可/主体核验的服务类别；餐饮 SaaS、白标服务商若参与代收或聚合，不能仅凭技术集成判断其角色。
• 待验证：桌边终端、自助机、分单、小费、订金、外卖代收、退单退款、游客卡及多币种结算。

4. 平台配置与集成影响

• 支付方式目录需支持卡受理、即时支付二维码、Request to Pay 和其他 PSP 产品的独立启用；“Aani”不应被配置为全量门店默认方式。
• 二维码支付应保存商户标识、二维码类型、金额、支付请求、渠道结果、查询结果和订单关联；动态码有效期、金额可变性及重复付款处理由 PSP 文档确定。
• 平台需把“商户收单/支付聚合/技术服务商”作为不同责任角色记录，并在多租户白标下隔离合同主体、结算账户、门店和终端配置。

5. 与服务商/PSP 的确认问题

• 业务模式属于商户收单、支付聚合、支付发起或纯技术服务的哪一种；相关许可主体、代理/外包关系和客户合同如何安排。
• Aani 是否为目标餐饮法人、门店类型和收单产品开放；静态/动态二维码、Request to Pay、金额限制、通知、查询、退款/退回、对账与商户标识规则是什么。
• 柜台、桌边、自助机、桌码、线上自取、预订订金和外卖分别支持哪些方式；终端、SDK、H5、回调与主动查询证据如何提供。
• 结算币种、商户账户、手续费、结算周期、准备金、拒付与多币种游客支付均应取得目标合同、账单样例和终端/接口文件。

6. 来源与证据边界

• CBUAE Rulebook — Retail Payment Services and Card Schemes Regulation（访问：2026 年 10 月 9 日）：证明受监管服务类别与许可要求，不判定某平台或 PSP 的许可状态。
• Al Etihad Payments — Aani Help（访问：2026 年 10 月 9 日）：证明 Aani 官方声明的商户二维码/请求付款范围，不证明所有餐饮商户已可用。
• CBUAE — Aani launch announcement（访问：2026 年 10 月 9 日）：证明 AEP 与 CBUAE 的公开关系，不替代 PSP 签约和产品可用性验证。

9.14 沙特阿拉伯

1. 国家卡摘要与证据状态

• 适用范围：沙特支付服务监管、mada 的卡/POS 网络，以及 SARIE 即时转账系统的基础设施范围。
• 证据状态：已验证 SAMA 的支付服务法规、mada 和 SARIE 的官方说明。未验证餐饮业的具体支付偏好、特定终端/网关接入、手续费、结算天数、钱包覆盖、税务票据和外卖平台能力。

2. 已验证的支付与监管基础

• SAMA 发布的《Implementing Regulations of Payments and Payment Services Law》说明，其支付及支付服务法实施细则已生效；受该法和实施细则约束的 PSP 与支付系统运营者须遵守相应规定。来源：SAMA Rulebook — Implementing Regulations of Payments and Payment Services Law（访问：2026 年 10 月 9 日）。
• SAMA 说明，mada 是其拥有的国家支付系统，通过 POS、ATM 和电商等渠道连接至中央支付系统；其 POS 服务用于商户/门店的电子支付，并可使用支持近场通信的 POS 设备。来源：SAMA — mada（访问：2026 年 10 月 9 日）。
• SAMA 说明，SARIE 是其拥有的国家支付系统之一，面向本地银行的低金额转账，支持以 IBAN 或替代标识进行全天候即时转账。来源：SAMA — SARIE（访问：2026 年 10 月 9 日）。

3. 餐饮支付场景含义

• 已验证的直接受理线索：mada 官方页面明确覆盖 POS 与电商渠道，因此餐饮柜台、桌边手持机和线上自取可将 mada 受理列为候选能力，并要求收单方提供目标终端/线上渠道的实际支持证据。
• SARIE 的官方资料证明即时账户转账基础设施及替代标识能力；它并不证明餐饮门店可将其作为实时收银支付方式，也不证明可处理订单退款或部分退款。
• 待验证：自助点餐、桌码、预订订金、拆账、小费、服务费、外卖代收、钱包及国际卡受理的具体产品与餐饮规则。

4. 平台配置与集成影响

• 应将 mada 的终端受理、线上受理及其他支付产品分开配置；每种渠道均需独立记录终端型号/认证、渠道交易号、回调、查询、退款、结算和对账文件。
• 对 SARIE 或其他账户到账候选方式，平台必须使用“付款指令/付款人确认—PSP 或银行状态—主动查询—订单履约”的闭环，不能因客户提供 IBAN 或替代标识即修改订单为已支付。
• 多品牌、多门店配置应隔离沙特商户主体、结算账户、终端、支付方式可见性、阿拉伯语/英语顾客文案及当地票据/税务集成，具体法定义务待另行核验。

5. 与服务商/PSP 的确认问题

• 合同与监管：各参与主体是否为 SAMA 监管的 PSP、支付系统运营者、代理或技术服务商；商户签约、资金持有、退款与投诉责任如何划分。
• mada：柜台、手持、桌边、自助机、线上自取、支付链接分别是否支持；NFC、终端管理、撤销/退款、查询、收据、对账和异常恢复如何实现。
• SARIE/账户到账：是否存在面向餐饮商户的收款产品；付款确认、客户取消、误付、退款/退回、订单引用、通知及结算报表规则是什么。
• 餐饮特有能力：分单、多人付款、小费、服务费、订金抵扣、缺货部分退款、外卖取消、跨门店/多品牌对账是否有合同和接口证据。
• 票据与税务：支付收据、税务票据、电子发票、退款税务处理及数据保存要求应由当地税务/合规资料另行核验。

6. 来源与证据边界

• SAMA Rulebook — Implementing Regulations of Payments and Payment Services Law（访问：2026 年 10 月 9 日）：证明法规实施及受规制主体的一般遵从义务，不判定任何公司已获许可。
• SAMA — mada（访问：2026 年 10 月 9 日）：证明 mada 在 POS 与电商等渠道的官方范围，不证明所有终端、收单方或餐饮商户已接入。
• SAMA — SARIE（访问：2026 年 10 月 9 日）：证明即时转账系统及公开标识方式，不证明其为餐饮实时收银、退款或商户结算产品。

第 9 章合并交接（A 包）

• 合并位置：本文件接在 30-市场档案与外部确认.md 的第 9.6 节之后，作为第 9.8—9.14 节；随后回到原第 10 章。
• 给第 10 章（餐饮服务商确认）的输入：七个市场均需确认首期门店业态、柜台/桌边/自助/桌码/线上/预订/外卖场景、商户主体、当地收款账户、设备部署和一线支持责任；巴西 Pix、阿联酋 Aani、沙特 mada 的公开基础设施资料可作为访谈起点，不可替代商户可用性证明。
• 给第 11 章（支付服务商确认）的输入：以本文件每国“确认问题”为最低访谈清单，取得合同主体、许可/登记、资金路径、费用附件、结算文件、终端/接口文档、异步通知与查询、退款/争议、账单与对账样例。
• 未解决的共性证据缺口：各市场的餐饮支付偏好与业态差异；特定 PSP、商户类别、终端与线上渠道的已开通能力；KYC、税务票据、服务费/小费、附加费规则；费率、结算周期、准备金、拒付和退款时效。以上均须在目标服务商、商户合同与试点中验证后，才可写入国家档案的“已验证”字段。

9.15 澳大利亚

国家卡摘要

• 适用范围：澳大利亚首期白标餐饮 SaaS 的支付档案起始卡，覆盖门店受理卡支付及非卡支付的配置与外部核验，不构成任一收单产品的上线承诺。
• 证据状态：支付卡附加费规则与卡网络监管信息已验证；特定餐饮业态、终端、在线支付、退款、结算与商户准入均待以候选服务商材料核验。

已验证的支付与监管基础

• 澳大利亚储备银行（RBA）说明，其指定卡网络为 eftpos、Mastercard 和 Visa；自 2026 年 10 月 1 日起，这些网络已实行通常禁止按持卡人支付方式另收卡支付附加费的规则。该限制针对“因使用卡而加收”的费用，不等同于周末、公共假期或服务费等与支付方式无关的收费。RBA：卡支付附加费取消常见问答（访问：2026 年 10 月 9 日）
• RBA 同时说明，商户仍会发生收单服务成本，服务商可能分别收取终端租赁、交易处理或其他支付相关服务费用；这些服务费用与向顾客加收“卡支付附加费”是不同概念。 RBA：商户卡支付成本与附加费结论摘要（访问：2026 年 10 月 9 日）
• RBA 的卡支付监管资料明确将指定信用、借记和预付卡系统，以及借记卡路由和卡号令牌化等列为监管关注范围。该资料不列明具体服务商或餐饮商户的产品资格。 RBA：卡支付监管资料（访问：2026 年 10 月 9 日）

餐饮支付场景含义

• 对堂食收银台、桌边和自助点餐等需要受理卡的场景，产品应将“顾客支付方式”“菜单/订单服务费”“周末或节假日附加费”拆分建模；不得把任一金额项自动映射为卡支付附加费。
• 顾客可否使用特定卡网络、移动钱包、线上卡支付或账户到账户方式，以及这些方式可否用于预订订金、外卖、部分退款和小费，公开监管资料未按餐饮场景证明，均为待验证项。

平台配置与集成影响

• 国家层：配置 AUD、支付方式展示、顾客价目展示规则与支付费账单字段；“卡支付附加费”不得作为默认可启用功能。
• 商户/门店层：分别配置订单服务费、营业日相关收费、支付方式启用、终端与收单账户；保留支付方式、费用项目、原始渠道交易号和退款关联。
• 对接层：候选 PSP 必须用接口/终端文档验证 CP、CNP、终端小费、撤销、部分退款、异步结果查询和结算文件；不能由 RBA 规则推断。

与服务商/支付服务商的确认问题

• 合同与费用：商户接受卡支付的收单服务费、终端费及其他费用如何列示；报价是否将其与订单服务费、周末收费分开。
• 终端与场景：桌边、柜台、自助机和扫码/线上订单各支持哪些支付方式；失败、结果未知、重复支付如何查询和处置。
• 数据与对账：支付方式、终端流水、退款、手续费与商户结算单怎样关联；结算和银行到账是否为独立状态。
• 合规：候选方案对卡网络附加费规则的适用范围、例外及配置限制由签约 PSP 确认。

来源与证据边界

• 一手来源共 3 项：RBA（监管机构）卡支付附加费常见问答、RBA 结论摘要、RBA 卡支付监管资料，均见本卡“已验证”部分（访问：2026 年 10 月 9 日）。
• 以上来源不证明任一 PSP 已接入、餐饮商户已获准受理、费用报价、结算时效、退款政策或具体终端能力。

9.16 日本

国家卡摘要

• 适用范围：日本餐饮门店线下受理、线上订单及储值/预付类方案的核验起点；本卡不将公开监管或卡网络资料外推为全国餐饮支付偏好。
• 证据状态：支付体系、资金移转及第三方预付支付工具监管边界已验证；二维码钱包的餐饮普及度、服务商覆盖、票据和结算安排待验证。

已验证的支付与监管基础

• 日本银行将支付结算系统定义为由设施、共同规则和协议构成的安排，并说明 BOJ-NET、Zengin System 等是日本支付结算体系的一部分；该资料属于体系说明，并非商户受理产品说明。 日本银行：支付结算系统概览（访问：2026 年 10 月 9 日）
• 日本金融厅（FSA）说明，非存款类机构从事资金移转业务须按《支付服务法》取得相应许可或登记；其公开说明也区分预付支付工具与资金移转服务。 FSA：金融科技支持台—支付服务与资金移转说明（访问：2026 年 10 月 9 日）
• JCB 的官方商户材料公开说明 JCB Contactless 的受理标识及接触式/非接触式终端受理相关信息；该材料仅证明卡网络发布的商户受理说明存在。 JCB：JCB Contactless 商户服务（访问：2026 年 10 月 9 日）

餐饮支付场景含义

• 堂食桌边、柜台和自助机若选择接触式或非接触式卡受理，应要求 PSP/收单方确认终端认证、受理品牌、交易结果回传、撤销和退款接口；JCB 的公开页面不证明任一终端或门店均已支持。
• 预付余额、礼品卡或第三方钱包若被用于餐饮消费，须先判断该安排是商户自有闭环工具还是可能落入第三方预付/资金移转监管边界；具体结构及责任为待验证项。
• 扫码点餐、预订订金、外卖线上支付及小费的常见做法没有在本卡一手资料中获得餐饮专属证据，均为待验证项。

平台配置与集成影响

• 国家层：配置 JPY、日文支付提示、支付方式与票据字段；将卡、资金移转、预付余额作为不同资金工具，不可统一标记为“已结算”。
• 品牌/商户层：保存实际收款主体、受理品牌、终端型号、预付计划主体与退款责任方；储值/礼品卡需独立记录余额、发行、核销和退款事件。
• 对接层：为终端交易和线上交易保留支付方式原始状态、授权/扣款语义、查询与回调证据；是否具备这些能力以目标 PSP 接口文档为准。

与服务商/支付服务商的确认问题

• 主体：餐饮商户、收单方、预付发行方、资金移转服务方分别是谁；是否存在需由当地持牌主体承担的职责。
• 终端：柜台、桌边、自助机是否支持目标卡品牌与非接触式受理；签购单、电子小票和退款凭证如何提供。
• 线上：桌码、预订和外卖的支付页/跳转/回调/查询机制，及支付成功但订单未更新的处置路径。
• 票据与资金：支付收据和税务票据如何分别生成；具体结算、退款与争议规则以合同、账单和试点核验。

来源与证据边界

• 一手来源共 3 项：日本银行（支付体系）、FSA（资金移转与预付支付工具监管说明）、JCB（网络商户材料），均见本卡“已验证”部分（访问：2026 年 10 月 9 日）。
• 以上来源不证明某一二维码/钱包在餐饮业的市场占比，亦不证明候选 PSP、终端或线上渠道的可用性。

9.17 新加坡

国家卡摘要

• 适用范围：新加坡门店线下、统一二维码及本地转账相关餐饮支付方案的国家配置起点。
• 证据状态：支付服务监管框架、SGQR、FAST、PayNow 与统一 POS 终端的官方描述已验证；各商户的开户、受理范围、退款和结算安排待验证。

已验证的支付与监管基础

• 新加坡金融管理局（MAS）说明，《Payment Services Act 2019》对支付服务提供者实行许可与监管，并对支付系统进行监督。 MAS：Payments（访问：2026 年 10 月 9 日）
• MAS 的电子支付资料说明：SGQR 是可受理国内和国际支付方案、电子钱包及银行支付的通用二维码；FAST 是参与银行间的新元电子转账服务；PayNow 基于 FAST 的中央地址机制；UPOS 可在单一终端受理主要借记卡、信用卡及其非接触/手机形态。 MAS：E-Payments（访问：2026 年 10 月 9 日）

餐饮支付场景含义

• 对柜台、桌边和自助机，UPOS 是可供候选 PSP 验证的统一终端方向；对桌码点餐和预订页，SGQR、FAST/PayNow 可作为候选轨道。公开资料不证明每个餐饮商户、每一支付 App 或每一终端均可接入。
• 平台不得把扫描 SGQR、收到 PayNow 付款提示、订单标记已支付和商户完成结算混为同一状态；需由 PSP 定义查询、回调、撤销和退款证据。
• 外卖、订金、分账、小费、服务费与支付方式附加费的餐饮适用规则，本卡资料未作直接证明，均为待验证项。

平台配置与集成影响

• 国家层：配置 SGD、SGQR/卡/本地转账的支付方式展示、二维码载体、支付渠道原始交易号和状态来源。
• 门店层：将桌边终端、收银终端、桌码和线上订单的受理账户分别绑定，避免将一个商户标识默认复用到所有门店或白标租户。
• 对接层：接口须区分顾客可见成功、PSP 最终交易状态、退款结果、商户结算文件和银行到账；以候选 PSP 的 API、终端手册与结算样例验收。

与服务商/支付服务商的确认问题

• 许可与主体：签约、收款、结算和 KYC 各由谁负责，服务商是否仅提供软件/实施。
• QR 与终端：目标门店可受理的 SGQR 支付方案、UPOS/终端型号、桌码与自助机集成方式及离线兜底。
• 异常与退款：付款提示、异步回调、主动查询、顾客重复支付、撤销及原路退款的责任、接口和凭证。
• 财务与票据：手续费、结算、银行到账、税务票据和支付收据各自的文件与对账键。

来源与证据边界

• 一手来源共 2 项：MAS 支付监管页、MAS 电子支付基础设施页（访问：2026 年 10 月 9 日）。
• 两项来源证明监管与基础设施说明，不证明单一 PSP 的商户产品、餐饮费率、结算周期、跨境能力或退款时效。

9.18 印度

国家卡摘要

• 适用范围：印度餐饮商户的 UPI 商户受理、二维码和线上支付集成的核验起点。
• 证据状态：RBI 对支付聚合相关监管文件的存在、NPCI 对 UPI 商户受理及接入模式的官方说明已验证；具体支付聚合商、商户准入、费率、结算和餐饮流程待验证。

已验证的支付与监管基础

• RBI 的支付聚合跨境监管通知引用了其《Guidelines on Regulation of Payment Aggregators and Payment Gateways》；说明支付聚合/网关规则是 RBI 监管文件体系的一部分。 RBI：支付聚合跨境监管通知（访问：2026 年 10 月 9 日）
• NPCI 的 UPI 商户常见问答说明：商户需与收单银行合作以启用 UPI；商户可采用 QR、Intent、应用内和 Collect 等接入模式；商户退款需按定义流程向银行提出。 NPCI：UPI 常见问答（访问：2026 年 10 月 9 日）
• NPCI 发布的 UPI 商户生态循环说明，已对 QR 商户方案、Android Intent、虚拟地址相关 API 和商户入驻标准化提出要求。 NPCI：UPI 商户生态合规循环（访问：2026 年 10 月 9 日）

餐饮支付场景含义

• 桌码点餐、柜台扫码和自助点餐可将 UPI QR 作为候选支付轨道；平台必须以收单方确认的商户二维码、支付单和查询结果认定支付状态，不能仅凭顾客出示的成功页面结单。
• 线上预订、外卖和支付链接可评估 Intent、应用内或 Collect 等模式，但具体可用性、超时、退款及风控由支付聚合商/收单银行书面确认。
• 堂食拆账、小费、服务费、预授权及离线支付的适用性没有在本卡资料中取得餐饮专属证明，均为待验证项。

平台配置与集成影响

• 国家层：配置 INR、UPI 支付方式、动态/静态 QR 属性、商户 UPI 标识、支付请求有效期和展示文案。
• 商户层：保存收单银行/聚合商、商户类别代码、收款账户及门店二维码归属；商户类别和开户责任不得由 SaaS 自行假定。
• 对接层：实现支付创建、回调验签、主动查询、退款请求/查询和重复支付拦截；金额、订单号、支付单号与 UPI 原始标识需可对账。

与服务商/支付服务商的确认问题

• 商户入驻：谁承担 KYC、商户类别、收单银行关系和 UPI 标识分配；连锁品牌与门店是否各自开户。
• 渠道：目标商户支持哪些 UPI 集成模式，桌码、收银台、自助机、H5 和外卖是否使用相同或不同产品。
• 异常：顾客支付后无回调、Collect 超时、重复扫码、部分退款、取消订单的查询与人工处理规则。
• 资金与合同：支付聚合商是否直接处理资金、结算文件和费用账单如何提供；不从 RBI/NPCI 公开资料推定。

来源与证据边界

• 一手来源共 3 项：RBI（监管通知）、NPCI UPI 常见问答、NPCI 商户生态循环（访问：2026 年 10 月 9 日）。
• 这些资料不证明候选聚合商已获准服务某餐饮商户，也不证明具体付款方式、退款、结算或收费已适用于该商户合同。

9.19 印度尼西亚

国家卡摘要

• 适用范围：印度尼西亚餐饮门店二维码支付与其他数字支付渠道并行接入的国家档案起始卡。
• 证据状态：QRIS 的国家标准、参与方、商户开通流程和支付服务提供者（PJP）相关资料已验证；特定餐饮场景、服务商合同及资金安排待验证。

已验证的支付与监管基础

• 印度尼西亚银行（BI）说明，QRIS 是用于支付交易的国家二维码标准；提供二维码支付的支付服务提供者须使用 QRIS。其交易处理相关方包括 PJP、交换机构、标准制定机构及国家商户库管理方。 BI：QRIS（访问：2026 年 10 月 9 日）
• BI 的 QRIS 商户说明显示，商户通过 QRIS PJP 注册、提交所需业务资料和文件，经验证后获得 Merchant ID 与 QRIS 码；该说明不等同于任意商户已获准接入。 BI：QRIS—成为商户（访问：2026 年 10 月 9 日）
• BI 的零售支付渠道资料列出 QRIS 交易中的 PJP、交换机构、商户、聚合商和国家商户库管理方，并说明支付工具适用范围另受相应规章约束。 BI：零售支付渠道与服务（访问：2026 年 10 月 9 日）

餐饮支付场景含义

• 柜台、桌边和桌码点餐可将 QRIS 作为候选二维码受理方式；对动态金额、静态码、顾客主扫、退款和交易状态回传，必须以目标 PJP 的产品/API 文档核验。
• 一张 QRIS 码可受理不同支付工具的国家标准属性，并不自动证明餐饮商户的所有品牌、门店、支付 App、线上订单或跨境顾客均可使用。
• 预订订金、外卖、混合支付、小费、服务费、终端卡支付及税务票据关联没有在本卡资料中取得餐饮专属证明，均为待验证项。

平台配置与集成影响

• 国家层：配置 IDR、QRIS 支付方式、Merchant ID、静态/动态二维码类型、二维码有效期、扫码结果与交易查询状态。
• 商户/门店层：Merchant ID、二维码、结算账户和 PJP 合同按实际主体与门店范围隔离；不得跨服务商或租户复用。
• 对接层：设计二维码创建/展示、支付通知、主动查询、撤销/退款、重复支付判定与结算文件导入；支付成功、商户结算和银行到账分别保存。

与服务商/支付服务商的确认问题

• 入驻：候选 PJP 要求的商户资料、主体、门店和 Merchant ID 分配方式；连锁商户的门店管理是否支持。
• 场景：柜台、桌边、桌码、自助机、外卖和预订是否支持 QRIS；二维码由谁展示、金额由谁生成、支付结果如何回写。
• 异常：网络中断、扫码成功但订单未更新、取消、缺货及部分退款的 API、人工操作与对账凭证。
• 合同与资金：费率、结算、留存、争议、服务等级和跨境受理以适用 PJP 合同及账单为准。

来源与证据边界

• 一手来源共 2 项：BI QRIS 说明（含商户开通说明）与 BI 零售支付渠道资料（访问：2026 年 10 月 9 日）。
• 这些来源不证明特定 PJP、银行卡网络、电子钱包或餐饮 SaaS 已互联，亦不证明商户可按某一商业条件受理交易。

9.20 南非

国家卡摘要

• 适用范围：南非餐饮门店卡受理、账户到账户与快速支付轨道的初始核验卡。
• 证据状态：国家支付系统监管职责、第三方支付提供者监管范围及 PayShap 基础设施描述已验证；餐饮商户受理、终端、费用与资金安排待验证。

已验证的支付与监管基础

• 南非储备银行（SARB）说明其依法负责国家支付系统（NPS），并运行、监管、监督该体系；其说明将零售卡交易等支付流纳入 NPS 范围。 SARB：Payments and Settlements（访问：2026 年 10 月 9 日）
• SARB 的监管页说明，NPSD 监管范围包含支付系统、清算结算参与方、系统运营方、第三方支付提供者及电子货币提供者；法律基础包括 NPS Act。 SARB：NPS Regulation（访问：2026 年 10 月 9 日）
• PayInc（支付清算基础设施运营方）公开说明，PayShap 是其面向南非的支付基础设施，并将其描述为现金替代方案；其页亦说明卡支付服务范围包括卡授权、POS、ATM 交换和结算。 PayInc：Our Reach（访问：2026 年 10 月 9 日）

餐饮支付场景含义

• 柜台、桌边与自助点餐的卡受理可作为候选方案，但需要由收单方/终端服务商确认实际受理品牌、NFC、签购单、撤销、退款及终端部署；SARB 与 PayInc 页面不提供该商户级承诺。
• PayShap 可作为账户型或请求付款类方案的候选轨道；是否支持餐饮收银台、桌码、外卖、预订订金和退款，均为待验证项。
• 任何快速支付的顾客可见成功不应替代 POS 订单状态或商户结算状态；平台应保留支付方查询/通知证据并处理结果未知。

平台配置与集成影响

• 国家层：配置 ZAR、卡/账户支付方式、支付渠道来源、终端与 QR/请求付款标识；不预设某一轨道为所有商户默认。
• 商户/门店层：隔离收单合同、结算账户、终端和收款标识；支持柜台、移动桌边、自助机和线上订单分别启用。
• 对接层：候选 PSP 必须提供授权/支付、查询、通知、退款、对账与结算文件的明确证据；平台保存交易、终端、订单和结算批次关联。

与服务商/支付服务商的确认问题

• 主体与许可：实际收单/第三方支付提供者、终端提供者和结算主体分别是谁，所需授权或接入路径是什么。
• 场景与设备：餐厅桌边移动终端、柜台、自助机、线上支付和 PayShap/其他账户支付各自的支持边界。
• 异常：支付结果未知、终端断网、订单未回写、顾客重复支付、撤销和退款的查询及证据要求。
• 财务与票据：交易明细、服务费、退款、结算、银行流水和税务票据如何分开提供和对账。

来源与证据边界

• 一手来源共 3 项：SARB 支付结算页、SARB 监管页、PayInc 基础设施页（访问：2026 年 10 月 9 日）。
• PayInc 对自身服务的陈述属于运营方自述，不能替代商户合同或证明任一 PSP/餐饮门店的具体能力。

9.21 尼日利亚

国家卡摘要

• 适用范围：尼日利亚餐饮门店的账户型即时转账、卡、终端及二维码候选方案的初始核验卡。
• 证据状态：支付服务提供者类别与非银行商户收单监管框架、NIBSS Instant Payment（NIP）基础设施已验证；特定商户受理、网络可用性、终端与结算安排待验证。

已验证的支付与监管基础

• 尼日利亚中央银行（CBN）将卡/支付方案、移动货币运营商、交换与处理机构、支付解决方案服务提供者、支付终端服务提供者等列入其支付服务提供者分类与授权名单，并列出非银行商户收单、二维码、非接触式支付等相关框架。 CBN：Payment Service Providers（访问：2026 年 10 月 9 日）
• CBN 的《Regulatory Framework for Non-Bank Acquiring in Nigeria》说明，非银行商户收单属于受监管服务，并规定相关参与方的最低运营标准、权利和义务。 CBN：非银行商户收单监管框架（访问：2026 年 10 月 9 日）
• NIBSS 说明，NIP 是基于账户号码的线上实时电子资金转账平台，交易消息从发起机构到接收机构即时传递，并提供名称查询、转账与交易状态查询等服务；NIP 的最终机构间结算机制与顾客账户可用资金状态须分开理解。 NIBSS：NIBSS Instant Payment（访问：2026 年 10 月 9 日）

餐饮支付场景含义

• 对柜台、桌边和扫码点餐，账户型转账可作为候选支付方式，但 POS 不得仅凭顾客转账截图确认已支付；必须使用候选 PSP/NIBSS 接入方提供的交易查询、通知和金额/收款方匹配证据。
• 卡、二维码、非接触式与支付终端均在 CBN 支付体系文件中有相应监管/参与者分类线索，但具体餐饮门店的受理产品、终端型号、网络兜底和退款路径均为待验证项。
• 预订订金、外卖代收、部分付款、现金混合支付、小费、服务费和税务票据的本地餐饮规则没有在本卡一手资料中取得直接证明，均为待验证项。

平台配置与集成影响

• 国家层：配置 NGN、账户转账/卡/二维码/现金等方式的独立记录、转账付款参考号、收款方账户校验结果、交易状态查询结果与人工复核状态。
• 门店层：收款账户、终端、二维码、商户主体和支付服务商绑定必须按品牌/门店隔离；资金进入账户的证据不自动代表订单、税务票据或日结已完成。
• 对接层：必须支持异步通知加主动查询、幂等处理、超时后的“结果未知”、重复支付识别、退款/人工退回记录和支付—订单—结算三方对账。

与服务商/支付服务商的确认问题

• 许可与合同：候选机构在 CBN 分类中的授权类别、非银行商户收单责任、商户 KYC、收款和结算主体分别为何。
• 转账流程：名称查询、付款参考号、交易状态查询、超时/失败/重复转账的确认规则，以及服务商客服责任。
• 终端与渠道：卡、POS、二维码、非接触式、桌码、线上链接和外卖渠道的实际产品支持、网络要求与故障兜底。
• 对账与票据：订单支付单、NIP/渠道交易标识、退款、结算文件、银行流水、手续费账单和税务票据的字段及责任边界。

来源与证据边界

• 一手来源共 3 项：CBN PSP 分类与框架页、CBN 非银行商户收单框架、NIBSS NIP 产品页（访问：2026 年 10 月 9 日）。
• CBN 授权名单仅证明所列机构/类别在其页面展示的范围，不证明具体合同、餐饮行业支持、交易成功率、费用、结算周期或网络可用性；NIBSS 页面也不替代接入机构的商户产品和 API 文件。

第 9 章合并交接

• 合并位置：将本文件置于 30-市场档案与外部确认.md 第 9.6 节之后、原第 10 章之前；标题顺序为 9.15 澳大利亚至 9.21 尼日利亚。
• 向第 10 章交接：服务商访谈应逐国确认首期门店形态、商户主体、柜台/桌边/自助/桌码/线上范围、终端与网络条件、票据和一线支持责任。
• 向第 11 章交接：支付服务商对接应取得每国适用合同、授权/KYC、商户受理产品、终端/API、交易查询与回调、退款、对账、结算和费用材料。
• 向第 12、13 章交接：只有经合同、接口、账单、终端或试点证据确认的国家/服务商/品牌/门店字段才能成为配置和验收项；本文件的待验证项不得设为默认值。

第 10 章 与餐饮服务商的确认清单

10.1 会议目标与会前输入

本会议的目标不是让服务商“选择一个支付渠道”，而是确认服务商能否为目标商户持续承担销售、实施、运营、财务协作和一线支持责任。会议前应要求服务商提供目标市场、首期商户范围、典型门店流程和现有支付资料；无上述输入时，会议结论只能记为需求假设。

10.2 服务商经营与商户运营确认

10.3 服务商商业、资金与数据责任确认

10.4 服务商会议的关闭条件

服务商会议结束时，至少应输出：

1. 已签字或书面确认的首期市场、商户和门店范围；
2. 按餐饮场景排序的支付需求，及每项需求的业务负责人；
3. 服务商、商户、平台和支付服务商四方的初步责任矩阵；
4. 支付服务商待确认问题清单，以及每项问题所需证据；
5. 不能进入承诺或排期的开放项、风险和升级路径。

未取得合同主体、收款/结算主体、首期支付场景和一线支持责任时，不应对外承诺完整支付方案。

10.5 本章交接

• 向第 11 章移交：经服务商确认的场景优先级、商户组织、合同和资金责任假设、门店部署需求及待验证问题。
• 向第 12 章移交：服务商白标、租户隔离、权限和支持流程需求；仅经证实的差异可以进入配置设计。
• 向第 13 章移交：首期门店、角色、支持方和业务验收人名单，作为试点与上线组织输入。

第 11 章 与支付服务商的确认清单

11.1 对接原则

支付服务商会议应把每一项能力落到可验证材料：合同条款、费率附件、接口文档、终端材料、结算单、账单、测试记录或支持SLA。演示、销售口头承诺和通用宣传资料只能作为追问线索。

平台、服务商和支付服务商必须分别确认其在合同、资金、数据、设备、交易异常和客服中的责任。任何一方未确认的责任均应登记为开放项，不得由平台默认为己方承担或替对方承诺。

11.2 商业、主体与市场覆盖确认

11.3 支付场景、终端与交易能力确认

11.4 费用、资金、结算与账单确认

11.5 技术、数据、合规与支持确认

11.6 支付服务商会议的关闭条件

在下列材料到位前，不应将“可接入”表述为“可上线”：

1. 商户签约、收款、结算、费用承担和风险责任的主体关系已书面明确；
2. 首期支付方式和餐饮场景的适用条件已有产品或技术证据；
3. 费用报价、附加费用、结算规则和至少一份脱敏账单/结算单样例已取得；
4. 退款、争议、结果未知、重复交易和终端故障的处理边界已确认；
5. 接口、终端、数据和支持材料已移交第 8、13 章进行技术及验收核验。

11.7 本章交接

• 向第 8 章移交：版本化接口/终端/回调/查询/对账资料、技术前置条件及异常处理承诺，供系统集成验证。
• 向第 12 章移交：支付方式、开户主体、结算、费用展示、白标、权限和数据隔离的可配置字段及适用条件。
• 向第 13 章移交：必须在测试、试点和上线后取得的终端交易、退款、结算、账单、银行入账和支持SLA证据。
• 向附录 D、E、J 移交：供应商评估条目、账单字段和未闭合的风险/决策事项。

附录 D：支付服务商能力评估表

决策规则建议：任何涉及合同主体、资金结算、数据责任或安全边界的“待验证/不适用”，均为阻断项；其他能力缺口可由项目负责人明确是否降级、替代或延后。

附录 E：商户费用账单拆解模板

E.1 基础信息

E.2 交易费用拆解

E.3 从交易到银行入账的核对

附录 G：国家支付档案空白模板

G.1 档案标识

G.2 市场与经营场景

G.3 合同、资金与费用

G.4 支付能力、设备与数据

G.5 平台与服务商配置影响

附录 J：风险、待验证事项与决策记录模板

J.1 风险与待验证事项台账

J.2 决策记录

J.3 变更同步提醒

当国家档案、支付合同、费用、结算、终端、数据责任或上线范围发生变化时，使用以下格式，先完成影响分析再更新产物：