技能介绍

要解决的具体问题

接入 FlyPay 支付时，开发者容易在三件事上反复踩坑：一是不确定该选 Checkout、API Direct 还是 Element SDK，选了不符合合规要求的模式可能返工；二是签名规则细节多，比如字段要按名称升序拼接、amount 格式得用字符串保留两位小数，错了就会收到 INVALID_SIGN 或 INVALID_AMOUNT；三是回调处理，漏了 Hash-Sign 验签或没返回 OK，网关会按每 6 分钟一次、最多 10 次的策略重试，徒增系统压力。

技能如何工作

场景路由：通过接口路由表，根据业务场景直接定位生产/测试环境的接口地址，比如创建支付单走 checkout 模式的 order/payment/create 端点。
签名规则：

- 请求签名：提取 amount、currency、invoice_id、merchant_id，按字段名升序拼接值，前置 secret_key，做 UPPER(SHA256())；
- 回调验签：从 body 提取字段，amount 按接口要求格式化为四位小数，同样按升序拼接后计算 hash，与 Header 的 Hash-Sign 对比。

流程引导：

- 先识别用户目标是接入咨询、联调还是排查错误；
- 再确认运行环境（测试/生产）、是否已有商户凭证和公网回调地址；
- 最后路由到对应流程：如 Flow B（创建支付单+查询+验签）、Flow C（Webhook 验签与重试）。

错误速查：内置常见错误码表，比如 ORDER_EXIST 对应重复的 invoice_id，WEBHOOK_SIGN_ERROR 要检查字段是否遗漏或 amount 格式。

适用边界与注意点

模式限制：API Direct 需商户自建收银台并通过 PCI DSS 认证；Element SDK 嵌支付方式时，ApplePay 需在域名下放置 apple-developer-merchantid-domain-association.txt，GooglePay 要提交购买流程截图给飞来汇审核。
格式要求：amount 必须用字符串，保留两位小数（如 "100.00"），回调验签时可能需要四位小数，具体以接口文档为准。
回调处理：验签通过后必须返回字符串 OK，否则触发网关重试；需确保 notify_url 可公网访问，否则回调无法送达。