Payment is always a core domain of a company, because it is the lifeline of any company with a transactional nature. So what does a payment system actually look like, and how does it run and interact? Setting aside the payment architecture of financial companies that hold payment licenses, the links and system composition described below basically fit the vast majority of payment scenarios. In fact, the whole thing can be seen as two big systems: a transaction core + a payment core. The transaction system connects business scenarios with the underlying payment, while the payment system completes a series of related operations from invoking payment instruments to reconciliation and settlement. Let’s take a look at the core composition and interaction of each system.
- Payment system overview
Core system interaction
Business map
- Parsing the core systems
- Transaction core
The transaction core connects the company’s business systems with the underlying payment, so that the business systems can focus on business and don’t have to care about the underlying payment.
- Abstraction of basic transaction types
- Multi-table aggregation & order association
- Payment core
The payment core is mainly responsible for abstracting the various payment types into four payment forms: top-up, withdrawal, refund and transfer. At the same time, it is also responsible for integrating multiple payment instruments, orchestrating payment instructions, and so on.
Payment behavior orchestration
Its purpose is to enable a flexible development approach with plug-in development and configurable payment rules.
Exception handling
Exception handling covers exception scenarios such as duplicate payment, partial payment, inconsistent amounts and other exceptions.
Channel gateway
Fund accounting
- Service governance
- Unified platform context
After determining system boundaries and splitting the business model, the entire payment platform is split into dozens of services, and how to ensure that the business information flowing between services is not lost is a problem we need to consider. The element information of the unified platform context (a unique business identifier code) is passed along the entire payment platform link and is used to solve this problem.
- Data consistency governance
Large payment companies all have very strict and complete data consistency solutions internally, such as distributed transactions with very high business invasiveness; sacrificing development efficiency to improve data stability is entirely necessary. But for business companies, if they don’t use distributed transactions, what other strategies are there?
CAS validation
Idempotency & exception compensation
Reconciliation
Near-real-time reconciliation
DB sharding
Asynchronization
Payment is the core link of the entire transaction chain, so how do you balance the stability of the payment system with execution efficiency? The answer is asynchronization.
Message asynchronization
Asynchronizing external payment calls
In external payments, the service side often needs to interact with a third-party payment provider to obtain a prepayment credential, as shown in the figure above.
In the case of such synchronous calls, because it needs to cross an external network, the response RT will be very long, possibly taking several seconds. Because it is a synchronous call, it will block the entire payment link. Once the RT is very long and the QPS is relatively high, the service will be held up as a whole, and may even refuse service.
Therefore, the operation of obtaining the credential can be split out: through an independent gateway channel front-end service, the way it is obtained is made asynchronous — get the internal credential from the front-end gateway, and then the front-end gateway asynchronously calls the third party.
Asynchronous parallelization
Asynchronizing fund accounting
Handling hot-account bookkeeping separately
Splitting bookkeeping transactions
- Production practice
- Performance stress testing
Build a stress-testing model that simulates real-world scenarios; stress-test data goes into a shadow database with no intrusion into normal business; neither single-machine performance nor the aggregated link can be ignored; identify system stability and capacity ratios. . .
Stability governance
Separation of core links
Service dependency degradation
Reprinted from: https://mp.weixin.qq.com/s/0hxHkAoL47Fv6EKAleedAg
