This is the third text in the series explaining how payment cards and wallets interact. The purpose of this text is to provide some details about operations of payment gateways in the process.
We will use the single term “payment gateway” for acquiring payment processors, payment service providers (PSP) and acquiring clearing hosts (ACH) – we will call payment gateways all the systems that are between merchants and the interchange network.
A payment gateway’s purpose is to be the trusted source of transaction data for the interchange network. Relatively small number of companies is allowed to connect to the interchange network and to send transactions to it directly, and these companies serve as a gateway to the interchange for many more companies (merchants) that wish to accept cards as a means of payment.
For the interchange network, payment gateway also acts as a sort of filter and gatekeeper. Payment gateway is there to ensure that only trusted and verified companies can submit transactions into interchange network. On the other hand, for merchants, payment gateway is literally gateway into interchange network, but also facilitator of payments, offering them additional services and much simpler interface than the one supported by the interchange network itself.
Depending on the type of transaction’s source it supports, the payment gateway might offer several interfaces to its clients. There might be one interface for internet (e-commerce) transactions, another interface for POS and a third interface for ATM transactions. Depending on the system architecture, some of these interfaces can be combined into one (for example there might be one interface for card present transactions, and a different interface for card not present transactions).
To generate transaction for the interchange network, a payment gateway needs several different information elements:
- Information identifying the merchant
- Information about the card participating in the transaction
- Information about the transaction itself (value and what is requested)
Information about the merchant
Usually, the payment gateway receives information that identifies the merchant and the specific terminal which belongs to the merchant via its interface to that merchant/terminal (for example, that can be credentials (username/password pair) combined with the network address). Using the information received, it can pull more information from its internal database, which contains lower-level information that was assigned to the merchant by the card scheme (different IDs, type codes etc.).
Information about the card
The amount and structure of the information about the card depends on the type of transaction taking place.
If the card is present (CP), card data is usually read directly from the card’s chip (using either wired or contactless interface). This data contains the card number (PAN – primary account number), the card expiration date, the crypto elements created by card’s chip to confirm the card’s presence to its issuer and PIN information (depending on transaction type).
If the card is not present (CNP) at the place of purchase (normally internet sale, but it can also be mail order or telephone order), a different set of information is provided. If it is an internet sale (so the person in possession of the card is initiating the payment), the payment gateway normally requires the information that should somehow confirm that the person initiating the payment is the cardholder registered with the issuer. In this case the payment gateway performs card 3D enrollment check, and if this check determines that the card is enrolled with 3D security program, there will be an attempt to authenticate the cardholder (this could be by requesting from the cardholder to enter the code delivered only to them via an independent channel, such as SMS or mobile application, or by requesting the cardholder to generate some authentication code using secure application on their phone, or simply by asking the cardholder to provide another password (3D password)). Authentication of cardholder for cards enrolled with 3D security is performed by merchant plugin system (known as MPI). We will not go into details how this system works, but sufficient is to say that for the given card, MPI returns encrypted data which can be used on the issuer’s side to verify that it was the real cardholder who initiated the CNP transaction. This encrypted data from MPI basically plays a similar role to data coming from the card chip for card present transactions.
Information about transaction itself
This data includes most importantly the value of the transaction (amount and currency), and the type of transaction (is it debit, is it credit or is it some other transaction like PIN change or balance inquiry for example). How this information is transmitted depends on the payment gateway interface itself – certain payment gateways might have different endpoints for each transaction type, while others might have only one endpoint with dedicated parameter to indicate the transaction type.
Building a message
Once it has collected all the information about the transaction, the payment gateway builds a message in the format that the card network expects (usually ISO 8583). A message in this format contains:
- information about the card and the value of the transaction,
- many security-related parameters (like was card present, was merchant present, is POS machine attended or not, and many others),
- many fields related to the merchant (location, some address data, associated ID, type of its business),
- some fields related to the reconciliation (couple of IDs of the transaction within the payment gateway, time and date when the transaction happened in the merchant time zone, UTC time when the transaction is inserted into the interchange network), and
- some fields related to the additional fees or currency conversion if it was used.
Executing a transaction
After building the message in the format that card network wants, the payment gateway will send it to the network, and it will wait for the network’s reply. Important thing to note here is that messages are sent as packets to the interchange network, so different requests and responses might become interleaved. The payment gateway’s responsibility is to properly pair response received to the request message that was sent.
Once the reply comes, the payment gateway needs to decode it from the network’s format to understand transaction result, since transactions can be approved, declined or partially approved. After that, it can send its own reply to the merchant’s system, which can then show an appropriate message to the merchant and/or the cardholder.
Settling/clearing of transactions
As mentioned in one of the previous texts, an authorization (real-time component of the payment using a card), ensures only that funds are available on the card, but doesn’t actually move them anywhere. In order to actually collect the funds, merchants need to submit transactions for clearing. Transactions are submitted for clearing by submitting the so called clearing file, which contains list of transactions that are requested to be cleared, and for each transaction there are some additional details included (most important are card number, as always, but also transaction amount and authorization code which was received in the authorization reply message, if the transaction was approved by the issuer).
Often this clearing file is not created by the merchant, but rather by the payment gateway on its behalf – the payment gateway would record all approved authorizations during the day, and then it would, once per day, compile a list of approved transactions and send it to the network for clearing. Usually, gateways expose an API call that allows merchants to cancel an authorized transaction before it is sent to clearing (either by executing an actual authorization reversal, or by simply omitting it from the clearing file and letting it expire on the issuer side).
Additional services usually offered by payment gateways
Normally payment gateways would offer various reporting to its clients (the merchants would be able to see their turnover, they would be able to see the cost of each card transaction). On top of reporting, gateways can offer additional, security-related services to their clients. The most often used is fraud prevention. This service is normally provided to payment gateways by third party, which would usually do some checks based on the card number, the location where the card was used and maybe additional parameters, to evaluate transaction’s probability of fraud. Then, depending on the merchant’s preferences, the transaction can be rejected, or additional information can be requested in an attempt to get extra assurance that the card (and cardholder) is legitimate.
In the next text we will see what happens on the next hop in the communication chain, and how payment networks actually manage to process a huge number of transactions every second.
Leave a Reply
You must be logged in to post a comment.