Payment Lifecycle - Understanding how money moves

A standard payment involves a payer (the one making the payment), a payee (the one receiving the payment) and a payment channel (IMPS, UPI,etc.) that facilitates this process. Much like grammar decides the semantics of a language, the payment channel decides the semantics of a payment.

Payments can be classified into two groups:

i) Push payments - Initiated by the payer

ii) Pull payments - Initiated by the payee

In this article, we’ll focus on a card payment that has been initiated by the payer (push payment) to understand the payment lifecycle.

An issuing bank is one that issues cards to customers. Customers can then use these cards to make a purchase from a merchant. The merchant’s bank in turn is the acquiring bank. And, the card network (VISA, Mastercard,etc.) is the medium facilitating this entire process. The process can be divided into two phases: Authentication and Authorisation.

In authentication, the identities of the payer and payee are determined. This is followed by a verification of the payer’s credentials. Upon successful authentication, a fund check is done by the issuing bank to ascertain if the payer has sufficient balance to honour the payment. Availability of sufficient funds authorises the payment. The authorisation of the payment transmits a response to the merchant, thus letting the acquiring bank know on how to proceed with the payment.

Payment legs

There are two legs of payments, forward and backward. The former deals with the original payments, while the latter deals with the associated refunds, reversals, or chargebacks.

Then, comes clearance and settlements. Clearance involves card networks sharing transaction data with the issuing and acquiring Bank for reconciliation purposes.

Settlements are handled by banks. In this process money is moved from the issuing bank to the acquiring banking via the payment network. Settlements account for both forward and backward legs of payments.

In the next section we will look at the payment lifecycle on the fusion platform to showcase both payment forms.

The fusion platform runs on a rule-based engine and has different payment states to help in tracking the progress of the payment.

When the payer (card holder) swipes his/her card at the merchant’s site, the payment state is classified as Payment_Requested. In this state, the payment engine authenticates the identity of the cardholder. In the case of an unsuccessful authentication, the state is changed to Payment_Request_Failed.

If the authentication (verifying CVV, cardholder name, expiry,etc.) is successful, the state changes to Payment_Authorisation_Requested. In this state, the issuing bank is requested to authorise the payment, and successful authorisation changes the state to Payment_Authorisation_Recieved.

The cardholder (payer) is now requested to authorise the payment. This can done via OTP , fingerprint scanning, swipe2pay, etc. for e-commerce transactions or by PIN entry for Point-of-sale(POS) transactions. If the cardholder cannot authorise the payment (wrong OTP, PIN, etc.) the state changes to Payment_Request_Declined.

If the transaction is authorised, a payment plan detailing the debit and credit ledgers is prepared. A successfully executed payment plan changes the state to Payment_Effected and unsuccessful one changes it to Payment_Failed.

Execution of the payment plan changes the state to Payment_Effected. In the next state, Payment_Captured, the payment channel is notified of a successful transaction.

In cases where the channel fails to capture the payment or requests for a reversal, the state changes to Reversal_Initiated. In this state, a new payment is initiated, nullifying the original payment. Upon successful reversal, the state is changed to Payment_Reversed and this is captured by the payment channel.

Payment lifecycle - Understanding how money moves

Much like grammar decides the semantics of a language, the payment channel decides the semantics of a payment

Payment Authentication & Authorisation

Payment legs

Payment Lifecycle in Fusion