Displacing card payments – beyond just technology
At Icon we firmly believe that the combination of APIs and Instant Payments will provide a powerful alternative to card payments, particularly in e-and m-commerce. And it’s not just our belief – Ovum predict that the market share of cards will be severely eroded, with Instant Payments overtaking card payments for e-commerce by the mid-2020s. But it’s not yet a done deal – several things must happen to enable this. Firstly, the technology challenges need to be overcome – interoperable API standards, strong customer authentication, transaction risk assessment and so on, all tied up in a seamless user journey. For the sake of argument, let’s assume that’s sorted.
The next challenge will be to convince consumers that ‘API payments’ (which need a generally accepted customer-friendly name) are as safe, or safer, than card payments. Fear of fraud is one of the main reasons that customers do not adopt new payment methods – a survey by Osborne Clark found that over 80% of UK consumers worry about fraud in a cashless society.
There’s also a lot of confusion around consumers’ rights under existing payment schemes, so let’s briefly look at those.
Card payment protection
If I buy goods or services using cash and I’m not happy with what I bought, I have to resolve matters directly with the merchant. If direct negotiations fail I am protected (in the UK) by the Consumer Rights Act.
If I pay by card, suddenly there are at last three additional parties involved: my bank (the card issuer), the merchant’s bank (the card acquirer), and the card network (Visa, Mastercard etc). If I paid using a debit card, my bank is unlikely to get involved unless there was some irregularity with the payment process – for example, I claim that I didn’t authorise the payment, or the amount was different. With credit cards it’s different – part of the ‘value add’ offered by the card issuer is additional protection, and Section 75 of the Consumer Credit Act makes the credit card company just as responsible as the retailer or trader for any breach of contract or misrepresentation by the retailer or trader. The difference in policy is down to profitability – the bigger margin on credit card payments supports the additional level of protection.
In cases of dispute – a problem with the payment or problem with the goods/services – the card issuer and the acquirer engage in a ‘chargeback’ process, which involves the exchange of claims and rebuttals via electronic messages, within a rules framework laid down by the card scheme. If the claim cannot be resolved in this way, the scheme can be called on to arbitrate. The process can be expensive and time-consuming, and organizations that apply intelligent automation can save significant sums.
In Europe, PSD2 lays down minimal protection for API payments. Article 73 says “the account servicing payment service provider [bank] shall refund immediately… the amount of the unauthorised payment transaction”. It is then up to the bank to sort out responsibility with the payment initiation service provider. But that only covers unauthorised payments – for other types of dispute it’s more like paying with cash – the dispute is between customer and merchant, and the payment service providers are not involved.
Even in the case of technical problems with a PSD2 payment, the situation is unlike cards because there is no “scheme” regulating PSD2 payments, hence there is no dispute process and no impartial third party to arbitrate in case of deadlock. A scheme would cost money to staff and run, and there’s no fee structure in PSD2 from which to fund this. From a simplistic viewpoint this is a good thing – it squeezes costs out of the payment value chain – but I don’t think anyone has calculated the probable costs of an unstructured, manual, bilateral dispute process, where the participants may be regulated by different national authorities. Certainly, this will significantly offset the lower “sticker price” of PSD2 payments and make them far less attractive.
There are many types of fraud, and criminals are forever inventing new ways to fleece consumers. PSD2 lays down quite strict security requirements around payments, demanding (in most cases) “strong customer authentication” to ensure that the payer is bona-fide; and linking the customer’s authorisation to the specific payment, so the payer cannot dispute the fact that the payment was authorised, and the merchant cannot use that authorisation for other payments that the payer is not aware of.
One type of fraud that would not be prevented by the strong authentication requirement is so-called “Authorised Push Payment” fraud. This is where a payer initiates and authorises a payment to a fraudster who is pretending to be another party. For example, imagine I receive a phishing email saying that I need to make an emergency payment to the gas company to avoid being cut off, and giving details of the account to which the payment must be made. If I am foolish enough to make the payment, I cannot complain to my bank that they have made an unauthorised payment (because I did actually authorise it), so I must rely on the goodwill of my banks to help me. UK Finance say that financial service providers were able to return 26% of the authorised push payment scam losses in 2017. Currently this only relates to FPS and Bacs payments – as API payments become more popular and volumes rise, the burden on banks providing this support will increase.
It’s not possible to fully protect customers from online fraudsters any more than it’s possible to stop people handing over cash to silver-tongued con artists. But it is possible to go a lot further than the current PSD2 protections.
In the world of PSD2, online shoppers will see several “Pay By” options on the checkout screen. As well as Visa, Mastercard and Paypal, there will be new PISP payment brands – let’s imagine one of those is AcmePay. Already there are two problems; how does AcmePay persuade merchants to include their pay-by button; and how does AcmePay persuade customers to click their button rather than other means of payment? Hold that thought, and just assume the customer does click AcmePay.
AcmePay will communicate with the customer’s bank and pass the merchant invoice details to the bank. The customer logs in to their mobile banking app, the bank presents the invoice, and the customer authorises payment. PSD2 mandates that AcmePay must prove their identity to the bank (so the customer can be sure that AcmePay is an accredited PISP); but there is no requirement for AcmePay or the customer’s bank to do due diligence or authenticate the merchant. This is where a new opportunity arises.
A consumer protection scheme for PSD2
Let’s further suppose that rather than being simply a technical provider of payment initiation services, AcmePay also offers a consumer protection service, backed by a dispute resolution and arbitration service in the style of the card schemes.
This would be attractive to customers as AcmePay could promote shopping with confidence, protected against fraud and cyber crime. It would be attractive to (bona fide) merchants and banks who would appreciate the reduced number of customer complaints and the structured dispute resolution process in the cases where problems did arise. AcmePay would just need to prove the value of the service, so merchants and banks would both subscribe to and promote AcmePay.
It would depend on AcmePay putting risk mitigation measures in place such as KYC and monitoring of merchants and real-time fraud checking, and backing these up with a commitment to ensure the customer and/or bank is not out of pocket if a rogue merchant did slip through the net, or a previously good merchant went bad.
Measures such as these, coupled with a strong brand, would boost customer confidence in using AcmePay, which would essentially become a PSD2 payment scheme. They would not be cost-free, but this is a case where cheapest is not necessarily best. These non-technology service features are crucial to both enable and encourage the large-scale displacement of cards by PSD2 payments.
 Instant Payments and the Post-PSD2 Landscape, Ovum / Icon Solutions, 2017