📄 正文
无论您是交易所、钱包还是平台方，都可以让持卡人在您的应用内一键把 DCS 发行的卡片加入 Apple Wallet 或 Google Wallet（即推送绑卡，Push Provisioning），免去手动输入卡号，直接在手机上完成非接触支付。 作为持牌、自有 BIN 的发卡机构，DCS 的虚拟卡与实体卡均兼容主流数字钱包，您的持卡人可借此在 Apple Pay、Google Pay 等场景完成支付。
Apple Pay 接入方式：DCS 提供 DCSProvisioningSDK 和 POST /open-api/card/v1/digital-wallet-ticket。SDK 负责应用内绑卡和 Apple Wallet 扩展，服务端接口用于获取临时绑卡凭证（ticket）；Apple 权限声明、卡产品和令牌服务配置仍需由接入机构与 DCS 集成团队共同完成。完整步骤见 Apple Pay SDK 安装 与 实现指南。Google Pay 的具体接入方式请在项目启动时与 DCS 确认。
参与方与职责
数字钱包绑卡的本质，是把一张实体/虚拟卡映射为一个钱包内令牌（token）：真实卡号（PAN）不直接落到设备，钱包用令牌代替卡号发起支付，由卡组织维护令牌与真实卡号的映射。整个过程涉及四方：
与 获取卡敏感信息 的关系：钱包绑卡所需的卡数据来源与「敏感信息获取」同源（均涉及真实卡号），因此对 PCI 范围、密钥与白名单有同等要求。两者请配合阅读。
业务流程与各方职责
下表按推进顺序列出当前（人工协同模式下）的关键步骤：为何 DCS 代为提交：钱包绑卡权限由 Visa 卡组织与 Apple/Google 在发卡机构（BIN Sponsor）层级授权。DCS 作为发卡机构统一对接，接入机构无需、也不应直接联系 Apple/Google 或卡组织通道。
应用内绑卡流程（持卡人视角）
Apple Pay 绑卡时，SDK 会先生成originRef，接入机构后端再调用POST /open-api/card/v1/digital-wallet-ticket获取临时绑卡凭证（ticket），最后由 SDK 完成 PassKit 与 DCS / Visa 的加密交互。详见 实现指南。
当前限制与对账
- 无沙盒：Visa 不为绑卡提供沙盒卡，必须用生产卡测试。详见 沙盒环境。
- 不阻塞上线：绑卡能力可在主流程上线后并行推进，不作为发卡上线的前置门槛。
- 令牌生命周期：换卡、补卡、有效期更新时，钱包内令牌由卡组织通过 Visa 生命周期机制自动维护，持卡人通常无需重新绑卡。相关事件通知能力在规划中。
- 绑卡失败：钱包方风控（设备风险、短时间内多次尝试、地区不匹配等）可能拒绝绑卡，DCS 与卡组织无法覆盖钱包方决策；建议引导持卡人 24–48 小时后重试。
- 数字钱包对账：经钱包令牌发生的消费，在每日对账文件中与普通卡交易一并体现，对账文件中是否提供可区分数字钱包交易的标识，将随对账能力完善而明确。详见 对账文件。