This is the fourth text in the series explaining how payment cards and wallets interact. The purpose of this text is to provide some details about operations of the interchange network in the process.
In this text, I will use the term “interchange network” for any card network, and for all components that do not belong to payment gateways and payment processors that are between them (this will also include interface processors provided by card schemes to both payment gateways and processors, and all systems between interface processors on the acquiring and the issuing side).
After the transaction message is created by the payment gateway it is injected into the interchange network. The interchange network’s role is to route this transaction to the right issuer, and to route its response back to the acquirer which sent the message.
About message interleaving
It is important to note that messages handled by the interchange network are treated as independent packets. That means, although the contents of one message cannot be interleaved with the contents of another message, the order of the responses can – for example, a payment gateway could be sending authorization request 1 (A1) and authorization request 2 (A2), in that order, but it might receive back from the interchange reply for A2 first, and only later (or never!) reply for A1. This is an interesting problem to solve when building a payment gateway (which on its side communicates with its clients in more RPC-like manner), and one approach to deal with this would be to implement the gateway in the similar way as a single-threaded multi-client server (there are many examples on internet, they were a popular method of trying to solve C10K problem). We might come back to this problem in a future text.
Immediately after receiving the transaction from the payment gateway, the interchange network verifies that message is correctly formed – this means checking that currencies within the message designate real currencies, that if the message is referring to another transaction (for example a reversal), that it contains all the fields used for linking (without checking if this data indeed links to an existing transaction), and that transaction is allowed to the merchant (for example not all merchants are allowed to send money to payment cards). In case a violation is detected in this process, a response is immediately sent back to the payment gateway without sending the message deeper into the interchange network.
In case the message passes the format and the fields verification, it is sent deeper into the interchange network to be routed to the card’s issuer.
How interchange network knows where to route the message
To know where to route the message, the interchange network needs for each message to know two parameters, as expected, the message source and the message destination. The message source is inserted into the message by the payment gateway (there is a field for putting the acquirer ID and merchant ID in the transaction message), but the interchange needs to discover the message destination. To do this, the interchange analyzes the card number (PAN) that is embedded in the transaction message. A card number is made of 3 components:
- First 6 (or 8) digits are called BIN (as Bank Identification Number), or less common IIN (Issuer Identification Number, since today not only banks issue cards)
- Digits identifying the account (random number, not calculable from actual bank account number)
- 1 Control digit, that is calculated from the rest using Luhn algorithm
The routing system of the interchange network takes the card number, extracts the BIN part from it, and then looks it up in the internal database. BIN information include:
- Who issued the card and from which country
- Which payment processor is responsible for authorizing these cards
- Information about the card level (is it debit, credit, corporate card, or something else)
- What currencies this card stores its balance in
- What currencies the issuer will pay to the card scheme for the transactions made by this card
- More information about the card behavior
Supplementing transaction with more data
Once it gets this information about the message destination, the interchange network adds some additional fields to the message. The message gets its unique interchange network ID (banknet reference), and it fills the fields related to how much to bill the cardholder. Since merchants mostly don’t know which currency the card holds (unless they perform BIN database lookup themselves), they pass the transaction value in the merchant’s currency. The interchange network converts this value to the billing currency (the one the cardholder has on his/her account), and to settling (clearing) currency (the currency in which the issuer will be paying to the card scheme). This way, the payment processor receives all the monetary information about the transaction that it needs to decide whether to approve or decline the transaction.
Interchange fee
The card level and the issuing country from the BIN database, in combination with the data extracted from the merchant ID, are used to calculate the fee that the interchange network is going to charge for processing the transaction (interchange fee is charged only for transactions that actually settle/clear, all issuers who charge for failed transactions are simply greedy).
If a transaction is helping the merchant to sell something, then it is considered to be more beneficial for the merchant, and the merchant is required to pay for processing of the transaction, so the interchange fee would be negative from the merchant’s point of view, but it would be considered positive from the issuer’s point of view, since they would receive a portion of it.
If the transaction provides services to the cardholder on the issuer’s behalf (such as pulling cash out), that transaction is considered to be more beneficial for the issuer, and the issuer needs to pay for it, so this interchange fee would be positive from the merchant’s point of view, but negative from the issuer’s point of view.
Delivering the message to the payment processor
At this point, the interchange network knows the destination of the message (which is expanded with additional fields) and delivers it to the payment processor’s endpoint server. Messages are here again delivered as packets, so the interchange simply delivers the messages one after another, without waiting to get a reply for each (it is more like a message queue than RPC). Since now the payment processor needs to eventually pass the message for approval to the wallet, again in RPC-like fashion, the payment processor faces a similar complexity like a payment gateway on the acquiring side.
The payment processor has a predefined time window to respond to the message (otherwise on the acquiring side, the payment gateway would consider the transaction as rejected, and responses a rejection to the merchant). This time is of the order of several seconds (interchange network is trying to reduce this time over the years). If a payment processor doesn’t respond within a defined time frame, the interchange network will send a response to the payment gateway, stating that the transaction was rejected due to the time-out on the issuer side, and at the same time it will send a reversal advice to the issuer (which will instruct the issuer to reverse the transaction).
In case the payment processor doesn’t respond within the predefined time, it is counted as a rule violation by the payment processor. Depending on the number of violations during the month, the payment processor might be fined by the card network.
Routing the response back to the payment gateway
The transaction response message contains almost all the same fields as the request (with addition of the response code that indicates if transaction is approved or not (and potentially in which amount)). Among these fields, there are also the acquirer ID and the merchant ID which are used by the interchange network to forward the reply to the originating payment gateway. This is a relatively straight forward operation.
The payment gateway responds to the merchant
If the payment gateway receives a response within a defined time, it parses it and creates its own response for the clients and sends this response back to the client (which is waiting on its RPC-like call).
If the response doesn’t come within a defined time, the payment gateway should create its own response to the merchant notifying it that contacting the issuer has timed out.
In the next text we will see how payment processors participate in transaction processing.
Leave a Reply
You must be logged in to post a comment.