4-Party Model: a step-by-step process description

step-by-step card transactions

First, the step-by-step process outlined in the following applies primarily to card transactions and uses reference to cards. The card transaction processing model is the basis of contactless payments, mobile payments, payments made using wearables and payments made using wallets. The technologies might differ but the logic and data content are consistent – the step-by-step outline below is therefore relevant to all.

To begin with, the cardholder is in possession of a payment card (Credit or Debit) that has been issued by the cardholder’s Issuing Bank, or alternative, authorised Financial Institution (FI). The payment card contains a series of cryptographic elements that will allow the card issuer to authenticate the card, and transactions, as genuine.  

Step One: Cardholder presents card to Merchant

The cardholder is making a purchase, has arrived at the checkout and has presented their card to the Checkout Operator or to a Semi-Attended Customer Activated Terminal (SACAT) – self-checkout to you and me.

The Merchant Terminals, or Point of Sale (POS) devices will have been certified by the Card Schemes during manufacture and configuration, and will contain the cryptographic keys necessary to validate the incoming card.

The POS device generates a payment request using the merchant details, the transaction amount and the appropriate card details.

Step Two: Authorisation

The merchant systems, including POS, SACATs and backend processes, generate an authorisation request, including cryptographic safeguards, that is sent to the Acquirer.

The authorisation request is formatted according to the Acquirer’s interface specifications, based on their interpretation of the global standards they have adopted. Switching Acquirers can be problematic as the standards may have been interpreted differently.

The authorisation request is delivered to the Acquirer for onward routing.

Step Three: Acquirer to Issuer via the Card Scheme

The Acquirer manages the relationship with the Card Schemes, along with the physical connectivity.

The incoming Cardholder transaction, or authorisation request, is checked for its basic information content and integrity, which amongst other things will reveal the identity of the card issuer, and therefore the appropriate Card Scheme routing.

The Acquirer sends the authorisation request to the Card Scheme associated with the card, from where the Card Scheme sends it on the Card Issuer.

The Card Scheme isn’t therefore a part of the logical transaction process, although it is very much a part of the physical process. This is why it isn’t included in the 4-party model, unless the 4-party model includes the Interoperability Domain – essentially the 5th party.

The Card Issuer receives the authorisation request and checks the incoming transaction using an assortment of validation techniques that will depend on the nature of the transaction. For an EMV transaction, the authorisation request will include a cryptogram (Authorisation Request Cryptogram – ARQC) generated by the chip – or other EMV compliant processes – that can be authenticated by the Card Issuer. 

This is possible because each card has a set of unique keys derived from a master key and an algorithm based on the PAN, which the card uses to generate the ARQC. The Card Issuer is able to regenerate the unique derived keys from the original master key, and the PAN provided in the authorisation request. Once the keys have been re-created, the Card Issuer is able to validate the ARQC and therefore the card and the transaction.

There are other things going on but this is probably the most important, and it has never been compromised!

Step Four: Issuer to Acquirer via the Card Scheme

Once the authorisation request has been validated and the account has been checked for validity and the availability of funds, the Card Issuer approves (or declines) the transaction and generates an authorisation response. 

The authorisation response will include a code indicating the approval status of the response and another cryptogram (Authorisation Response Cryptogram – ARPC). This time, the cryptogram can be used by the chip on the card to authenticate the response – this ability isn’t widely used today as it is not physically possible for a contactless transaction, and is purposely not implemented for Quick Chip transactions.

The authorisation response is returned to the Card Scheme for onward delivery to the Acquirer.

Step Five: Authorisation Response delivered to Merchant

The Acquirer receives the authorisation response from the Card Scheme and it is passed on to the Merchant.

The merchant systems will authenticate the response and act on the result; if the authorisation request is approved, the Cardholder transaction completes, if it is declined, the Cardholder will need an alternative means of payment.

Step Six: Transaction Completed

The Cardholder entered the Merchant premises to avail themselves of some product or service provided by the merchant, and elected to pay using a payment card. The transaction was approved by the Card Issuer according to steps one to five, and to complete the process, step six sees the Cardholder walk away with their intended product or service. 

four-party settlement

Settlement is based on the principle of a Merchant Settlement file being generated by the Merchant, which is based on the approved authorisation requests received and completed by the merchant in the current business day.

Settlement is a complex process and is described and explained separately, but in principle, money flows from the Cardholder account at the Card Issuer, via the Card Schemes, to the Acquirer and then to the Merchant.