Over the past few years, payment digitalization has grown exponentially. From utility payments, insurances, microfinance, loyalty and many more financial use cases, digital banking and payments platforms are now processing millions of transactions in a day. mobiquity® is one such leading digital banking and payments platform that powers digital financial services for over 80 banks, financial institutions and telecom operators catering to over 120 million consumers and processing 7 billion transactions annually.
To meet the scale of transactions and diversity of use cases, we have built mobiquity® as highly scalable, reliable and flexible digital banking and payments platform. In this article, I will share my experience of engineering mobiquity® the next gen digital banking and payments platform.
Design Constraints:
To support diverse lines of business in a uniform way, mobiquity® platform implements a more generic way of handling payments with the design constraints mentioned below:
- Any addition of a new line of business does not impact core payment processing platform.
- Maintain a single code base for all our clients. Extensibility at core to meet changing needs and client specific customisation without changing core platform.
- Consistent money movement
- Immutable
- Auditable
- Zero Sum Principle of accounting
Getting the Architecture Right
The journey started with finding the best architecture pattern to fit within design constraints and ended with an event driven micro-service architecture mix of choreography and orchestration. Our engineering team re-wrote all our code into modular services built on top of a messaging infrastructure. At a high level, the architecture is as below.
 100vw, 1268px” data-src=”https://www.comviva.com/wp-content/uploads/2020/09/blog1.jpg” data-srcset=”https://admin.comviva.com/wp-content/uploads/2020/09/blog1.jpg 1268w, https://admin.comviva.com/wp-content/uploads/2020/09/blog1.jpg 300w, https://admin.comviva.com/wp-content/uploads/2020/09/blog1.jpg 1024w, https://admin.comviva.com/wp-content/uploads/2020/09/blog1.jpg 768w” /></p>
<p>All these micro-services are controlled by a service orchestrator built in-house and flexible enough to stich any business flow using configurations. Each business flow consists of a number of command events or messages which are served by different micro-services asynchronously.</p>
<p>The system is built for high performance and scalability. Provided below are a few mechanisms we implemented to handle performance and scalability requirements:</p>
<ul>
<li>Extensive parallelization of processing with the competing consumers pattern, by having multiple parallel running (micro) service instances.</li>
<li>Independent scaling of processing components, to more flexibly manage needed capacity, and</li>
<li>Using optimistic locking, to avoid the need for complex distributed locking mechanisms which was a bottleneck in earlier monolithic architecture.</li>
</ul>
<p>These patterns ensure that design is scalable and industry proven.</p>
<p><strong> </strong><strong>Getting Payment Processing Right</strong></p>
<p>mobiquity® core is payment processing which has to be reliable and fault tolerant. The conceptual model of the mobiquity® Payments processing is based on the ideas of double-entry bookkeeping. The Payments Platform inherits three key principles from<br />
double-entry bookkeeping:</p>
<ul>
<li>Immutability of transactions (once created, the payment transactions are immutable: if an transaction was created in error, a new corrective transaction needs to be created)</li>
<li>Auditability of all money movements (reliably stored and cannot be changed)</li>
<li>Error detection based on the zero-sum principle. Every entry to an account requires a corresponding and opposite entry to a different account.</li>
</ul>
<p>The processing of a payment transaction results in money movements to and from accounts. The zero-sum principle also originates from the double-entry bookkeeping and zero-proof bookkeeping, and in this context it means that sum of amounts (+ vs -) in each transaction has to be zero. For instance, a typical payment transaction will involve the collection of the money from a customer for a service (e.g., bill payment), paying (disbursement) of a partner (e.g., recharge operator), as well as obtaining a service charge for business. These three entries will constitute a transaction, and the amount of money collected from the customer has to equal the amount of money obtained by partners and businesses.</p>
<p>The zero-sum principle is a simple error detection mechanism, especially useful it in a loosely coupled distributed systems at scale. Processing of the transaction will results in several transactions, each potentially involving integration with different payment service providers and banks. As delays, network, and other failures will unavoidably happen, zero-sum principle provides a solid method to detect if any errors happened.</p>
<p>These principal are achieved with below three main data objects used for<br />
payment processing.</p>
<ul>
<li>Entry describes a single instance of a money movement to or from an entry (a customer, partner or business)</li>
<li>Account represents the entity in payments, capturing all entries of that entity. The sum of money amounts in the account entries represents its balance</li>
<li>Transaction captures the payments for encapsulating all money movements among the involved parties (customers, partners, and businesses)</li>
</ul>
<p><img decoding=)
https://medium.com/@mfs.techblog/engineering-the-next-gen-digital-banking-and-payments-platform-5052cd125c72
