站点级
配置边界
多 PSP
处理器排序
兜底
支持挽回的路由
控制
无需改代码即可配置路由
运营团队可以在工程团队触碰结账逻辑之前,先建模流量应该流向哪里。
- 将规则限定到一个站点或一组站点
- 按币种、国家/地区、卡品牌和金额确定处理器优先级
- 让处理器故障转移对支付运营保持清晰
挽回
减少可避免的支付失败
当选定处理器不可用或不适合当前交易上下文时,兜底逻辑为团队提供可行的交易挽回路径。
- 使用处理器排序支持可兜底流量
- 保持重试逻辑与已配置渠道一致
- 通过控制台报表检查挽回的交易
治理
保持策略与站点归属一致
路由变更不应跨商户或站点混用。EFundFlow 将站点商户 ID 作为配置的运营边界。
- 使用商户权限进行访问控制
- 配置变更前校验站点归属
- 将商户身份与站点支付执行分离
智能路由如何融入你的支付堆栈
控制台将站点设置、处理器凭证、支付方式和路由策略连接起来,使支付路由与实际收单配置匹配。
1
创建或选择站点
将站点商户 ID 作为域名、币种、Webhook 和支付配置的运营边界。
2
连接处理器
将 PSP 账户、凭证、支付方式、卡品牌和币种绑定到选定站点。
3
定义路由范围
按支付方式、国家/地区、卡品牌、金额、币种和处理器优先级创建策略。
4
监控结果
使用报表和交易视图跟踪成功率、失败模式、退款和争议。
Route node
Primary PSP
Route node
Fallback PSP
Route node
Risk review
为什么这很重要
1
Site
2
Policy
3
Processor
4
Fallback
Route value 01
单个商户可以运营多个站点,每个站点可能拥有不同的域名、支付方式、处理器、币种和结算需求。
Route value 02
只有策略边界与交易边界一致时,路由才有效。EFundFlow 将站点商户 ID 视为该边界。
Route value 03
支付团队可以有意地转移流量,而工程团队保持一个集成入口。
Route value 04
兜底策略成为运营策略,而不是分散在结账逻辑中的代码。
