易支付接入 Infini 实战：银行卡、Google Pay 配置教程与3个真实踩坑

一、Infini 是什么，为什么接入易支付？

Infini 提供数字货币收款及托管收银台相关接口。这里使用的是 Hosted Checkout：网站服务器创建订单，取得收银台链接，再让客户前往 Infini 提供的页面选择当前可用的付款方式。支付页面和付款引导由上游承载，网站负责自己的订单与交付。具体产品流程见 Infini 托管收银台说明。

对已经使用易支付的网站来说，插件的价值在于接入现有订单流程：前台网站继续向易支付发起订单，易支付通过 Infini 通道创建上游订单，再核验付款结果。你不需要把每个商城都单独改写成一套 Infini API 客户端。没有易支付程序的可以点击购买或下载

这里介绍的是 infinipay 第三方适配插件，不是 Infini 官方发布或背书的易支付插件。账户能否收款、能使用哪些方式、是否需要补充验证，以及费用和结算安排，都以商户后台及平台要求为准。

二、银行卡、Google Pay、Apple Pay，到底能用哪些？

先区分两件事：插件提供这个选项，不等于你的账户当前就能用这个方式完成付款。新版插件提供以下选择：

这些编号与默认行为来自 官方创建订单文档。表格中的测试结果来自此次联调，不代表所有账户、地区、币种和未来时点的可用性。尤其不要因为银行卡成功，就推断 Apple Pay 一定已经开通。

三、开始前准备什么？

• 一套正常运行的易支付网站，以及固定、可访问的 HTTPS 支付域名。
• 能够使用相应收款接口的 Infini 商户账户。
• Infini API Key、配对的 Secret Key，以及 Webhook 验签密钥。
• 确认订单计价币种、换算系数和希望开放的支付方式。
• 服务器 PHP 可使用 cURL、JSON、hash，数据库可使用 MySQL/MariaDB 的订单互斥锁功能。

在 Infini 商户后台的 Developer 页面管理 API 凭据和 Webhook。正式环境与 Sandbox 的凭据分别填写，不要混用。商户注册、环境地址和凭据流程可参照 官方接入指南。

API Key 与 Secret Key 用于服务器调用上游；Webhook Secret 用于核验通知来源。它们都不是易支付的商户 PID 或商户签名密钥。录屏时只展示字段名称，不展示完整凭据。

四、安装插件：目录名不要改，支付类型选 bank

把插件文件夹上传到易支付根目录下的 plugins 中，保持下面的结构：

plugins/infinipay/
├── infinipay_plugin.php
├── README.md
├── inc/
│   └── InfiniClient.php
└── tests/
    └── run.php

然后在易支付后台刷新插件列表，新增普通支付通道，选择 “Infini 托管收银台”。

如果后台没有显示插件，依次核对目录是否多套了一层、主文件是否名为 infinipay_plugin.php、文件是否可读，以及插件列表和 PHP 缓存是否已刷新。现有通道升级前先备份插件目录。

五、支付通道每个配置项怎么填？

希望同一个收银台提供两种已经验证的选项，可以选择“银行卡＋Google Pay”。希望完全交给平台决定，则选择“使用 Infini 商户后台配置”。后者表示不指定 pay_methods，并不是强制启用所有支付方式。

六、易支付是人民币，Infini 填美元，换算系数到底填多少？

插件按照下面的方向计算：

Infini 下单金额 = 易支付 realmoney 实付金额 × 金额换算系数

如果按“1 美元等于 R 元人民币”定价，系数就是 1 ÷ R。例如用 1 USD = 7.20 CNY 作为演算假设，系数保留六位小数后填写：

1 ÷ 7.20 ≈ 0.138889
144.00 CNY × 0.138889 = 20.000016 USD

这里的尾数来自系数只保留六位小数。它说明了一个很实用的检查点：不要只凭心算判断“应该是20美元”，要核对订单实际提交金额和收银台展示。本例只是计算演示，不是实时汇率、费率或到账承诺。

如果你自行设定的换算系数是 0.13，那么 180.00 × 0.13 = 23.40 USD。同币种收款填 1。不要把“1美元等于多少人民币”的 7.20 直接填进人民币转美元的系数，否则会把金额方向反过来。

当前插件按六位小数做十进制换算，不自动获取实时汇率；手续费和结算成本也不会被这个系数自动补偿。调整系数只影响后续新建订单，旧订单继续使用初次下单保存的金额和币种。

按当前官方文档，银行卡、Apple Pay 和 Google Pay 的下单金额至少为16；加密货币订单需大于0.1。美元通道应先检查换算后的美元金额。使用后台默认方式时，还要由上游判断所选方式是否符合限额。见 官方金额限制与错误码说明。

七、Webhook 地址怎么填？关键是通道 ID

假设你的易支付域名是 pay.example.com，新增的 Infini 通道 ID 是 12，通知地址就是：

https://pay.example.com/pay/notify/12/

把域名和数字替换成自己的信息，在 Infini 后台订阅 order.completed。Webhook Secret 填到对应易支付通道。插件配置说明中也会展示代入本站域名和通道 ID 的地址。

这不是 /pay/return/，也不是本站 Sokin 教程里的 /pay/webhook/。不同插件的路由不能混抄；地址后面也不用附加 API 密钥。

本插件会核验 Infini 回调的时间戳、事件编号和 HMAC 签名，然后主动查单。只有远程状态、订单归属、金额和币种符合要求，才进入易支付入账流程。官方通知字段与事件说明见 Infini Webhook 文档；签名机制见 API 与 Webhook 鉴权文档。

八、从下单到到账，完整流程是什么？

1. 网站发起订单：调用易支付，由已经配置好的 bank 通道承接。
2. 插件保存快照：记录金额、币种和幂等编号，避免重试时突然换金额。
3. 创建上游订单：拿到 Infini 订单号和收银台地址。
4. 客户前往收银台：选择账户当前允许的付款方式并完成相应操作。
5. 上游发送通知：付款状态变化后向配置的 Webhook 发起请求。
6. 验签并主动核单：核对是否真实支付、是否对应这笔本地订单。
7. 易支付更新订单：再按照易支付原有流程通知业务网站。

所以，验收时至少要看三个地方：Infini 订单、易支付订单、业务网站订单。客户浏览器跳回成功页，只能证明页面完成跳转，不能单独证明资金已到账或业务网站已收到通知。

九、实战故障：Apple Pay 为什么报 40015？

这次测试中，Apple Pay 下单金额为16.90美元，上游返回 HTTP 200，但 JSON 中的业务码是 40015，文字说明如下：

Payment method not supported: on-ramp is currently not available

也就是：当前上游不提供这项 on-ramp 服务，所选付款方式暂不可用。这是此次接口的实测响应，并不是根据错误码猜出来的结论。不能通过修改本地按钮文字或把订单标成成功来解决。

新版插件已经补上这条错误的中文解释。遇到同样情况，先使用账户已经可用的方式，再向 Infini 确认相应服务的可用性。不要把本次结果扩展为“Apple Pay 永久不支持”，也不要将其他账户的成功案例当成自己的开通证明。

我们还对“商户后台默认配置”重新创建了独立诊断订单，结果成功。这说明不同方式需要分别验证，不能因为一次默认配置失败，就判断默认模式一定不可用。对照测试时尽量保持币种和金额一致，只改变一个选项。

十、“未返回有效订单编号”，不一定是密钥填错

如果旧版插件只读取最外层 order_id，而上游返回的数据放在 data 内，就可能出现“Infini 未返回有效订单编号”。另外，HTTP 200 也可能装着业务错误；只检查 HTTP 状态会丢失真正原因。

修订版会先检查外层业务结果，再读取订单对象，并兼容直接对象和 data 包装。未识别的错误需要结合上游说明排查，不能统一解释为“金额不够”或“账户没开通”。

还有一个更隐蔽的问题：下单正常，查单字段不一致

我们从真实接口读到的金额字段是 order_amount、币种字段是 order_currency，而说明页示例使用 amount、currency。如果解析只认其中一套，后续订单核验可能失败。

新版已兼容两套字段，但仍然严格比较金额、币种和订单号；若两套字段同时出现却互相矛盾，会拒绝处理。修复解析不等于降低到账校验标准。

另外，本次验证可用的令牌重发路径为 /v1/acquiring/order/token/reissue，与 OpenAPI 定义一致。手写接口时要留意说明页与接口定义之间的路径差异。

十一、收银台能打开，回调为什么还是进不来？

这次我们对同一个回调地址做了两次无签名空请求测试：

第二种结果在这个测试里是正常的：我们故意没带签名，插件当然不应该接受。第一种结果则提醒我们，公网通知通路可能被浏览器验证拦住，还需要处理 Cloudflare 规则后再验证真实通知。

先在 Cloudflare 安全事件里找到对应请求，确认是哪项规则或产品触发，再为准确的回调地址配置例外。下面是匹配条件示例，不是可以直接导入的完整规则：

(http.host eq "pay.example.com"
 and http.request.uri.path eq "/pay/notify/12/"
 and http.request.method eq "POST")

将域名与通道 ID 换成自己的。对于可以跳过的 WAF 规则，配置对应的 Skip 范围并确保规则顺序正确；不需要把整个网站的防护关闭。具体选项见 Cloudflare Skip 规则说明。

注意产品差异：免费 Bot Fight Mode 不能通过 WAF Skip 规则绕过。如果触发的是它，就要按该产品的限制调整方案；不能以为新增一条 Skip 就一定解决。参见 Cloudflare 机器人误拦截说明。

正确目标是让机器通知到达插件，再由插件验签和查单；不是让所有通知都返回成功。

十二、正式收款前，按这三层做验收

第一层：接口有没有接通？

检查真实下单是否获得订单号，收银台链接是否可打开，主动查单金额、币种和订单号是否一致，重复打开待付订单是否能重新取得收银台链接。这一层本次已经实际验证。

第二层：付款有没有被确认？

用账户允许的方式完成一笔受控付款，核对 Infini 后台的最终状态，再观察有效 Webhook 是否到达易支付、是否通过验签与主动查单。不要通过手工修改数据库模拟真实到账。

第三层：业务网站有没有收到结果？

确认易支付订单已更新，业务网站收到正确通知，商品交付或服务开通正常。随后验证通知重发不会重复交付，并明确异常付款与退款由谁处理。

当前插件已在 PHP 7.4 与 PHP 8.4 环境通过109项模拟检查，覆盖解析、换算、幂等、回调校验和回跳核单等逻辑。自动化模拟检查不能替代第二、第三层的真实付款验收。

十三、几个容易混淆的问题

1. 支持 PHP 8.3 吗？

当前插件没有已知的 PHP 8.3 语法兼容问题，但本次实际运行检查的是 PHP 7.4 和 PHP 8.4，没有单独做 PHP 8.3 环境验收。升级时还要检查易支付主程序、模板和其他插件，不能只凭一个插件判断整站兼容。

2. USD 是不是代表客户只能用美元余额？

USD 是这里的订单计价币种，和收银台允许客户选择的付款方式、代币或网络不是同一个配置项。实际可选项及换算展示，以当时收银台为准。

3. 为什么修改支付方式以后，旧订单还是原来的方式？

插件保存了首次请求快照。为了避免同一笔订单在重试时改变金额或付款方式，旧订单继续复用原请求。切换配置做测试，请重新从业务网站生成一笔易支付订单。

4. 40901 是不是再刷新几次就好了？

本次旧失败请求重试时，实际遇到上游提示该幂等编号已经处理。不要无限刷新，也不要在付款状态不明时自动更换编号。先在上游核对是否已有订单；确认失败且未付款后，再按需要建立新的测试订单。

5. 当前插件支持主动退款吗？

不支持易支付后台通过此插件主动发起 API 退款。Infini 对特定异常付款提供的自动退款机制，与本插件的主动退款接口不是一回事。接入前应确认自己的退款处理流程。

6. 能不能同时配置很多套商户密钥？

不同凭据应分别建立普通通道。本版不支持轮询子通道、商户自填密钥、合单和分账；不要为了增加一个入口就直接覆盖仍有待付订单的通道凭据。

7. 页面能打开，是否就可以放心正式收款？

还需要完成真实付款、Webhook、易支付更新和业务网站通知的闭环。本次记录中公网回调出现过 Cloudflare challenge，这类通路问题必须在开放正式业务前处理并复测。

十四、插件获取与技术咨询

你现在卡在安装、金额换算，还是付款回调？欢迎在本文评论区说明易支付版本、PHP 版本、希望使用的付款方式，以及已遮挡敏感信息的报错内容，便于判断问题发生在哪一步。

插件获取、版本更新和安装联调用积分下载。咨询时不用发送完整 API Key、Webhook Secret、服务器密码或客户付款资料。

如果你正在比较其他接入方案，也可以阅读本站的 Sokin 对接易支付教程。两种插件的字段、路由与退款能力不同，请按各自说明配置。