Continuing our journey to understand the mobile payments ecosystem, let’s look at card transactions, how they happen, and who gets money for them.  Again, please correct me with comments where I’m wrong.

Making a card payment

As everything with card payments, the actual transactions can be very complex and involve a large number of organisations. To understand them, let's look at the four-party model behind most card transactions, where Merchant, Cardholder, Issuer, and Acquirer are linked by a Scheme.

Every payment takes place over several stages:

Authorisation: The Merchant puts together the details of a potential transaction, along with any other information required to authorise it, and sends it, via the Acquirer and Scheme, to the Issuer. The Issuer checks the details, records the 'pending transaction', and sends back an authorisation code.  

Clearing: Once the merchant has delivered the goods or services, it sends the 'transaction' via the Acquirer, and Scheme, to the Issuer.  Since this is less time critical, a Merchant will typically send a batch of transactions at a time.

Settlement: The Scheme debits the Issuer the amount of the payment, and credits the Acquirer.

Funding: The Acquirer pays the Merchant the outstanding amount, less the transaction fees involved.

Who pays for the payments?

Payment organisations are not charities, and need to make money from payments. There are three main ways they do so:

1. Interest on the money they hold, and interest charges to credit card holders. 2. Commission deducted from the funding payments made to the merchants. 3. Regular fees levied on the merchants, and in some cases the cardholders.

Interestingly, the interest portion of this is around half the total revenue from payments.  The regular fees tend to be a relatively small portion.  And the most visible revenue is the payment charges to the Merchant.  These vary enormously based on the Acquirer, the Merchant, the amount of the transaction, and the type of the transaction. However, each charge has two components: the interchange fee (received by the issuer), and the acquirer fee. The interchange fee is typically of the order of 0.7%; the acquirer fees typically bring the total fee deducted from each payment to the order of 2%. [Source: AIB/McKinsey, VISA, PPS].

In the real world …

There may be many components and facilities involved in each step:  The Issuer step includes Programme Managers and Fraud Detection; the Scheme may have a separate ‘Interchange’ or ‘Switch’ to manage the actual payments; the Acquirer step involves Hardware Terminals, Payment Service Providers, and Aggregators; and much else, including of course lots of software.  But all will slot into this basic model.  Some, such as Programme Managers and Payment Processors, take a percentage of the transaction fees (here’s an example); the remainder are typically paid fixed fees or fees based on transaction volume.

There’s also a lot more detail in the implementation.  For example, not all cash flows go from the Issuer to the Merchant.  Merchants may make refunds, or negative payments, against a payment that they’ve already received.  And, in response to a Cardholder complaint, the Scheme may force the Merchant to make a Chargeback. 

Financial institutions like to save money, too, so if there’s a means for payments to avoid some of the steps they’ll use that.  So, for example, if the Issuer and Acquirer are the same institution, the payments don’t need to involve a Scheme.

But that’s it – two payment phases, a good deal of payment switching, and a large number of small commission payments along the route. 

Where does mobile come in?

Mobile phones come in the first step of the payments process.  A mobile phone can replace the Cardholder’s card, and generate the credentials for the Authorisation Request that the Merchant sends.  Typically in Europe (though not in the USA, yet), this will be in the form of an EMV token – an encrypted hash of the transaction details, signed with a secret key known only by the phone.  Mobile phones and pads may also be used by an Acquirer (or Aggregator) as part of the Payment Terminal, to generate the Authorisation Request from a Cardholder’s card information.

See also:

Wikipedia on Credit Cards

IP Pay’s How Merchant Processing Works

Best regards,

Charles