1. 选择收银台集成方式
对比 收银台模式（Checkout Mode） 与 前置组件模式（Component Mode），确定前端呈现方案。
2. 选择交易模式
区分 单次 CIT 代收、MIT 按需代扣 与 固定套餐订阅，匹配您的计费模型。
3. 联调与测试卡号
使用沙盒测试卡号模拟支付成功、发卡行拒付及争议场景。
交易模式与能力矩阵
根据您的业务是「单次买断」、「首次绑卡后按需/按量扣款」还是「固定周期会员续费」，选择对应的接口：收银台集成方式速览
HaiPay 将「支付方式」与「收银台集成方式」完全解耦，所有下单申请接口均同时返回payUrl 与 clientToken：
- 收银台模式（Checkout Mode）：使用响应中的
payUrl将用户重定向至 HaiPay 托管页面完成付款，前端几乎零开发量，适合快速验证与上线。 - 前置组件模式（Component Mode）：使用响应中的
clientToken将组合组件嵌入商户自有页面，用户无需跳转即可完成银行卡、Apple Pay 或 Google Pay 付款。
支付方式、编码与限额
银行卡（含信用卡与借记卡）及移动钱包交易默认以 USD（美元） 计价结算（需使用美元对应的appId），单笔代收限额统一为 0.99 – 1000 USD：
inBankCode 与 paymentMethods 互斥二选一规则：- 当指定单一支付方式时，传递
inBankCode（此时paymentMethods不填）。 - 当需要动态控制展示的支付方式组合及由上至下的展示顺序时，传递
paymentMethods（英文逗号分隔，例如"GOOGLE_PAY,CREDIT_CARD"将仅展示这两项且按此顺序自上而下排列；此时inBankCode不填）。 - 该动态排序与展示能力同样支持映射至 全球收银台。
核心 API 与调试入口
完整的请求参数、签名说明、响应示例及在线调试（API Playground），请直接进入 API Reference：银行卡代收申请
POST /usd/collect/apply — 创建单次 CIT 代收订单，支持信用卡、借记卡、Apple Pay 与 Google Pay。MIT 代收申请
POST /usd/mit/apply — 首次绑卡授权扣款（不传 tokenID）或后续商户主动代扣（传 tokenID）。代收订单查询
POST /usd/collect/query — 查询单次代收或 MIT 代收订单的最终支付状态与手续费明细。退款申请与查询
POST /usd/refund/apply 及 退款查询 /usd/refund/refundQuery — 支持全额退款与指定 refundAmount 部分退款。正确请求示例（代收申请 /usd/collect/apply）
- 方式一：指定单一支付方式（传 inBankCode）
- 方式二：动态控制展示方式与顺序（传 paymentMethods）
当仅需拉起银行卡支付时，传入
payType: "BANK_TRANSFER" 与 inBankCode: "CREDIT_CARD"（此时 paymentMethods 不填）：合规、争议与安全要求
- PCI 合规性：直接违反 PCI DSS（支付卡行业数据安全标准）要求。
- 安全隔离不足：第三方
WebView或外层iframe可能无法提供足够的安全隔离。 - 中间人攻击风险：宿主环境可能拦截或篡改持卡人敏感支付数据。
- 钓鱼风险：无法向用户证明当前处于受信任的持卡人数据采集环境。
扩展阅读与专项板块
Apple Pay 与 Google Pay
查看移动钱包的设备、系统、浏览器环境要求（
#supported-browsers）与配置要点。CIT 与 MIT 交易模式说明
深入理解首次在场授权（CIT）与后续商户离线扣款（MIT）的合规机制，以及与周期订阅的选型对比。
MIT 支付与订阅支付
支持地区与测试卡号
查看 支持的 62 个国家/地区 及 沙盒测试卡号。