This post is part of the series I’m writing on Real-Time Digital Payments. You can find the other posts in the series here.
Table of contents
Open Table of contents
Introduction
The introduction of quick payments and real-time payments through smartphones meant that users could no longer be expected to input every payment related detail manually. Initially, this lead to the introduction of aliases. Aliases are simplified identifiers that map to complex payment information, allowing users to send money using familiar handles like phone numbers, email addresses, or custom usernames. They’ve essentially made the UX around payments akin to texting. But as payment systems evolve, I believe they are overdue for a fundamental rethinking of how we identify and advertise payment information.
Alises
Aliases are a fundamental blocks of the payment ecosystem. In fact details like account number and other details like routing number or branch number can also be considered as aliases. They help map payment information to a simple identifier. This is specifically important for real-time payments, where speed and convenience are of the essence.
Early payment apps like PayPal and Venmo used email addresses as aliases. This was a natural choice, as email was already familiar to both users and merchants. Interfaces like POS terminals and QR codes can be considered as a layer of abstraction on top of payment alias. They allow users to make payments without having to remember or manually enter payment details, except for minimal information like the amount to be paid.
When UPI (a realtime payments protocol in India) was launched, it introduced a new type of alias called VPA (Virtual Payment Address). VPAs are basically a unique identifier of the form username@bankname. They are similar to email addresses.
While payment apps allow users to create their own VPAs, they are most often created automatically by the app or issuing bank itself during onbording. This meant that almost all the users of UPI (atleast initially) had a VPA of the form phonenumber@bankname. Some apps like google pay (which was introduced as Tez in India), created VPAs of the form emailaddress@bankname.
However, VPA’s are used as public identifiers. This meant that everyone who ever used UPI, their VPAs (along with their full legal name) are forever recorded in their bank statement along with the transaction details. In fact, This is still the case today! Most users don’t care to rename or delete VPA’s they don’t use anymore. (UPI is a fantastic OSINT tool, will probably write a post on that later). Payment applications have thier own mapping layers on top of VPA’s. For instance, Google Pay allows users to map their phone numbers to their VPA. This means that when a user sends money to a phone number, the app looks up the VPA associated with that number and sends the payment to that VPA.
The latest addition to UPI aliases is UPI number. UPI number is a unique numerical identifier of 8-10 digit or it can also be the 10 digit phone number of the user. UPI number is not widely used and most users just stick with whatever alias their respective payment app has created for them.
India has an obsession with phone numbers. In fact, most of the apps and services in India are built around the user’s phone number. My understanding is that, for a country like India, it is not uncommon even today for users to open and operate bank account without a proper email account setup in the first place. At the time of introduction of UPI, and even today, Phone numbers are probably the most practical identifier for most users in India, because of the strong KYC requirements associated with it.
However, I am not a fan of using phone numbers as aliases. They have issues of their own. Ideally users should be able to choose their own aliases. This post isn’t specific to UPI or India, but about payment aliases in general. In the rest of this post, I will be discussing how aliases could be improved in the future.
Nice to haves
Federated aliases and routing
Just as I was writing this part, UPI had a brief downtime downtime ,that’s the third time in one month!
This just goes to show the obvious risks of centralisation, in payment systems or otherwise. Federation among payment protocols can enable multiple owners with their offering on top of an interoperable protocol. Email is a great example of this. There are multiple email providers, and they all use the same underlying protocol to send and receive emails. Additionally, building payment protocols in the open can help expand the adoption and innovation without forgoing control over the protocol.
It shouldn’t come as a surprise if private players like banks start offering their own payment protocols in the near future. As this happens, I think it is in the best interest of all the stakeholders to have a federated approach to payments in general. To begin with, breaking down the payment process into smaller components such as aliases and routing can help in building a more robust and flexible payment system.
Leveraging DNS for payment discovery
The Domain Name System (DNS) is the phone book of the Internet. It is one of the fundamental ways for businesses, governments, and individuals to establish authority, authenticity, and ownership on the Internet. While the primary use of DNS is to translate domain names to IP addresses so that machines and browsers on the internet can discover and reach each other, it has since been periodically extended to include several other use cases.
Lets see how we can leverage DNS infrastructure to store and broadcast payment aliases while ensuring machine readability. Or in other words, how can I pay a business or entity using just their domain name.
TXT records in particular are a great fit for our use case. It’s already being widely used both for good and nefarious purposes. For instance, to prove domain ownership, among other use cases.
The following is my quick back-of-the-napkin attempt at designing a payment alias protocol using DNS. I am no protocol design expert, so you have been warned!
Here’s what a payment alias record for a traditional bank account based transfer could look like in plain text:
"pay:v1; pa=AB12BARC10201530093459; pn=John Doe; url=example-bank.com; md=lorem ipsum;"
The above record contains the following fields:
pay: The protocol name (e.g., pay, followed by versioning)pa: Payment alias (e.g., account number, UPI ID, etc.)pn: Payment name (e.g., John Doe)url: URL of the payment provider (e.g., bank, payment app, etc.). This could also be an intent URL or a deep link to the payment app. Additionally, it could be used to forward the request to the next alias in the chain.md: Metadata (could be any KV pairs, e.g., amount, currency, signature, etc.)
Prototype
The following prototype was created using flutter.
Here is a simple example of how the above record could be used in a payment app:
First the app would look up the DNS record for the domain name (e.g., example.com) using a DNS resolver. The resolver would return the TXT record containing the payment information.
Here’s how we could use it list traditional banking based alias like account number:
If you’re wondering - isn’t account number a sensitive information? Also how is it different from just listing it on the website as a text?
Well the above approach might not be particularly useful for individuals, but it is definitely useful for businesses. For instance, I have personally experienced this when I was trying to pay for my tuition fee to my university. All the bank details were listed on the website, but I had to manually enter the details in my payment app. In another instance, I’ve noticed how donors were against using a particular payment gateway for donations (because of political and ethical reasons) at a non-profit organization I was working with. The org had to then list banking details on their website, as an alternative to the payment gateway.
Either way, customers have to manually lookup what payment method a website accepts, and then manually enter the payment details in their payment app. What if a website just accepts cash or cheque? There’s currently no way to programmatically discover this information. This is the heart of the problem that I am trying to address.
By using DNS records, businesses can easily update their payment information without having to notify each of their customers.
Here’s an example of how the above record could be used for storing UPI based alias:
Domain names provide a sense of trust, have widespread adoption, awareness and are human-readable by design. However, the above approach is not without its drawbacks. For instance, DNS is vulnerable to spoofing and phishing attacks. Features like DNSSEC provide protections against such attacks. Protocols like DOH (DNS over HTTPS) and DOQ (DNS over QUIC) ensure DNS requests are secure, private, and leak-proof by encrypting DNS requests.
Alternatives
Here’s some alternatives that are worth considering, other than the DNS based approach described above. Specifically, the following protocols use standard HTTP methods over the internet:
- webfinger
- payments.txt (i.e under ./.well-known/payments.txt)
- atproto
What lies ahead
I strongly believe that will be more payment protocols and standards introduced in the near future. With each new protocol, we will see new use cases and new ways to leverage existing infrastructure. However, the onus of managing and setting up interoperable aliases should not be on the user alone. For now, I am convinced that payments is not a technology problem (at least it no longer is), it is a regulatory and adoption problem. Having said that, I do believe that there’s definitely room for standardization and interoperability in the current payment space.
Until next time, cheers and have a good one!