前置方案最佳实践

2026-02-28 16:14

在传统集成体验下，买家需要在支付过程中跳转至支付方式页面完成某些操作以完成支付，如选择具体银行支付方式、填写支付要素、扫码或复制支付口令。以下最佳实践指导您在您的页面呈现银行列表、支付要素、二维码或支付口令，从而减少支付过程中的页面跳转，提升买家体验。

银行前置方案

标准集成方案中，需要买家在部分支付方式页面选择具体的网银，再跳转到网银页面，流程较长，容易增加买家流失的概率。银行前置方案使买家能在商户页面选择具体银行完成支付，帮助您优化网银支付体验。

该前置能力支持在 Web、WAP、App 端集成，下表以买家在商户 App 端使用 iDEAL 支付方式支付为例，对比展示标准方案和优化方案的体验：

表 1. 标准方案与银行前置方案体验对比

标准方案下，买家需要跳到 iDEAL 中间页选择具体银行。优化方案下，买家直接在商户页完成选择银行。该方案避免跳转到 iDEAL的中间页，有助于降低买家的流失。

此方案的集成步骤与标准集成流程一致，仅在接口的入参、出参中有细微差异：

在调用 pay 接口时，需传入支付方式以及指定银行。以 iDeal 支付方式为例，若买家选择的支付方式是 iDeal 渠道下的 Rabobank 银行，则您需要在 pay 接口的入参中传入：

下表展示支持银行前置方案的支付方式对应的支付方式枚举值、银行简称和具体银行枚举值：

表 2. 银行前置方案支持支付方式

标准集成方案中，买家需要跳转到支付方式页面完成支付要素（支付方式登录账号、动态口令等）填写后再完成支付，流程较长，容易增加买家流失的概率。您可以在商家页面提前收集支付要素并在 pay 接口中传入给 APO，避免因跳转造成买家流失。

该前置能力支持在 Web、WAP、App 端集成，下表以买家在商户 App 端使用 OVO 支付方式支付为例，对比展示标准方案和优化方案的体验：

表 3. 标准方案与支付要素前置方案体验对比

标准方案下，买家需要跳转到 APO 中间页填写 OVO 账号信息。优化方案下，买家直接在商户页完成输入账号信息。该方案避免跳转到 APO 的中间页，有助于降低买家的流失。

除以下差异点外，此方案的集成步骤与标准集成流程一致：

在调用 pay 接口时，需传入支付方式以及对应的支付要素。以 BLIK 支付方式为例，若在商户侧采集 BLIK code，则您需要在 pay 接口中传入对应的支付要素，支付要素参数名请参见支持支付方式列表。
对于 P24 支付方式，在您发起 pay 接口请求后，需要利用 APO 返回给您的链接先跳转到 P24 页面。对于 OVO 和 BLIK 支付方式，在您发起 pay 接口响应后，建议您先展示支付处理中的状态，待 APO 向您发送支付结果通知或您向 APO 查询并拿到支付结果后，再向买家展示支付结果。

下表展示支持支付要素前置方案的支付方式及其所收集的支付要素和对应的支付要素参数名，以及实现该方案的最佳实践。

表 4. 支付要素前置方案支持支付方式

标准集成方案中，买家需要跳转到支付方式页面扫码或输入支付口令完成支付，流程较长，容易增加买家流失的概率。您可以在商家页面展示支付二维码或支付口令，降低跳转带来的买家流失。

该前置能力支持在 Web、WAP、App 端集成，下表对比展示两种前置模式下标准方案和优化方案的体验以及最佳实践，其中二维码前置模式以买家在商户 Web 端使用 AlipayHK 支付方式支付为例，口令前置模式以买家在商户 App 端使用银行转账支付方式支付为例：

表 5. 标准方案与二维码/口令前置方案体验对比

标准方案下，买家需要跳转到 APO 中间页扫码或获取口令。优化方案下，买家直接在商户页扫码或获取口令。该方案避免跳转到 APO 的中间页，有助于降低买家的流失。

除以下差异点外，此方案的集成步骤与标准集成流程一致：

在支付请求的响应中，通过orderCodeForm.codeDetails.codeValue字段获取支付二维码或支付口令。支付二维码提供文本（displayType=

TEXT

）和图片（displayType=

MIDDLEIMAGE/SMALLIMAGE/BIGIMAGE

）两种格式，支付口令提供文本格式，您可以按需选用码值，将支付二维码或支付口令展示在商家页面。

下表展示二维码/口令前置方案所支持的支付方式以及建议使用该能力的商户端类型：

表 6. 二维码/口令前置方案支持支付方式