[转]中小型研发团队架构实践之企业支付网关
企业支付网关由统一支付服务、统一支付通知、统一支付后台三部分组成,我们今天主要介绍前两个部分。企业支付网关独立出来非常有必要,它是企业做大后金融事业部的基础,当前价值如下:
- 1、集中研发工作:集中研发封装公司使用的各种支付方式,如支付宝、财付通、预付款等,同时统一各应用系统的支付调用方式。
- 2、集中运维工作:集中发布、监控、维护、安全等工作。
- 3、集中财务工作:集中各支付方式的对账、统计、日志追踪、异常处理等结算运营工作。
以上接口有支付、代扣、分润、退款、退分润、补差、转账、冻结、解冻、预付款。支付接口服务仅负责生成和返回支付链接,由调用的业务应用来负责 URL 跳转。
- 按照公司统一应用分层架构,把第三方支付放在 DataLayer 里的同时,每种支付方式都是一个独立的组件,里面的 Model 放在各自组件中,不放在 EntityLayer 层,因为不涉及到跨层对象访问;
- BusinessLayer 核心类有 xxxLogic、xxxHelper、xxxVerify,如 AlipayLogic、AlipayHelper、AlipayVerify,采用统一的接口编写;
- Notify 采用 RESTful 接口,同时允许外网访问,并可指定 IP 安全设置,如仅允许淘宝相关的 IP 访问,这个可以在网络层进行设置,为了高可用,部署时也可用金融级硬件或集群。
1、PaymentFacade:提供对外访问的门面。
2、ThirdPaymentFactory:根据请求的支付类型,创建相应的支付业务逻辑处理类。
3、关键点:面向接口编程。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
public class ThirdPaymentFactory{ public static IPaymentService Create(PayChannels channels) { if (channels.ToString().ToLower() == "alipay") { return new ThirdPayment.AlipayLogic(); } if (channels.ToString().ToLower() == "alipayptp") { return new ThirdPayment.AlipayPTPLogic(); } if (channels.ToString().ToLower() == "tenpay") { return new ThirdPayment.TenpayLogic(); } if (channels.ToString().ToLower() == "tenpayptp") { return new ThirdPayment.TenpayPTPLogic(); } //... throw new NotImplementedException(); } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
public class PaymentFacade : IPaymentService { public TradePayResponse TradePay(TradePayRequest request) { IPaymentService paymentService = ThirdPaymentFactory.Create(request.payChannels); return paymentService.TradePay(request); } public TradeRefundResponse TradeRefund(TradeRefundRequest request) { IPaymentService paymentService = ThirdPaymentFactory.Create(request.payChannels); return paymentService.TradeRefund(request); } //… } |
我们的各支付方式接口封装情况具体如下:
- 1、支付宝支付接口封装:包含支付、代扣、分润、无密退款、补差、转账、冻结、解冻。
- 2、财付通支付接口封装:包含支付、分润、退分润、退款。
- 3、预付款支付接口封装:包含支付、分润、退款、余额查询。
- 4、微信支付接口封装:包含支付、退款。
统一支付通知包括同步回调和异步通知。支付流程是这样的:用户完成支付后,第三方支付平台会分别回调企业支付网关的同步回调处理服务和异步通知处理服务;企业支付网关接收到回调信息后,会调用业务应用系统的接口进行支付后处理。
统一第三方支付通知的接入有利于安全、可靠性以及满足功能方面的需求,如统一处理支付接口的数据签名,提高支付服务器的物理级别安全,记录支付相关的安全审计日志,支付通知重试等等,让业务系统更简单,更专注自己的业务处理。
统一支付通知的实现与第三方支付的通知接口有些类似,只是减少了不必要的安全验证,我们以两个问题来探讨这点。企业支付网关是如何通知业务调用方的呢?调用方即业务应用系统在支付时将一个同步回调地址 ReturnUrl 和一个异步通知地址 NotifyUrl,传给企业支付网关即可,这与第三方支付一样,只是内网的支付后处理 Restful 接口仅需处理业务逻辑,无需关心安全验证和支付日志。
企业支付网关为什么有了同步回调,还需要引入异步通知机制呢?这是为了提高可靠性。如果同步通知处理服务失败,那么第三方支付平台的服务器会不断重发给异步通知处理服务,但是重发又不能过于频繁,以支付宝为例:企业支付网关的异步通知处理服务执行完成后必须打印输出 success 字符,否则支付宝服务器会不断重发,直到超过 24 小时,在 24 小时内完成 6 到 10 次通知重发(通知频率:5s、2m、10m、15m、1h、2h、6h、15h)。我们的统一支付为了统一重试机制,先接到通知后,立即返回成功,然后内部再统一建立自己的重试机制、异常清单、补尝与人工处理等。
[source]中小型研发团队架构实践之企业支付网关