A bit of a sensational title, but in my opinion, Australia is falling behind in contactless payments.

Background

By this I don’t mean the use of PayWave or Tap & Go. According to the RBA, 44% of transactions were made by mobile wallets, 54% were made by contactless cards, totalling 98% of retail transactions.

QR code payments have become synonymous in various countries around the world including China, Korea, Malaysia and Japan. It isn’t that QR code is a superior technology or provides an enhanced user experience compared to contactless payments (it does not), it is the way that QR codes democratises B2C payments that is key.

In Australia, if you own a business, a card reader (commonly referred to here as an EFTPOS machine) is pretty much essential. Given <2% of retail transactions are not contactless, you wouldn’t be getting many customers otherwise! This requires dedicated hardware and fee payments to a bank or payment provider (like Square) to process each transaction. There is no “fee-free” payment option for collecting contactless payments, it is an inherent part of the industry and a major business model for many payment providers.

There are various fees collected in a single transaction, and Square actually has quite a good breakdown of how it works here. Australia is also planning to ban card surcharges by around mid-2026. This, for the most part, would push the onus onto the business.

The funny thing is, Australia already has a fast, modern and mature payment system that has no fees.

The New Payments Platform (NPP) was implemented in 2018 as a replacement for the old ‘clearing house’ payment system that was originally used for paper transactions such as cheques.

Since its inception, it has quickly become the backbone of the finance sector in Australia, processing more payments than all credit or debit cards combined. However it is mostly used for P2P payments, commonly between individuals, businesses and some B2C payments usually via an invoice.

Generally speaking, it isn’t used for in-person payments.

I feel like this is a missed opportunity. All the Australian banking apps have the capability of making payments via Osko and the NPP, but there is a missing link for how this is handled for in-person payments.

There has been some growing adoption in the e-Commerce industry to support NPP payments, the main example being Amazon supporting PayTo directly from the checkout flow.

RFC 8905

To avoid creating the 15th standard from the most popular XKCD strip, I came across an interesting standard memo called RFC 8905, which defines a URI schema for payments.

They provide an example for IBAN like this:

payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello

But this could easily be adapted to:

payto://payid/0404040404?amount=AUD:200.0&message=hello

Why a URI? This would allow, for instance, a mobile OS to ‘know’ that a link, or QR code is wanting to handle a particular action. You might have come across this with mailto: and tel: which is way of passing the action with a payload to a specific app. Apps can even create their own custom URI handling in iOS and Android.

What could a QR code future look like?

In a nutshell, not dissimilar to how mailto: works. When tapping or clicking on a mailto: URI, the OS sends this request to the default mail app. Some operating systems will also show a picker for which app you would like to open the URI with.

In an ideal world, the handling of payment (payto:) URIs would be one of these default options. I could set any of my banking apps to be the default handler for a URI if I wanted. Upon tapping or scanning a valid URI, it would open the relevant banking app with the details pre-filled with the data contained within the URI payload.

This is an example of what an Osko payment looks like in a mobile app.

If generated by a POS system, the URI would contain not just the recipient details, but also the amount to pay. It could also contain a custom message (like a receipt URL) embedded in the code.

But the amount is an optional field, if the business does not have a POS system, the amount would not be included, requiring the user to enter an amount before proceeding. This provides some level of flexibility, depending on the maturity of the business.

This approach is directly B2C (or P2P technically) - it requires no payment gateway or specialised hardware to complete. Thus, it costs nothing for the business nor consumer. It lowers the barrier to entry, so anyone with an Australian bank account can accept in-person payments.

It is also agnostic of service or platform, unlike other alternatives like Beem or Liven, which require signing up for an account, downloading an app, and linking a bank card to the app.

Another use case would be e-Commerce payments. These often rely on payment gateways such as PayPal, Stripe or Shopify to handle the actual payment processing, which again, comes with fees and surcharges.

When tapping a payment URI as part of the checkout process, the flow would be the same (opening the default URI handler in a different app), although the website might not have an immediate callback to know if the payment has been completed successfully. This could be handled asynchronously, as it’s not a particularly exotic concept.

There are caveats however. The main blocker would be lack of support for customers who don’t have access to an Australian banking app, or wanting to use a credit card. Furthermore, platforms such as iOS and Android are somewhat incentivised to favour Apple Pay and Google Pay respectively as they take a cut on all transactions made using the digital wallet.

Conclusion

I think there is some interesting food-for-thought here, some way to bridge a gap that is costing businesses and consumers billions in fees each year.

A solution needs to nail two key objectives - it needs very low user friction (people hate downloading another app) and the business model needs to work. Something like a PayTo URI is universal and agnostic, leveraging existing technologies to achieve a balanced outcome.