Paying at the POS using Open Banking payments
Here, we are only going to consider the implementation of Open Banking Face to Face payment services in Bricks and Mortar stores. Similar considerations will also apply to e-commerce, but these are really only a subset of the wider considerations pool.
I have intentionally started this exercise with a blank canvas, choosing to disregard any considerations that might otherwise be made for developing a retail payment system that would need to integrate with or operate alongside existing or future retail payment systems.
The POS ecosystem for Open Banking
A synopsis of the Open Banking payment service ecosystem identifying the elements and describing their function.
The Merchant
Also known as the shop, and marked as such on the diagram. The Merchant sells goods to the consumer and every sale includes a payment, which might be cash or it might be something else. For this exercise, we are are looking only at cash and Open Banking payments, and as cash does not impact the Open Banking processes, we can reasonably ignore cash.
The Merchant is an Open Banking Merchant, accepting Open Banking payment transactions in exchange for goods and services.
The Consumer
Also known as the customer, the Consumer buys goods and services and generally makes sure that they have the means of payment at hand prior to making the purchase. This may be cash, which we aren’t interested in, or it may be an alternative to cash, like Open Banking payments.
If the Consumer is going to pay with Open Banking payments, they will need to have availed themselves of all the artifacts required for those Open Banking payments, which at some point may include a card.
If I were pushing the Open Banking payments agenda, I would push for an Open Banking logo that would indicate that Open Banking payments are available in store.
The Card
I’m not saying it has to be a card, but whatever it is, it needs to support some derivation of an ID. The credit card is a nice format, well recognised and it shares the same dimensions with the Raspberry Pi. It doesn’t need to be a card but it does need to be somewhere that can store credentials relating to Open Banking payments, and cards can do that for not a great deal of cash, and the personalisation processes are well understood.
It makes sense for it to be a card, because cards are cost effective and the card technology can be transferred to the mobile phone, allowing the payment option to span demographics and geographies.
The Merchant of Record
Payments actioned through the implementation of Open Banking systems and services are instantaneous Account to Account (A2A) payments that are completed in real time. However, whilst the initiation of the transfer can be confirmed, as it can be seen “leaving” the payers account, the same is not true for the transfer of funds arriving in the receiver’s account. This does not cause any issues where any further action is triggered by funds landing in an account (see the post on HMRC and Wise), but it does cause a headache for Retail – the introduction of a Merchant of Record resolves this issue.
The Merchant of Record acts as a man-in-the-middle, essentially addressing two logistical barriers:
- There is no mechanism by which the Open Banking (or Faster Payment) messaging logic is able to confirm that a transfer of funds has landed in the recipients account.
- Retailers (especially the larger ones) prefer to reconcile incoming payments against settlement files, and not against individual purchase transactions. This isn’t a card scheme thing, it makes large retailer sense.
The Merchant of Record fills the notification gap by guaranteeing the incoming consumer payments to the merchant making the sale, thereby alleviating the issue around confirmation of transfer. This is not as onerous as it might sound as in virtually all Open Banking payment transactions the money will land – I do have direct experience of OB money going missing – but retail is not in the habit of giving goods away without the assurance of completion.
The Merchant of Record, acting as the Merchant of Record on behalf of a merchant, will receive all OB funds for all purchases made by consumers at that merchant. Because of this, it would make sense to aggregate the incoming payments into one outgoing daily payment to the merchant, which alleviates the challenge of Point 2.
The POS Terminal
The POS Terminal – and by association, the Card – is a means by which the Open Banking payment transaction can be initiated. When a payment request is keyed by the Merchant cashier, the POS Terminal establishes a connection with the Merchant of Record (MoR). The payment data collected during the payment initiation stage will be shared with the MoR, which will then complete the Open Banking authentication on behalf of the Consumer.
The POS Terminal is not required to establish which Financial Institution (FI) the customer is banking with as the payment will have been initiated using a card issued by that FI – the POS Terminal will know.
The Bank Accounts
All the Bank Accounts are standard personal and corporate accounts that support Open Banking along with the more established payment mechanisms.
The Merchant of Record has the ability to drive transactions from the Customer Account and from the Merchant of Record account – maybe even the Merchant bank account should the need for refund and chargeback processing arise, but the precise details of remedial account transfers would depend on the nature of the “to be determined” payment rule book.
The Merchant of Record bank account is implemented as a staging post for incoming customer payments, allowing multiple incoming payments to be aggregated into a single “settlement” payment to the Merchant, possibly on a daily basis.
There are three main drivers for this approach:
- Few banks provide real-time information on incoming payments.
- Incoming payments may be delayed for up to two hours (Faster Payment guidelines, though arguably not insurmountable).
- The information content (reference field) of a Faster Payment doesn’t have the capacity to identify a single Point of Sale payment.
This Bank Account configuration is essential to address the shortfalls of an A2A transfer process that is adapted for retail.
The Settlement File
I have used the tape icon as I remember creating BACS files, writing them to tape and then handing them over to a motorbike courier for transportation to the bottom end of Burnt Oak Broadway in Edgeware.
The motorbike courier was a daily thing – weekends and bank holidays accepted – accumulating in one file, all the transaction requests originated since the creation of the previous file.
Since all Open Banking retail payments will be processed by the Merchant of Record, and therefore initiated and completed by a POS Terminal attached to the Merchant of Record – with possibly limited transactional interaction with the checkout – the Merchant of Record is essentially going to be guaranteeing the Open Banking payments.
The Settlement File is needed to allow the Merchant to reconcile the incoming aggregated bank payment against the individual “authorised” payments.
I would use a standard industry file format, restructured to support Open Banking transactions.
The Open Banking Transaction Process
Open Banking payments are not natively suited to retail because they are account-to-account transfers, and whilst it’s true that account-to-account transfers may look simple in principle, they add significant complexity to an inherently simple process and a set of well established and well understood payment practices.
Ignoring the global payment ecosystem – cash or card – there are always going to be Consumers and Merchants, there are always going to be devices for identifying Consumers and devices that accept those Consumer devices for doing payments at Merchants, and then there are always going to be mechanisms for moving value from Consumer to Merchant.
It looks very much like any payment proposition is always going to include some sort of payment card equivalent, some sort of POS Terminal equivalent, and some sort of money movement process.
Card Issue
The Financial Institution issues a card (or similar device) to a Consumer. The device identifies the Consumer’s account and provides a set of credentials necessary to connect with that account – there will be security features to prevent unauthorised access to the payment facilities, but this exercise is about establishing a process that works in isolation.
POS Terminal Provision
The consumer goes shopping and uses the card (or alternative device) to initiate an Open Banking payment at the Point of Sale. The Consumer uses the Open Banking POS Terminal, which is plug-and-play integrated into the checkout software and is also connected to the Merchant of Record platform.
Transaction Authorisation and Completion
The Merchant of Record uses the Consumer credentials to authenticate access to the Consumer’s Bank Account, based on permissions already given and the fact that the Financial Institution provided and issued the credentials used to initiate the transaction.
Assuming that all the transaction parameters are in order, the Merchant of Record initiates a Faster Payment to the Merchant of Record bank account, on behalf of the Consumer. The Merchant of Record uses the successful initiation of the bank transfer to respond positively to the POS Terminal, thereby completing the transaction at the point of sale.
The Merchant of Record holds the full details of the payment, as provided by the POS Terminal, and can use the Faster Payment reference field to link the two.
Payment Guarantee
The Merchant of Record is essentially guaranteeing the payment in the same way that a legitimate card authorisation guarantees future payment, which means the Merchant can act on the response received by the POS Terminal rather than waiting to confirm receipt of the cash – crucial for retail.
Aggregated Settlement
The Merchant of Record aggregates the transactions for the settlement period – maybe a day but in any case, the elapsed time since the previous settlement – timing is less significant than having a definite settlement period that is closed at both ends.
Settlement Files
The Merchant of Record will generate a Settlement File containing all the transactions pertinent to a particular Merchant, closed at both ends, and this will be provided to the Merchant for reconciliation between transactions authorised and transactions settled.
Settlement
The Merchant of Record will pay the total amount represented by the Settlement File into the Merchant Bank Account, which is a single payment representing all the payments collected by the Merchant of Record in the given settlement period.
Open Banking Integration
There are reasons why card payments have been so successful in the past and remain so today. If you break down the requirements of a consumer to merchant payment service, they are the same today as they have always been. The evolving ecosystem, developed by the card schemes, is fundamentally straightforward and is no different, logically, to the original framework processes devised and implemented in the 1950s.
Any alternative to the existing global card payment ecosystem is inevitably going to be more complex than the established card ecosystem, and to gain traction, it must also be simple – to the point of being a no-brainer – for merchants to implement.
There may be local variations on payments – like ideal in the Netherlands – but these variations do not usually make it to over the counter, face-to-face transactions.
The challenges facing alternative payment propositions are discussed in the next section, which hasn’t been written yet.
Explore the Future of Payments
The global payment ecosystems continues to evolve with technologies like AI, tokenisation, and real-time payments.
Stay ahead of the game by diving deeper into the world of payment processing.
Have questions or need expert insights? Contact us.
