QR Payments - Innovate, don't imitate!
Instead of innovating payments, the new breed of QR/A2A payment schemes too often think of their system as a “primitive” form of card payments. Or, they treat payment merely as an enabler for their ambition of becoming a virtual bank. There is too much data, too much functionality and not enough effort to make the payment process better.
In this post, I want to make the case for removing data from QR payments.
In my view, the principles of any new payment system should be: “Payment moves money efficiently, anonymously and conveniently (for the customer). Use of account information is kept to a minimum. There should be no personal data.”
With QR Payments[1], there is no need to hand over account data to the merchant, to the customer or to their service providers.
If governments, merchants, banks, or the myriad of “value add” service companies want more data, maybe for a loyalty program, they should ask. Payment systems should not secretly collect data that is not strictly necessary for the transfer of money.
The Problem
Historically, payment systems have been plagued by the acquisition, processing and storage of sensitive data. First this practice facilitated fraud, and then it became a privacy issue as well.
Since the early days of the BankAmericard, the underlying principles of electronic payments have not changed and the problem persists to this day.
The solutions so far centered around the desensitization of data (tokenization, EMV, 3D) and the enforcement of data security standards (PCIDSS). All of it expensive, clunky and not addressing the underlying issue - the unnecessary proliferation of data.
Even if the industry succeeded in preventing data compromise or at least the use of comprised data for fraudulent transactions, the problem of privacy still remains. We all know that the best laws will not stop the government from eventually using the available data against their citizens.
Not all existing solutions are entirely useless. EMV may still have a role in offline transactions, transit ticketing, and in countries that have invested too much into the acceptance infrastructure already.
PCIDSS, on the other hand, should be a thing of the past for the merchant, and have a more limited scope for service providers, and 3D Secure will hopefully not be needed anymore.
Tokenization makes sense if thought of as a reference number for a particular transaction that has been pre-authorized on the customer-side systems, and not as a substitute for an account number.
In my view, pull-payments should be stopped altogether. The customer should always initiate a push payment, or for corner cases, have a pre-authorized amount or dedicated balance ready for the merchant to trigger a push payment.
QR payments mostly already work that way. There are only two data elements needed for the actual movement of money:
-
The “address” of the service provider
-
A reference to a pending transaction
Customer-presented QR Payment
The EMV specification for customer presented QR code (1) is nothing more than the old magnetic stripe in new, but already tattered, clothes. Thankfully, it will only be used in face-to-face transactions and only for applications such as transit ticketing.
If it has to be used, then the account information should be either generic or used as transaction reference numbers. The reference number needed to find a pending transaction can go into the transparent templates of the QR data.
Since the customer presented the QR code, the customer can also set up a pending push-payment transaction that can be triggered by the merchant.
Merchant-presented QR Payments
In the case of merchant-presented QR payment transactions, the additional data can only come from the sending QR provider, and the merchant can only get the data from the receiving QR provider. Nevertheless, the same principle applies. There is no need for anybody to hand over data to the merchant or the merchant’s QR provider.
Of course, the customer needs to know where to send the money. At least the merchants have to reveal their account number to the customer, don’t they?
Well, not really! The nature of QR payments is that the merchant or the customer create a “pending” transaction in their respective backend system. They should therefore have no problem assigning a unique reference number to that transaction. The opposite side in the payment transaction only needs to contact the operator who runs the backend system. Using the reference number, they can use the pending transaction to send or receive the money.
In the traditional card payment world you may call this tokenization, however, this would not be entirely accurate. The transaction reference number identifies a transaction, while most payment tokens identify an account.
Of course, the merchant QR code contains data such as the merchant name that allows the customer to identify a transaction.
Subscriptions and Account-on-File
I was wondering whether my premise applies to account on file and subscription services, or whether they would still need the account information.
One could argue that account numbers are still necessary for regular automated payments or for services that conduct convenient transactions by using accounts on file. My solution would be to introduce pending transactions that are good for multiple payments over a defined period of time.
For instance, if somebody has to pay PHP 3000 every month to a merchant, they could set up a pending transaction that is good for one year and a single monthly payment of Php 3,000.
The customer may opt to withhold the merchant name from the sending service provider and give the pending transaction a name by which to remember it.
Such a pending transaction would show up in the e-wallet as “subscription” or whatever terminology is most intuitive for the customer. The pending transaction is under the customer’s control. The merchant has no say in this.
Since the pending transactions “live” entirely on the sending side, customers would have no problems cancelling subscriptions, setting limits, or control the extent to which they want to authorize recurring transactions. It would be easy to find subscriptions and even easier to cancel them.
Of course, the receiving service provider will have to maintain a record of pending transactions. Every time they receive money with a reference number, the pending transaction record will tell them to which account they should credit the money.
Fees should be charged on the sending and receiving side of the transaction separately. The customer pays a fee to their e-wallet provider and the merchant pays the payment provider.
Setting up a pending transaction can be achieved in many ways. One way that would also minimize the implementation cost would be to generate QR codes that can be scanned by the e-wallet of the customer.
To achieve this, we would need more data in the merchant-presented QR code. Here is a list of data elements that illustrate my point:
| Field Name | Meaning |
|---|---|
Unique Identifier |
Need to link to the merchant account info. This is the unique identifier that holds everything together |
Transaction Name |
A name for the customer to recognize the pending transaction, especially when the customer has multiple pending transactions with the same merchant. |
Effective Time |
The transaction reference is valid from this date/time. An attempt to “pull” money before that date/time will fail. |
Effective Duration |
This is the period starting with the “Effective Time” during which the transaction reference is valid. |
Transaction Frequency |
The number of transactions per period. For instance, exactly 1 per month or up to 12 per year. |
Transaction Amount |
Exact amount or upper limit per transaction. For instance, exactly Php 3,000 per transaction, or app to Php 1,000 per transaction. |
Approval Policies |
Information about the approval of each transaction. For instance, whether every transaction still needs an explicit approval (maybe by responding to a message from the wallet). |
Cancellation Policies |
Information about the cancellation of the pending transaction. For instance, how many transactions still go through after the customer cancels. |
Signature |
Any cryptographic method to prevent changes in the record without involvement of the customer and their service provider. Such a signature could turn this record into a crypto token as well. |
When a customer signs up for a recurring service or wants to allow a merchant to conduct future transactions with no further input, then the merchant could create a QR code with the desired parameters, such as for how long, how much and so forth.
The customer scans the QR code it and approves everything in their e-wallet app. Finally, the service provider will set up a pending transaction, which the merchant can query to see whether the customer approved it.
Pending transactions should be transferable between e-wallet providers. For instance, if the customer is using wallet A for a subscription, but wants to use wallet B in the future, then the wallet should have an easy option to move the pending transaction record to the new wallet provider.
On the merchant side, this should be transparent because the reference number of the pending transaction is unique to the transaction and not to the e-wallet provider or the customer. Strictly speaking, a pending transaction record could be moved to another customer as well, but this seems to be a nice to have.
Considering the previous paragraph, pending transactions records could be traded like crypto tokens. For instance, a customer may give a subscription to somebody else as a gift.
Not covered in this post
I suspect that a lot more needs to be said about dispute resolution, liability allocation and fraud detection. However, I am convinced everything can be done at least as well as in current systems, maybe better. I also question whether electronic payment systems should be responsible for reducing authorized fraud.
If the government forces payment service providers to snoop into all aspects of the private life of their citizens, that can still be done. But it would be a deliberate action that is obvious to the customer and not baked into the system, ready for abuse.
There is also the question of agentic systems that do purchases on behalf of the customer. The issue with such systems is that the payment part of the purchasing process hasn’t changed. It still relies on the customer handing over their data to a system that should not have it.
References
publicdomainvectors.org, “Bodybuilder cartoon.” Jun. 2024, Accessed: Nov. 07, 2025. [Online]. Available: https://freesvg.org/bodybuilder-cartoon.