Payment card processing (whether using a debit or credit card) is the process of reserving and taking funds from a cardholder’s card and crediting the merchants’ account with these funds. The merchant can carry out this process by sending transactions through a payment service provider i.e. A Payment Processor.
When taking payments by credit or debit card, two kinds of transactions are defined by the banking industry and the card schemes:
• Card Present Transactions
• Card Not Present Transactions
Most cardholders will be familiar with the more traditional Card Present (CP) transactions. CP transactions are those where the cardholder is present with their physical credit or debit card. To complete the sale the card is inserted into a card terminal to read the customer’s data from either the magnetic strip or the chip-and-pin device. In many countries, CP transactions require that a secret pin code be entered to authenticate the transaction, or alternatively the customer is required to sign a receipt to authenticate a transaction. The customer may be asked to produce identification to prove that they are in fact the cardholder. Because the customer is physically present with their card, and have authenticated their transaction either by entering their pin number or signing for the transaction, the transaction is considered to be largely non-repudiable, i.e. the customer cannot easily claim at a later date that they did not authorise the payment to be taken from their card. This information is provided for training purposes. This booklet does not deal with Card Present Transactions
Card-Not-Present (CNP) transactions are all those transactions where the customer is not physically present with their card, and it is these kinds of transactions that A Payment Processor exclusively deals with. CNP transactions can come in a variety of different forms:
• Internet (or E-Commerce) transactions
• Mail Order transactions
• Telephone Order transactions
• Fax Order transactions
In all of the cases described above, the customer provides their card information, but at no point is the card itself produced. Because the cardholder is not physically present with their card, it is not possible to confirm the identity of the customer using any of the means described above (although there are alternative means which can be used, and which are discussed later in the document). Merchants, therefore, need to be particularly careful when processing CNP transactions because, in the event of fraudulent use of a card, the legitimate cardholder can repudiate the transaction.
Stages
The stages of a card transaction are outlined below – A Payment Processor, as a payment services provider, are primarily concerned with the authorisation and batching stages of the process. However, it is important to understand all parts of the process, as questions may arise from customers on any or all of the elements below.
• Authorisation: The cardholder pays for the purchase and the merchant submits the transaction to the acquirer (acquiring bank) via a payments services provider such as A Payment Processor. The acquirer verifies the credit card number, the transaction type and the amount with the issuer (Card-issuing bank) and reserves that amount of the cardholder’s credit limit for the merchant. An authorization will generate an authorisation code, which the merchant stores with the transaction.
• Batching: Authorized transactions are stored in “batches”, which are sent to the acquirer. Batches are typically submitted once per day at the end of the business day. If a transaction is not submitted in the batch, the authorization will stay valid for a period determined by the issuer, after which the held amount will be returned back to the cardholder’s available credit. Some transactions may be submitted in the batch without prior authorizations; these are either transactions falling under the merchant’s floor limit or ones where the authorization was unsuccessful but the merchant still attempts to force the transaction through. (Such may be the case when the cardholder is not present but owes the merchant additional money, such as extending a hotel stay or car rental.)
• Clearing and Settlement: The acquirer sends the batch transactions through the card schemes (Visa/Mastercard etc.), which debits the issuers for payment and credits the acquirer. Essentially, the issuer pays the acquirer for the transaction.
• Funding: Once the acquirer has been paid, the acquirer pays the merchant. The merchant receives the amount totaling the funds in the batch minus either the “discount rate,” “mid-qualified rate”, or “non-qualified rate” which are tiers of fees the merchant pays the acquirer for processing the transactions.
• Chargebacks: A chargeback is an event in which money in a merchant account is held due to a dispute relating to the transaction. Chargebacks are typically initiated by the cardholder. In the event of a chargeback, the issuer returns the transaction to the acquired for resolution. The acquirer then forwards the chargeback to the merchant, who must either accept the chargeback or contest it. A merchant is responsible for the chargeback only if she has violated the card acceptance procedures as per the merchant agreement with card acquirers.
Authorisation
Card Authorisation is the process by which the customer’s card details are validated for correctness, and where their account is checked to ensure that there are sufficient funds to complete the transaction. Card authorisation is a complicated business, and the process of authorising a card transaction involves the input of a number of different stakeholders. When processing a card transaction through a Payment Processor, the card details are sent first to your acquiring bank, then to the customer’s card issuing bank via the card schemes. Despite the complexity of each transaction, the authorisation process itself is completed in real-time and takes no longer than 3 to 4 seconds to process.
Note: The card authorisation process is distinct from the transaction settlement process, in which transactions are actually funded.
When authorising a credit or debit card transaction, a number of key card details are used to identify the customer. These are:
• The Credit Card Number
• The Card Expiry Date
• The Card Security Code (the three or four-digit code usually located at the back of the card)
• Any Address Data provided for Address Verification (where supported, mainly UK based)
The Credit Card Number itself may be any length from 14-19 digits. The first six digits of the card number are known as the BIN or Bank Identification number – this identifies the card type (e.g. 4 for Visa and 5 for Mastercard) and the bank that issued the card. The Card Expiry Date is always in the form of MMYY. The Card Security Code (variously referred to as the CSC, CVV, and CV2) is usually three digits long and located on the back of the card. American Express cards have a four-digit CSC number which is located on the front of the card.
It should be noted that the only information guaranteed to be used in the authorisation of a card transaction is the Credit Card Number. The expiry date is usually, but not always, checked. The Card Security Code may be checked, but providing an incorrect Card Security Code will not always result in a card being declined. While A Payment Processor requires that a cardholder name be entered to complete every transaction, this information is gathered for reconciliation purposes only and is not used in any way in the authorisation process itself. The name provided by the customer may not match the name present on the card itself.
The diagram below shows the transaction flow for a standard credit or debit card transaction, outlining each of the key stakeholders in turn.
The card authorisation process is outlined below:
1 The Cardholder makes a purchase via the Merchant’s website. To pay for the purchase, the Cardholder enters key card details that identify their account.
2 The Merchant passes the customers’ card details to A Payment Processor for processing
3 A Payment Processor process the card details provided to the acquiring bank, the financial institution with which the merchant has signed a merchant services agreement. The acquiring bank checks that the transaction is allowed under the conditions of that agreement
4 The card details are processed, via the Card Schemes, to the bank that issued the customer’s card, the issuing bank. The issuing bank is identified based on the BIN Range of the card number provided. The Issuing Bank is the only authority who has access to the customer’s bank account details. The customer’s card details are validated, and the customer’s account is checked to determine if there are enough funds to cover the cost of the transaction. If the details are correct, and there are sufficient funds to cover the transaction, an authorisation code is returned to A Payment Processor granting authority to draw down the funds at a later date. A hold is placed on the funds on the customer’s account to prevent the account from being overdrawn.
5 The Transaction Result, and Authorisation Code (where applicable), are returned by A Payment Processor to the merchant. The transaction is now ready to be settled and funded.
Settlement
Settlement is the process of taking the money that has been reserved on the cardholder’s card at the authorization stage and crediting it to the merchants’ account. Gateways send the transactions to the merchants acquiring bank in a settlement file on behalf of the merchant. This instructs the acquiring bank to debit the cardholders’ card and credit the merchants’ account with the authorisation amount.
There are 2 types of settlement that the merchant can use
Automatic settlement
This is where Realex will automatically settle the transaction on behalf of the merchant. The transaction is automatically put into an open batch once the transaction is authorised.
Delayed settlement
This is where the merchant wants to decide on when to settle the transaction. This may be because they want to check they have the goods in stock before debiting the funds from the customer’s card. The merchant can manually settle the transaction by using the Realex transaction management tool RealContol or they can settle it remotely via XML, sending the message from their own system for example. Once the transaction is manually settled it is put into the merchants’ open batch for the day. The merchant must settle the transaction manually within 28 days of the authorization. However, some acquirers might charge additional fees for “late” settlements.
A batch will be opened when an automatic settlement authorization is sent in from the merchant or when the merchant settles a delayed transaction. An open batch will be created for each Bank Merchant ID that the merchant is processing authorization through. Open batches are closed at 12 midnight for most acquirers and put into the bank’s settlement file. The settlement file is delivered to the bank the following morning. The following diagram shows the transaction flow from authorization to settlement for 2 merchants processing through the same acquiring bank:
The following matrix shows the main Irish and UK acquirers and typical cut of time (note: taken from A Payment Processor).
Transaction Funding
Transaction Funding is the process by which funds for an authorised transaction are transferred from the customer’s bank account to your bank account. This is handled entirely by your acquiring bank – once the batch file has been delivered, A Payment Processor plays no further part in this process.