The new on-chain payments stack

Introduction 

Global access and technological innovations have created a confluence of events that have brought the payments industry to an inflection point. Digital wallets have exploded in usage, political unrest has led individuals to hold digital dollars to fight local inflation in geographies where banks are not trusted, societal expectations have pushed businesses and consumers to expect and demand immediacy, while ecommerce and digital channels have exploded as the fastest growing payment channels. We’re at a unique moment ripe to disrupt global payments and overhaul an antiquated stack that has been contorted to fit into a new age of commerce. 

In fact, we’re seeing the signs of such disruption. Stablecoins settled $10.8T worth of transactions in 2023 of which $2.3T were related to “organic” activities (i.e. excluding redundant transactions involved in smart contract activity and filtering for bot-driven and automated transactions) including payments and cross-border remittances, among others. Organic volumes grew by 18% YoY in 2022 and 17% in 2023 - that’s faster than any existing payment systems and surpasses PayPal’s payment volume in absolute terms. 

While everyone knows on-chain payments are a superior technology with faster settlement times, lower fees, and global reach—the learned secret from working in this space over the last 6 years is that the technology is not enough.

Matt Brown explains why best: “...the misconception is that payments are a problem in B2B payments. They’re not a problem, or at least not the problem. What’s hardest, most broken, and ultimately most valuable in B2B payments? The workflows and data that are the precursor to the payment being made.”

Image of the old payments stack

He succinctly points out that focusing on just the payments portion is a “ghost market” - one that looks big and attractive but is actually not possible to capture. You may be able to identify “who” you want to sell to, but when you go to build the “what,” it's impossible to find an answer that captures the entire market. Or conversely, you have built the “what” but the who you build it for is so fragmented that the market no longer looks attractive. 

Yes, businesses would prefer payments that are faster, cheaper, and inherently global, but to get to this final step, you must solve all the problems before the payment can take place. For anyone who onboarded into web3, you’ve experienced this pain. You had to download a wallet, save the seed phrase, figure out how to exchange fiat for crypto, maybe had to swap to get the right token, and then you could finally send funds - the easiest step in the entire process.  

For businesses, every industry in every country has its own workflows, data models, and software products that precede the actual payment. These workflows include:

  • Tracking the contract details, item sold, or usage amount to derive the amount to be paid

  • Validating the payment amount sent equals the amount due

  • Collecting required regulatory info

  • Calculating and withholding the correct taxes

  • Ingesting and reconciling the contract, invoice, and payment with internal tools like CRMs, revenue insights tools, and financial reporting that help businesses run 

If you improve the preceding workflows, you win the right to process the payment. 

The new payments stack with crypto payments

To understand the pieces that must come together to make this happen, I go through a series of examples to reveal the new on-chain payments stack. 

A simple example

Before I get into the technicals of how, let’s start with a simple payment example. Let’s say you’re a company selling books online. We’ll call this company Rainforest Retail. You want to accept on-chain payments because, well, your customers are global and located in countries where they prefer to hold digital dollars. The 2.9% credit card fees really add up at your scale for your business, and every second of settlement time matters in improving your cash flows, reducing risk and fraud, providing a better customer experience with faster order fulfillment, and reducing costs. 

You could throw your wallet address on your website and say, “want to buy a book, send money here.” Easy enough - you can now get paid on-chain from anywhere in the world. But your wallet will start looking something like this:

Example data from a block explorer

Pure gibberish. At least when you get paid by credit card or ACH or wire, the money comes in with the customer’s name so you can go figure out who just paid you, but on-chain, you know practically nothing, just an opaque string of 42 characters, a token amount, and a time-stamp. 

If you’re small, maybe you sell 1 book a day. It might be manageable to manually review and tie the payment to the new customer who just signed up. But if you’re selling 2, 3 or 1,000s of books a day, the problem becomes unmanageable. How will you know who sent you the funds when there are 1,000s of transactions for the same amount on the same day? How will you know what book that payment is for? What if they sent you only $9.85 and not $10 for the book? What about taxes? Or inventory management?

It’s easy to quickly discover that the hard part about payments isn’t the payments part, it’s all the workflows around it. Shopify, Toast and Stripe solve workflows and by solving the hard part of the business operations around the payment, they earn the right to enable it. 

Businesses want the benefits of on-chain payments but not at the expense of new workflow problems. The winning companies that will succeed during this inflection point and radically change payments will be the ones that solve these new workflow challenges and win the right to process the on-chain payment. 

These new workflow challenges include solving the regulatory complexity of moving seamlessly between on and off-chain, holding and moving digital assets, linking the on-chain payment to its off-chain context (e.g. amount, item sold, etc), and making on-chain payment data available for use by the systems and tools that companies are already dependent on to survive.

The on-chain stack 

For Rainforest Retail to accept payments in crypto, it’s going to need a few things. First, it’ll need a wallet to receive funds into. The wallet holds and stores assets and initiates transactions or approves another party to spend. Second, it’ll also need a way to move on and off-chain (paradoxically, knowing you can off-ramp actually increases the amount of funds held on-chain). Lastly, Rainforest Retail will also need a way to tie the on-chain payment to its payment context - things like the item sold, amount billed, invoice number - and it’ll need a way to store, and communicate all this data into its business operations systems - the software that businesses depend on to solve workflows internally. Systems like CRMs, point of sale systems, accounting systems, revenue forecasts, etc.

The components of the on-chain payments stack

Within each section of this new stack, various businesses solve and abstract away the complexity around completing the task at hand. For example, companies like Privy, Dynamic or Portal provide “Wallets-as-a-Service,” ready-made wallet integrations that allow companies to bypass key management, security, and infrastructure complexities. 

The biggest decision in putting together this stack to build a payments solution is who owns the wallets - a third party is entrusted with the private keys (i.e. custodial) or the user controls the private keys (non-custodial). 

Whoever controls the private keys controls the transaction approval and thus the ability to move funds. This in turn dictates how the communication and on/off ramp can function. Because of the material importance of this choice, we will use this choice to build a framework to understand the stack. In cases where both the sending and receiving wallets are custodial, I’ll refer to this setup as a “closed” system. If either of the wallets are owned by the parties in the transaction (i.e. non-custodial), then we’ll call it an “open system”. We’ll also use this framework to see this new stack in action.

A framework for on-chain payment systems

Closed system 

To illustrate what I mean by a “closed system”, let’s take another example. You’re a B2B company selling farm equipment internationally. We’ll call you Jane Dear. Your customer is in Mexico. It’s a Friday afternoon and you can’t wait until Monday for the banking system to open up and settle the payment. So you use a solution, International Payments Now (IPN), which will help you get paid fast. Underneath the hood, IPN utilizes on-chain payment rails to move funds, but its users likely do not even know this. 

For this to work, the payer needs to also be a user of International Payments Now. The payer would have gone through a KYB process through an on/off-ramp provider like Circle, Beam, or Bridge. These companies solve the workflow problem of handling the regulatory complexities around moving from off-chain to on-chain, one that requires countless licenses and liquidity across a wide range of both fiat and on-chain currencies and chains. It’s hard work that requires a breadth of offerings to meet a market’s needs. They will KYB your payer and connect the payer’s bank account to a custodial wallet. Whenever funds hit this wallet on-chain, they are off-ramped to the bank account and whenever funds are on-ramped they are sent to this wallet. The bank account and this wallet will be tied together. Likewise, the receiving company, Jane Dear, would have gone through this same process. It would have completed KYB and connected a custodial wallet to a bank account. 

With both payers on-boarded to International Payments Now, IPN can move money from the payer’s bank account to the payer’s wallet to Jane Dear’s wallet and then to Jane Dear’s bank account. By controlling the movement of funds - because IPN controls the custodial wallets - IPN can keep track of the on-chain payment and make this data available for both parties to fit into their existing systems (i.e. the communication layer). 

By connecting a bank account to a custodial wallet, orchestrating the payment from one wallet to another, handling the payment data, and finally moving funds from the receiver’s custodial wallet to the receiver's bank account, International Payments Now can move money around the world in seconds. 

For this system to work, two things must be true: 1) both the payer and the payee must be on-boarded to the same platform and 2) the underlying wallets are custodial. However, if just one party isn’t onboarded to this closed system, you need a new architecture.

Open system 

Let’s say you live in a country where there is high inflation or political unrest. You don’t trust your local currency so you want to hold dollars. Luckily, there exists the aptly named Digital Bank (DB). DB lets you hold, store, and use a digital dollar. As a customer of DB, you don’t care where this dollar is stored or how it works, you just care that it equals $1 and you can spend it anywhere digital dollars are accepted. You do not want to be tied to on-boarding to many closed platforms, you want true interoperability. 

So how would this work? 

To unlock interoperability, BD needs to use a non-custodial wallet. This allows the user to bring with them their funds to any merchant, not just those on-boarded to the same platform. This is also preferred for DB from a risk perspective.  Unlike with International Payments Now, these funds are sitting in wallets for a while. They are not quickly moved in and out of crypto; DB could end up custodying millions of dollars of assets, across different regulatory regimes. With non-custodial wallets, users KYC when they on-board as they need to convert from fiat to on-chain, but the wallet that is tied to the bank account and receives the funds is controlled by the user herself. 

As you might imagine, customers of DB are big readers, so they head over to Rainforest Retail to purchase some books. Having a customer’s preferred payment method available is critical to making a sale. In fact, 60% of e-commerce shoppers will abandon their carts if they don’t see their preferred payment method. Thus, Rainforest Retail finds a solution to accept on-chain payments. 

As we saw above, accepting on-chain payments at scale isn’t as simple as showing a wallet address. Merchants need at the very least a checkout page and cart that can support all of these new on-chain payment methods, from supporting EVM chains to Solana to any ERC-20 token to a way to keep track of the items they are selling in real-time to manage their inventory. They also need to have mechanisms in place to ensure full payment, so they don't spend time following up with customers. The ability to use coupon codes and free trials for sales promotions or even sending a simple receipt at the time of purchase are critical functionality as well. And this is just for selling books. Now imagine you’re selling APIs and charging when a threshold is hit or selling business software and charging per seat when a new seat is added, or you’re a creator platform managing subscriptions for many of your writers with their own various payment configurations. 

To solve this, Rainforest Retail needs a communication solution. It needs a tool that enables and orchestrates the payment. It needs a way to take its off-chain workflows, generate a payment request, charge the customer on-chain, and then bring the on-chain payment data back into its existing systems. Because the payments part is easy, capturing the payment details and properly charging the customer on-chain and then getting the confirmation into Rainforest Retail’s systems is the hard part. One such solution is Loop Crypto. Loop allows Rainforest Retail to collect payment in the customer’s preferred on-chain payment method, keeps track of the payment on-chain, and connects directly into Rainforest Retail’s existing systems. 

The benefits for Rainforest Retail don’t stop here. In addition to solving the pre-payment workflow issues, using this payment orchestration system that contextualizes, stores, and makes available on-chain data solves workflows post-payment. Rainforest Retail is now able to do things like: 

  • Prove it’s revenue on-chain to banks, lenders, and governments 

  • Easily produce financial statements that account for on-chain revenues

  • Analyze their customer and provider personalization by looking at the customer’s on-chain history 

  • Understand preferred payment chains and tokens 

  • Identify high-performing products and services

  • Calculate the success of a coupon or marketing campaign 

However, all of the benefits of the communication layer data sit with Rainforest Retail. Digital Bank (DB) and its customers are in the dark because the payment context sits centrally with Rainforest Retail. DB is left only with access to a block explorer to try and decipher the context around transactions. In the web2 world, there would be a card network or a Plaid API that would communicate a merchant category and other payment details via shared communication standards that have been built and used for decades. This is why in web2 banks and FinTech applications can provide the customer with a rich spend history with context on where money was spent and for what.

This lack of information means DB cannot do things like summarize its customers’ payment history, analyze spending trends, or underwrite credit products (e.g. BNPL) based on transaction history. To acquire this contextual data around the payment, DB has 3 options:

  1. Ask Rainforest Retail to share it directly with them

  2. Produce an on-chain record (like an NFT) that stores all the contextual data

  3. Utilize a third-party, neutral system that standardizes, stores, and makes payment data accessible

Option 1 works when there is only a single merchant but does not scale when you need to collect payment data from thousands of merchants. This is why banks today do not rely on individual merchants for transaction history; they utilize vast card networks or the ACH network with standardized messaging. Option 2 with NFTs is a solution that works well for other types of transactions such as loyalty or community participation; it works best when both parties want that representation to be public. However, payments are a delicate matter. Merchants want privacy so you can’t see their revenues and consumers may be purchasing products or joining communities they only want some people to see. These challenges make this option challenging.

Option 3, where there is a communication layer similar to the role that Plaid plays in web2, would allow for a scalable solution where payment data would not be siloed within individual crypto payment solutions but rather broadly accessible to both payers and payees. Such a system would be akin to the shared communication standards that web2 has developed but built in a way that retains the ownership and interoperability that web3 provides. Luckily, solutions like this are on the horizon. 

By using a non-custodial wallet, DB operates in the open system framework - one that is completely interoperable and likely more expansive as DB does not have to onboard every single merchant to their platform to unlock places its users can spend funds. And this makes sense, the killer feature of web3 is sovereign ownership and interoperability.  Solutions that solve workflows earn the right to process the payment. This is what unlocks on-chain payments. 

The Payments Flywheel

In our examples, on-chain payments offered faster settlement times, global reach and lower fees for Jane Dear, while for consumers it offered access to digital dollars, and by accepting those dollars, it offered Rain Forecast retail the opportunity to capture a sale. 

As on-chain payments take hold by solving these pain points, wealth is accumulated on-chain. And with wealth creation comes the desire to spend that wealth (even before stablecoins, consumers with on-chain wealth demanded buying 10,000 bitcoin pizzas). This demand to spend, drives merchants to accept, which creates more wealth on-chain, leading more merchants to join, and so on. Payment is about velocity, not absolute on-chain value. 

And this payment velocity is coming from many directions all at once. It’s coming from:

  • Demand for digital assets driven by ideology for a decentralized economy, and a hedge against fiat, a drive for higher returns (i.e. the original hodlers and now degen traders) 

  • A desire to get paid in and hold a digital dollar driven by global political instability and rising inflation

  • Demand for faster settlement times, especially for global payments, brought on by the social change in expectations for immediate combined with increased competitiveness forcing businesses to look for solutions to find an edge

  • Demand for lower fees driven by a desire to lower costs in a tough macro environment where finance is tight and there is increased competition  to attract customers

  • Demand for self custody driven by a decrease in overall trust, from trusting one’s government, to trusting the banking system, to trusting a platform or game to hold your assets  

If you’re working in web3, you’ve seen this flywheel take hold over the last decade. But if you’re living in LatAm or working at a large corporation doing cross-border transactions, you’ve also seen this flywheel take hold in your corner of the payments world. 

The companies working to solve the workflows around on-chain payments speed up this flywheel and will earn the right to process the on-chain payment.

Conclusion 

Once you begin to dig into how businesses can accept on-chain payments, you quickly realize the payments are the easy part. The hard part is all the workflows around payments. And if you can simplify this for merchants and their customers, you win the right to process the payment. 

Understanding the architecture required for on-chain payment adoption, you can start to build a picture of the future and answer market dynamics questions like where will value accrue, how will this market evolve over time and which parts of the stack are sticky and defensible. 

New technologies bring the promise of radical change, but for users to realize these benefits, the change must come at an inflection point – a drastic shift that removes a fundamental blocker. For telemedicine, this was Covid pushing governments to change regulations allowing patients to realize the benefits of video technology that had been around for years. For online editing and photo sharing, it was camera phones becoming so good that they replaced digital cameras, and for the gig economy, it was social applications like Facebook making us all more comfortable getting into a stranger’s car or hiring a worker in another country. These inflection points often go unnoticed by the majority until the shift is too big to miss. 

We’re at an inflection point now for payments. Blockchain as a technology allowed for the global movement of financial value, and Covid accelerated society’s rapid adoption of digital wallets while the world became more global with remote work, and we all started demanding personalized and instant experiences. This is happening while governments are beginning to produce regulation that will lay the groundwork for wide on-chain adoption. 

A payments revolution is here. 

A big thanks to Dmitriy (Archetype), Larry (Reverie), Wyatt and Juan for providing feedback and comments.

Get started in minutes

Stay in the Loop

Sign up for our newsletter to stay in the Loop on all the latest updates, features, and announcements from Loop Crypto.

© Loop Crypto 2024. All rights reserved.

Stay in the Loop

Sign up for our newsletter to stay in the Loop on all the latest updates, features, and announcements from Loop Crypto.

© Loop Crypto 2024. All rights reserved.

Stay in the Loop

Sign up for our newsletter to stay in the Loop on all the latest updates, features, and announcements from Loop Crypto.

© Loop Crypto 2024. All rights reserved.