What is a merchant Acquirer?

The average Retailer wishes to accept credit and debit cards from a number of card schemes. A Merchant Acquirer is (normally) a bank who will provide the following services to the retailer.

• Provide a single interface to the scheme for all card related matters
  • Customer authentication
  • Card authorisations
  • Recovering money from the card issuing bank

• Pay all the scheme and issuer fees on behalf of the merchant
• Act as an intermediary in the event of card claims, returns and refunds.

Essentially the Merchant Acquirer acts like a large switch protecting the merchant from having to understand all the detail of all the different card schemes, (VISA, Maestro, etc, etc.). This is discussed in more detail below.

Stage 1 – Customer authentication

From September 14th 2019 there will be a requirement for 2 factor authentication for all card based payments above EUR 30. For “cardholder present” situations this is handled by CHIP and PIN processing at the point of sale. For “cardholder not present”, e.g. internet purchases, then there is a more complex interaction where the merchant acquirer acts as a gateway to the card issuer to facilitate something called Strong Customer Authentication (SCA). The way this is carried out is illustrated below…

Essentially the acquirer takes control of the customer session to create a challenge/response authentication in co-operation with the payment scheme and card issuer. The challenge is normally to provide a one time password (OTP) sent to the mobile phone of the cardholder by the issuer. The cardholder then has to enter the OTP into the acquirer screens, the acquirer passes the OTP on to the issuer who can then confirm the customer is who he he says he is to the acquirer and merchant. The acquirer and merchant can then move onto payment authorisation.

Stage 2 – Payment Authorisation and Settlement

The sequence is roughly:

A. The retailer passes the card through his POS terminal which then dials up the acquirer for an authorisation. The acquirer routes the authorisation request to the appropriate Scheme who in turn routes it to the appropriate issuer, in this case Ron’s Card Issuer. The card issuer checks RON’s card number against the database for available funds and finding there are enough funds available passes a unique authorisation number back to the Scheme computer. The card issuer also reduces the available funds on RON’s account. Note the money may have gone as far as RON is concerned for payments, but not for interest calculation and certainly not out of the card issuer’s bank account yet. The Scheme routes the authorisation request back to the acquirer computer who in turn routes it to the appropriate POS terminal. This all happens in seconds without human intervention.

B. Every night the merchant acquirer sucks a file of transactions out of the retailer’s POS terminal or system which consists of payments for a number of different Schemes including the one Ron’s card subscribes to. The acquirer’s computer then sorts out the transactions into piles for each Scheme. It combines the transactions for each Scheme with those from other retailers for that Scheme and sends a file of transactions to each Scheme. The Scheme computer then sorts out the incoming files of transactions into a pile for each issuer and sends the Scheme’s transactions to the issuer.

C. The card issuer’s computer would take the file of Scheme transactions and

1. 1. check that the transactions have been applied and apply those that have not (e.g. if the retailer has floor limits then some transactions will not have been authorised by the card issuer’s computer).
   2. change the status of the balances in the card holder’s account to not having money available for interest (previously authorised transactions would not be available for payment but available for interest).
   3. calculate the bulk payment that needs to be made to the Scheme. This is essentially the sum of the value of the payments minus the interchange fee (which is the income that the card issuer earns as a Scheme issuer). This total is keyed into a bank’s electronic banking terminal instructing the issuer’s bank to transfer the amount payable to the Scheme’s bank account.

The Scheme’s computer works out the amount payable to each acquirer, again this is just the sum of all payments to be made to the acquirer less the interchange fee (the same fee the issuer keeps, i.e. no cut for the Scheme). Again the Scheme operator makes a series of real time payments corresponding to total of the day’s transactions to each acquirer’s bank.

Steps B and C take about 2 or 3 days to complete. Back on the first night the acquirer transfers to each retailer the total value of the transactions acquired that night.

Additionally the acquirer provides detailed information about the transactions acquired for the retailer to use, usually in the form of paper statements but also via web reports and electronic files in certain circumstances.

There are some important aspects of the core payment processing that have been omitted for simplicity, including

1. Hot Card files
2. Refunds
3. Various error processes; invalid card number, unavailable funds, The card issuer’s computer unavailable, acquirer and/or Scheme computer unavailable, POS terminal unavailable etc.
4. Floor-limits
5. International transactions
6. Foreign exchange transactions (not the same as international because of Euro)
7. ATM, cash and cash back transactions.

Related Reports

• SEPA
  
• How can we make substantial cost reductions to Europe’s payments