跨境支付：商户拓展之常规方案

本文是「跨境支付」系列第五篇，聚焦支付服务商如何拓展跨境电商和游戏商户。

本文根据平台开发文档、服务商官网、监管与政策文件、行业活动资料和支付运营实践整理。截至 2026 年 7 月，平台准入、支付方式覆盖、费率、结算周期、补贴和牌照状态仍可能变化。文中出现的客户数量、转化率、成功率、费率和返佣金额，应被理解为目标示例或验收口径，不应直接作为对外承诺。

商户拓展是一条有明确损耗的漏斗。平台曝光、销售线索、资质审核、沙盒测试、技术接入、首笔交易、首次结算和持续交易之间，每一步都会流失商户。「指数增长」只能用来描述已经发生的结果，不能作为计划前提。

跨境支付的常规拓展方案，要同时解决 5 件事：

1. 找到支付需求明确、准入风险可控的目标商户；

2. 通过平台、服务商和行业渠道稳定获得线索；

3. 用标准产品缩短审核、接入和上线时间；

4. 用真实交易数据判断本地支付、路由和风控是否有效；

5. 让已上线商户持续交易，而不是停留在注册或沙盒阶段。

初期可以接入连连国际、PhotonPay、PayerMax、Stripe、Airwallex 或目标市场的持牌服务商，减少账户、收单、换汇、付款和本地支付的自建成本。不同服务商提供的产品并不相同，资金账户能力不能自动等同于线上收单能力，全球付款也不能自动等同于目标市场的本地支付覆盖。接入前仍要逐项核对合同主体、牌照、商户行业、目标国家、支付方式和结算币种。

市场选择先看支付条件

目标市场不能只按人口或电商增速排序。支付服务商更关心市场里有没有可服务的商户、可接入的支付方式、可承担的风险，以及销售和支持成本。

可以先给候选市场做一张评分表：

一个市场只有在「商户需求、支付能力、获客渠道、交付能力」同时成立时，才适合进入首批范围。

东南亚要按国家拆开

东南亚不是一个统一支付市场。马来西亚、泰国、越南、印度尼西亚和新加坡的银行卡、本地转账、二维码、电子钱包和监管要求都不一样。

Google、Temasek 和 Bain 发布的《e-Conomy SEA 2025》Malaysia 报告显示，马来西亚数字经济 GMV 在 2025 年约为 390 亿美元，其中电商 GMV 约为 200 亿美元，高于 2024 年的 170 亿美元。原始材料中的「2025 年 160 亿美元」与这份报告不一致，不应继续沿用。

支付方式也要按国家归属整理：

KakaoPay 更接近韩国市场，不应混入东南亚首批支付方式。若业务后续进入韩国，再单独评估 KakaoPay、韩国本地卡和本地收单。

泰国央行将 PromptPay 定义为支付基础设施，个人和企业可以通过手机号、身份标识或企业标识关联银行账户。官方资料还列出了企业收款和跨境支付连接能力。对支付服务商来说，这类本地实时支付网络通常比「多支持一个国际钱包」更能改变本地用户的付款体验。

中东先从沙特和阿联酋验证

沙特和阿联酋的卡支付基础较成熟，但本地卡组织、钱包、银行转账和身份验证仍会影响成功率。沙特市场通常要评估 mada、国际卡和本地银行或钱包能力。STC Pay 已向 STC Bank 演进，具体产品、账户和支付能力应以当前银行及合作服务商文件为准。

中东商户拓展还要提前确认：

• 阿拉伯语和从右到左的收银台布局；

• 商户行业是否符合本地准入；

• 当地实体、合同主体和结算账户要求；

• 3D Secure、拒付和退款流程；

• 斋月、节庆和游戏活动期间的流量变化；

• 英语和阿拉伯语客服覆盖时间。

「当地钱包需求增长显著」这类判断不能只引用服务商宣传。更有用的验证方式是让候选商户提供最近 30 到 90 天的支付方式需求、失败原因和客服咨询记录，再决定首批接入方式。

欧美成熟市场看独立站和订阅

欧美市场适合从独立站、SaaS、数字内容和订阅业务切入。国际卡仍是基础能力，但本地转账、钱包、BNPL、税务、拒付和订阅管理会决定商户是否长期使用。

首批产品不需要一次覆盖所有国家，可以先限定：

• 一个合同主体，例如香港公司；

• 两到三个结算币种，例如 USD、EUR、GBP；

• Visa、Mastercard 和一到两个本地方式；

• Shopify、WooCommerce 和 API 三种接入形式；

• 实物电商或低风险数字服务等明确行业。

范围越清楚，销售越容易判断商户是否适合，技术和风控也更容易给出稳定交付时间。

客户分层要对应不同产品

头部平台、独立站、游戏公司和小微卖家的采购方式不同。用同一份销售材料和同一套接入方案覆盖所有客户，通常会让销售周期变长。

冷启动阶段更适合选两个 ICP：

• 欧美独立站卖家，主推国际卡、钱包、插件和多币种结算；

• 东南亚游戏或数字内容公司，主推 Web / PC 充值、本地支付、风控和对账。

ICP 要写到可以被销售直接筛选。至少包括注册地区、目标市场、商品类型、月交易笔数、客单价、现有通道、退款率、拒付率、技术栈和上线时间。只有「做跨境电商」或「做出海游戏」还不够具体。

标杆案例需要可复核数据

标杆案例可以缩短后续销售周期，但案例本身必须经得起复核。「成功率从 70% 提升到 95%」「费率低至 0.3%」「T+0 结算」都不能脱离样本和合同条件单独展示。

一个可以公开的支付案例，至少要交代：

支付成功率也要统一口径。可以定义为「成功授权并完成捕获的有效支付尝试数 / 有效支付尝试总数」，同时单独展示用户放弃、风控拒绝、发卡行拒绝和技术失败。不同口径下的 95% 没有可比性。

冷启动可以选 3 到 5 家商户做试点，但不必都包装成公开案例。更合理的组合是：一家欧美独立站、一家东南亚或中东游戏公司、一家平台卖家，再根据实际数据补充其他行业。

客户证言视频适合由商户负责人说明接入过程、对账变化和客服体验。费率、结算和成功率只引用合同允许公开的数据，不写「零掉单」「保证成功率」或没有统计口径的提升数字。

平台合作不是普通插件上架

平台渠道能持续带来商户，但支付应用通常受更严格的准入、审核和安全要求约束。

Shopify 需要 Payments Partner 资格

Shopify 官方文档明确说明，只有获批 Partner 才能在 Shopify Payments Platform 上开发 payments extension。支付应用还要通过产品要求、审核和 Payments Partner 条款，进入后台公开支付网关列表也需要单独申请。

因此，「开发插件后直接上架 Shopify App Store」不是完整计划。实际步骤应拆成：

1. 确认服务主体、牌照和目标国家符合 Shopify 准入；

2. 申请 Payments Partner 并确认可开发的 extension 类型；

3. 完成支付、退款、授权、捕获、撤销和 3D Secure 流程；

4. 通过技术、安全和商户体验审核；

5. 先通过安装链接服务已签约商户，再申请公开列表曝光。

「0 代码接入」只适用于商户安装和配置阶段。支付服务商仍要维护 OAuth、支付状态、Webhook、退款、对账、风控、版本兼容和平台审核。

WooCommerce 更开放，也更依赖维护

WooCommerce Payment Gateway API 允许通过传统插件增加支付网关。官方文档区分了跳转、iframe、直连和线下支付。直连模式会让支付字段出现在 checkout，服务商需要承担更高的服务器安全和 PCI DSS 责任。

WooCommerce 渠道的优势是接入和分发更灵活，代价是版本、主题、Checkout Block、WordPress 插件冲突和商户服务器环境更分散。上线前至少要覆盖：

• 经典 checkout 和 Checkout Block；

• 授权、捕获、退款和异步通知；

• 重复回调和幂等；

• WordPress、WooCommerce 和 PHP 支持版本；

• 插件升级、回滚和安全公告；

• 不同币种、税费和订单状态。

Wix 也需要商务准入

Wix 提供 Payment Service Provider Service Plugin，支持卡、钱包、本地方式、跳转支付、订阅、捕获、撤销和退款。官方文档同时说明，PSP 在集成前要先与 Wix 商务团队完成 onboarding 并确认合作条款。

Wix、Shopify 这类平台的共同点是：技术插件只是准入的一部分。商务协议、服务地区、退款和争议责任、商户支持、品牌展示和持续审核同样会影响上线时间。

Amazon SPN 更适合服务线索

Amazon Service Provider Network 是经过 Amazon 标准筛选的第三方服务商网络，商户可以按服务类型、地区、语言和评价寻找服务商。Amazon 同时说明，SPN 列表属于信息资源，不代表 Amazon 为服务商背书，商户与服务商直接签约。

支付服务商可以评估 SPN 或 Selling Partner Appstore 的适用类别，但不能默认「入驻后即可销售支付产品」。更现实的切入方式是围绕平台卖家的真实问题设计服务：

• 多平台资金归集；

• 多币种账户和换汇；

• 供应商付款；

• 对账和财务自动化；

• 目标市场本地收款；

• 拒付、退款和风险咨询。

费率优惠可以作为活动条件，但首月 0 手续费、0 月租或固定免费提现次数必须写清适用币种、交易类型、有效期、最低流水和不包含的卡组织、换汇或银行费用。

云服务商合作更适合共售

AWS Partner Network 提供技术支持、市场推广、Marketplace 和 co-sell 机制。AWS Marketplace 还要求服务商完成卖家注册、产品要求、支持能力、税务和银行信息等准备。

因此，「EC2 实例 + 支付接口」不适合直接写成标准套餐。云厂商不负责支付牌照和商户准入，支付服务商也不应替商户决定云架构。更可执行的合作形式包括：

• 在 AWS Marketplace 或云市场发布支付相关软件和专业服务；

• 与云服务商或实施伙伴共同举办技术活动；

• 提供经过验证的部署参考和日志集成方案；

• 为联合客户提供迁移、监控和安全配置支持；

• 通过伙伴销售团队共售，而不是捆绑不透明的资源价格。

阿里云合作可以按相同思路推进，通过合作伙伴计划、云市场、联合活动和客户转介获取线索。无论选择哪家云厂商，支付平台都要保持订单、支付、账本和风控数据的独立性，避免把云资源购买关系写进支付费率。

交易监控也不应只依赖云日志。支付服务商可以把 API 延迟、错误率、Webhook、通道健康度和商户告警接入商户现有监控，但卡号、CVV、证件信息和完整个人数据不能写入普通日志。

游戏渠道受应用商店规则约束

Unity Asset Store、Unity Package Manager、GitHub 和游戏开发者社区都可以分发 SDK、示例工程和服务端组件。SDK 可以减少签名、订单创建、回调验证和收据校验的接入工作，但不能绕过应用商店的支付规则。

Unity IAP 官方文档将 Apple App Store 和 Google Play Billing 列为移动游戏的默认内购路径，也提供 D2C provider 和 Webshop 相关能力。Apple App Review Guidelines 3.1.1 规定，应用内解锁功能、游戏币、关卡、订阅和数字内容通常要使用 In-App Purchase。Google Play Billing 也面向 Android 应用中的数字商品和订阅。

游戏支付产品要按发行平台拆开：

PayerMax 官网将游戏列为行业方案，公开展示 API、checkout、本地支付和充值站等能力。类似服务商可以帮助 Web、PC 和部分 D2C 场景接入新兴市场支付，但「为某款小游戏接入后成功率达到 95%」如果没有商户授权、统计周期和样本口径，不应作为公开案例。

开发者激励也要避免按支付尝试次数简单发放奖励。按「完成沙盒验收、上线生产、达到首个结算门槛、连续活跃 30 天」分阶段发放云资源或技术支持，更不容易被测试流量和欺诈交易放大成本。

低代码工具只能处理外围流程

Wix、Zen Cart、OpenCart、Magento Open Source 或 Adobe Commerce 可以通过平台扩展接入支付。Payssion 等聚合服务商也公开提供 Hosted Page、API、插件和 SDK 等方式。

Zapier 一类自动化工具更适合处理支付外围流程：

• 新商户线索写入 CRM；

• KYB 状态变化通知销售；

• 首笔交易后创建客户成功任务；

• Webhook 异常触发工单；

• 结算报表到达后通知财务；

• 低活跃商户进入召回流程。

它不应该接收 PAN、CVV、完整证件或未脱敏的支付数据，也不能替代支付网关、账本、幂等、退款和对账。所谓「拖拽式接入」，应该限定为外围运营自动化，不应被描述成完整支付系统无需开发。

本地支付决定区域转化

支付方式覆盖要和销售市场同步推进。东南亚、中东和拉美用户通常更依赖本地银行卡、实时转账、二维码、钱包或现金凭证，单独支持 Visa、Mastercard 并不能覆盖所有付款偏好。

PayerMax、Payssion 等聚合服务商可以减少逐个接入本地方式的开发量。PayerMax 官网列出的 600+ 支付方式、70+ 交易币种和 150+ 国家或地区，Payssion 官网列出的 200+ 本地支付方式，均属于服务商公开口径。实际项目要进一步确认目标国家、商户行业、退款、拒付、结算、费率、服务主体和当前可用状态。

连连国际和 PhotonPay 可以放在初期服务商组合中。连连国际更偏跨境收付和平台卖家服务，PhotonPay 官网公开展示账户、钱包、付款、换汇、发卡、收单和嵌入式金融等产品。使用哪一项能力，要以具体签约产品为准，不能把同一集团的全部能力默认视作已向当前商户开放。

初期服务商组合可以按职责拆分：

• 国际卡和成熟市场 checkout；

• 新兴市场本地支付；

• 多币种账户、换汇和付款；

• 备用通道和故障切换；

• 风控、拒付和对账支持。

按职责拆分服务商可以降低自建风险，也能保留后续替换空间。内部仍要统一商户、订单、支付、退款、拒付、结算和对账标识。

政策资源要注明有效期

政策补贴可以降低特定阶段的商户接入成本，但不能作为长期商业模式。

海南省政府公开细则显示，外卡 POS 补贴适用于 2024 年 1 月 1 日至 2025 年 12 月 31 日期间新增或更换并开通外卡受理功能的设备，补贴为采购成本的 50%，单台不超过 400 元。截至 2026 年 7 月，这个原有适用期已经结束。若没有后续文件，不应继续写成当前可申请政策。

类似政策的正确使用方式是：

1. 记录发文机关、文件编号、生效日期和截止日期；

2. 确认申请主体、设备或交易范围；

3. 区分财政补贴、银行优惠和服务商营销活动；

4. 在销售材料中标记「以当前政策审核结果为准」；

5. 政策到期后及时下线页面和话术。

CIPS 不是商户支付接口

CIPS 官网将其定义为经中国人民银行授权的跨境人民币批发支付系统，服务对象和接入结构围绕直接参与者、间接参与者、银行和金融市场基础设施。普通跨境电商或游戏商户不会把 CIPS 直接接到 checkout。

涉及人民币跨境结算时，可以通过银行、支付机构和合资格参与者使用相关能力。结算周期取决于银行、支付机构、合规审核、资金路径和商户合同，不能从「使用 CIPS」直接推导出「T+0 到账」。

数字人民币仍属于试点与机构合作

HKMA 与中国人民银行在 2024 年扩展香港跨境 e-CNY 试点，香港居民可以使用香港手机号开立个人钱包，并通过 FPS 参与银行为钱包充值，无需开立内地银行账户。中国银行还公开了香港居民使用实名八达通 App 余额购买数字人民币硬钱包的案例。

这些案例说明跨境零售支付工具正在互联，但它们还不是普通支付服务商可以自行组合的「数字人民币 + 外卡」产品。常规商户拓展阶段可以持续跟踪，只有在获得运营机构、银行和监管合作后，才适合进入产品路线图和销售材料。

内容获客要服务于销售判断

内容营销不应只追求阅读量。每一篇内容都要对应一个 ICP、一个支付问题和一个下一步动作。

适合的内容组合包括：

「3 分钟接入」「动态路由节省 1% 手续费」「转化率提升 25%」只有在演示环境或真实案例里有明确前提时才能使用。接入时间要从完整资料、审核通过和技术资源到位后开始计算。成本节省要比较相同国家、卡种、币种、拒付和换汇条件。

SEO 和 SEM 可以围绕问题型长尾词展开，例如「东南亚跨境收款」「独立站支付成功率」「游戏出海本地支付」「Shopify 支付网关接入」。广告落地页要对应目标市场和行业，不要把所有服务能力堆在同一页。

KOL 合作也要绑定可验证动作：观看后预约、提交需求、进入沙盒、完成首笔支付和 30 天活跃。只有曝光和点赞，无法证明渠道能带来合格商户。

行业活动要提前设计转化路径

Amazon 全球开店活动、TikTok Shop 生态活动、ChinaJoy 和 GDC 都可能聚集目标商户。参展前要确认活动受众、参会企业、地区和业务品类是否与 ICP 一致。

展台或技术分享更适合演示这些内容：

• 从订单创建到首次结算的完整流程；

• 同一订单如何展示不同国家的本地方式；

• 通道超时时如何避免重复扣款；

• 商户后台如何查看失败原因、退款和对账；

• 游戏 Web 充值如何处理账号绑定和交付证据；

• 一份真实但脱敏的支付健康报告。

「支付成功抽奖」会把活动注意力带向促销，还可能引入测试交易、退款和合规问题。活动可以改为沙盒挑战、技术诊断、支付方式评估或联合案例分享。

活动目标可以分成 4 层：预约会谈、完成需求表、开通沙盒、进入生产。展会结束后的 48 小时内，销售应按行业、市场、预计流水和上线时间分组跟进。

用统一漏斗管理渠道

平台、广告、KOL、合作伙伴、活动和推荐计划最终都要进入同一套 CRM 和商户状态机。

建议使用这些阶段：

每个渠道至少计算：

• MQL 到 SQL 转化率；

• SQL 到 KYB 通过率；

• KYB 到 Sandbox 转化率；

• Sandbox 到 Live 上线率；

• Live 到 Activated 激活率；

• 30 天和 90 天留存率；

• 单个激活商户获客成本；

• 单个激活商户接入和支持成本；

• 毛利回收期；

• 拒付、退款和合规损失。

Google Analytics 的自定义 Campaign URL 可以用 UTM 参数识别广告、推荐、活动和内容来源。命名规则要固定大小写和字段含义，并把浏览器侧来源写入 CRM。公开文章里的引用链接不应附带内部广告或 AI 工具的跟踪参数。

渠道 ROI 不能只看注册成本。支付业务更适合看「每个激活商户成本」和「激活商户 90 天净收入」。一个带来大量注册但几乎没有生产交易的渠道，价值通常低于线索少但上线率高的合作伙伴。

推荐计划要保护单位经济

推荐一家商户奖励 1000 美元，可以作为高价值客户的活动示例，但不适合无条件发放。奖励金额至少要受这些条件约束：

• 被推荐商户通过 KYB；

• 不是重复账户或关联主体套利；

• 完成首笔生产支付和首次结算；

• 达到约定的有效交易量或净收入；

• 在 30 到 90 天内没有异常退款、拒付和欺诈；

• 推荐关系和税务处理有书面规则。

长尾商户更适合使用小额固定奖励、费率券、技术支持时长或云资源。头部商户可以采用联合市场预算或阶梯返佣，但返佣不能覆盖未验证交易和高风险流水。

商户接入决定增长上限

支付服务商要把销售承诺变成标准接入包，减少商户在资料、测试和上线阶段的等待。

标准接入包可以包含：

• 产品和准入范围；

• KYB 资料清单；

• API、SDK、插件和示例工程；

• 沙盒账号、测试卡和失败场景；

• 签名、幂等、Webhook 和重试说明；

• 退款、拒付和对账流程；

• 上线检查表；

• 支持渠道和响应时间；

• 费率、换汇、结算和保证金说明。

商户后台要能回答 4 个高频问题：这笔支付现在是什么状态，为什么失败，何时结算，出现退款或拒付后怎么处理。后台和 API 如果给不出一致答案，销售带来的商户越多，客服和财务压力越大。

多语种支持从覆盖时间开始

英语、阿拉伯语、西班牙语和葡萄牙语支持可以按目标市场逐步建设。7×24 小时客服不是一句宣传语，需要轮班、工单分级、升级机制、技术值班和服务质量报表。

冷启动阶段可以先提供：

• 工作日英语技术支持；

• 目标市场本地合作伙伴的一线协助；

• 支付故障的紧急升级通道；

• 双语文档和标准错误说明；

• 明确的服务时间和响应目标。

交易量和时区分布稳定后，再扩展轮班和本地团队。客服覆盖不足时应如实写明，不要先承诺 7×24 再依赖单个客户经理处理所有问题。

免费试用要写清费用边界

首月 0 费率、0 月租或阶梯费率可以降低决策阻力，但「0」通常不等于交易没有成本。活动条款应说明是否包含：

• 卡组织和收单成本；

• 国际卡附加费；

• 换汇点差；

• 退款和拒付费；

• 提现和银行费用；

• 本地支付方式费用；

• 保证金和延迟结算；

• 税费。

优惠结束后费率跳升过大，会让商户在最初几个月后流失。活动设计要同时看激活率、留存率和毛利，而不是只看开户数。

90 天冷启动方案

冷启动目标是验证渠道和交付，不是追求注册商户总数。

第 1 到 2 周：限定范围

• 选择两个 ICP 和两个目标市场；

• 建立 100 家目标账户名单，而不是直接要求 100 家上线；

• 确认主服务商、备用服务商和可用支付方式；

• 完成费率、牌照、结算、行业和数据处理尽调；

• 准备落地页、需求表、沙盒和接入文档；

• 定义销售漏斗和 UTM 命名规则。

第 3 到 6 周：获得首批试点

• 完成 20 次左右的合格商户访谈；

• 让 5 到 10 家商户进入沙盒；

• 选择 3 到 5 家进入生产试点；

• 接入一个目标市场的本地支付方式；

• 每周记录审核、集成和失败原因；

• 启动合作伙伴推荐，但奖励在首次结算后发放。

第 7 到 12 周：验证留存

• 跟踪首笔支付、首次结算和 30 天活跃；

• 完成支付成功率、拒付、退款和成本基线；

• 形成 1 到 3 个经商户授权的案例；

• 停止低质量线索渠道，把预算移到上线率更高的渠道；

• 决定是否继续深耕当前市场，或增加第二个本地支付方式；

• 评估 Shopify、Wix、Amazon SPN 或云市场的正式合作申请。

90 天后可以用一组门槛决定是否扩张：

规模化阶段：3 到 12 个月

规模化阶段要扩张已经验证的渠道，不要同时进入多个陌生市场。

建议动作包括：

• 按真实交易数据增加中东、东南亚或欧美的第二批市场；

• 上线行业解决方案页，分别服务电商、游戏和 B2B；

• 完成第二通道、动态路由、统一错误码和自动对账；

• 从 5 场候选活动中选择目标商户最集中的 2 到 3 场参与；

• 与云服务商、建站服务商、ERP、税务和物流伙伴建立转介关系；

• 建设英语和目标市场语言的客户成功能力；

• 对高流水商户谈阶梯费率和结算条件；

• 形成 3 到 5 个可公开、可复核的标杆案例。

「3 到 12 个月获取当地支付牌照」通常不是可直接承诺的里程碑。这个阶段更适合完成牌照必要性评估、成本测算、法律意见和合作机构筛选。若现有持牌合作方可以覆盖需求，自建牌照未必是优先事项。

长期阶段：12 个月以上

只有当某个市场的交易量、商户数量和利润稳定后，本地牌照和团队投入才有清晰依据。

长期建设可以包括：

• 评估沙特 SAMA、新加坡 MPI 或其他重点市场牌照；

• 建立本地商务、合规、风控和客户成功团队；

• 建设开发者社区、GitHub 示例项目和技术论坛；

• 开放商户测试工具、Webhook 重放和对账校验工具；

• 与银行和本地 PSP 建立更深的收单和结算合作；

• 跟踪 e-CNY、区域实时支付互联和跨境人民币基础设施；

• 根据市场需求评估新的钱包、BNPL 和数字资产支付。

数字人民币、硬钱包和区域清算试点适合放在政策观察和机构合作路线，不应挤占已经验证的卡支付、本地支付、风控、账本和商户服务建设。

推荐资源与合作方

这张表用于建立候选池，不代表推荐名单。服务商选择仍应回到第四篇的尽调框架：牌照、费率、成功率、合规、用户体验、技术适配和资金安全。

小结

跨境支付商户拓展可以按「市场选择、客户分层、渠道获客、标准接入、数据运营」推进。

前 90 天先建立 100 家目标账户名单，完成约 20 次合格访谈，让 5 到 10 家进入沙盒，并推动 3 到 5 家生产试点。这个数量只是工作量示例，最终要由销售能力、KYB 通过率、技术支持和目标商户规模决定。

平台合作、本地支付、云生态、行业活动和政策资源都能带来线索。线索能否变成持续交易，取决于商户准入、插件和 API、支付成功率、风控、账本、对账、客服和客户成功。商户完成首笔交易、首次结算并持续活跃后，这次拓展才算完成。

参考资料

市场与本地支付：

• Google、Temasek、Bain：e-Conomy SEA 2025 Malaysia Report

• Bank of Thailand：PromptPay

• mada

• STC Bank

平台与渠道：

• Shopify Dev：Extensions for payments

• WooCommerce：Payment Gateway API

• Wix：Payment Service Provider Service Plugin

• Amazon：Service Provider Network

• AWS Partner Network

• AWS Marketplace：Getting started as a seller

• Alibaba Cloud Partner Network

• Google Analytics：Collect campaign data with custom URLs

游戏和数字商品：

• Unity Docs：Unity In-App Purchasing

• Apple Developer：App Review Guidelines

• Android Developers：Google Play's billing system

• Game Developers Conference

• ChinaJoy

服务商：

• LianLian Global

• PhotonPay

• PayerMax

• Payssion

政策与跨境基础设施：

• 海南省人民政府：商家开通外卡 POS 机可享补贴

• CIPS：Introduction

• 香港金融管理局：Expanding the cross-boundary e-CNY pilot in Hong Kong

• 中国银行：便利跨境消费，中国银行创新数字人民币服务新模式