Why Crypto Payments Are Backwards

The Problem

If you’ve ever tried adding crypto payments to a traditional web app you may have noticed something odd. The standard approaches like WalletConnect and RainbowKit all execute transactions from your client-side code with a connection to the user’s wallet. Then they try to tie this transaction to the user for your backend to process. This is often done in a convoluted way like generating a new wallet for every transaction. Hosted solutions like BitPay and Coinbase Commerce abstract away some complexity but still face the fundamental challenge of client-side transaction execution.

The problem in all these approaches is the lack of server-driven design. It’s like sending someone cash in the mail with no note attached and then trying to prove it was you who sent it.

How I Stumbled Into a Solution

I wasn’t attempting to fix this. I wanted to learn more about the new x402 protocol with a hands-on project. I work at a crypto infrastructure startup where I added Stripe integration to accept payments, but we still weren’t accepting crypto-native payments. Two birds one stone.

Here’s the repo if you want to jump straight to the code: xtended402

Initial Approach

x402 v1 was designed specifically for agentic, high-volume, micro-payments. Using it to accept human-initiated, one-time payments of $100 on our dashboard meant breaking all three of those assumptions. The first thing I did was get rid of the “price discovery” phase, since the client here isn’t an AI agent that doesn’t know how to pay. It’s our own UI that knows exactly what the backend expects. Next I set up wallet connection and signature creation logic in the UI.

Backend integration was relatively simple using the Coinbase Go middleware, but your code will only be as reliable as the facilitator you’re using. We were building our own in-house facilitator so I integrated with that. Server ←→ facilitator interaction has two phases: verify the signature from the client is valid, then settle the transaction using the signature. The Coinbase middleware defaults to executing your happy-path logic after the verify phase succeeds but before waiting for the settle phase to succeed. While our in-house facilitator was still in development, the verify phase would succeed but the settle phase still failed. With the default middleware we would have been giving users free credits, so the final and most critical change was altering the Coinbase middleware to check the verify and settle calls before executing any code to process the order.

Done! Everything worked.

The Insight

I was excited that the experiment worked and we were accepting crypto payments in such an unusual way, but became much more intrigued when I started comparing it to the existing solutions.

The signature-based approach is completely server-driven. The client simply gets a signature from the user’s wallet, allowing the backend to drive payment logic. One drawback is the external dependency on a facilitator, but this is lower overhead than the existing hosted solutions and much more robust than the existing DIY solutions. You get:

• Server-authoritative pricing (no client manipulation)

• Tight in-line link between customer and their transaction

• Atomic order processing (payment confirmed before database writes)

• Standard REST patterns

The key shift here isn’t really about x402. It’s about using EIP-3009 signatures to process payments server-side. x402 establishes a consistent pattern and it’s facilitators provide a uniform way to abstract out some of the on-chain complexity - a nice balance between open-source and easy-to-implement. But a web-app or online store could implement this same pattern in another way, getting signatures from the client and writing their own execution logic for the backend, while the customer data is still in the request context.

The Solution

Based on this insight I created a library to make this pattern accessible.

Core Features:

• Go middleware with configurable settlement timing (process before or after payment)

• Context-based dynamic pricing from request bodies (shopping carts)

• React component that handles the entire payment flow

• Maintains Full x402 v2 compatibility

The React Checkout component in action:

How This Evolved

After a lot of back-and-forth I decided to keep the library x402 compatible. As previously mentioned, x402 standards aren’t specifically necessary for server-side transaction execution, but I figured why narrow when I could expand. Now one endpoint can accept payment from a human-driven UI or an AI agent.

I spent a couple weeks building a solution for v1 of x402. Then, less than twelve hours after finishing, Coinbase released v2. The good news was that it included some of the changes I made and validated the direction I was heading in. It’s more chain/token agnostic (uses CAIP-2 identifiers) and there’s even a React button example in their documentation, acknowledging human payments. The architecture is fundamentally more modular and extension-friendly as well.

v2 also introduced support for dynamic pricing but it’s designed to be implemented using request headers. This can get unwieldy when working with more complex data structures like a shopping cart order that determine price. The xtended402 repo includes some helpers to make it easier to determine the price based on the request body, store it in the request context and then tell the middleware to use that price.

The issue I experienced with settlement timing still wasn’t fully addressed, so I created another version of the Go middleware with a parameter to make that configurable (WithSettlementTiming). The other tools in this repo can be used with the standard Coinbase x402 middleware, but for physical goods or expensive products it’s important to ensure that the payment is processed and that the customer receives their order. The repo also includes code examples for best practices on how to ensure order integrity.

The React component uses the price discovery phase to learn what payment the backend accepts, ensure it’s a token that supports EIP-3009 signatures, connect to that chain in the user’s wallet, display the appropriate token balance and show the price as determined by the backend. No need to hard-code prices in to the front-end, just plug in the payment URL and let server tell the client how to pay.

What’s Next

xtended402 is open source so that more devs can try this pattern out, more quickly. Crypto payments don’t need to be harder than traditional payments—they're just backwards now.

Check out the repo here - I'd love feedback, contributions, or to hear if you've faced similar problems. I also have open issues for what I’m thinking about next.

Try it yourself - The repo includes a full-stack example you can get running locally in minutes.

This pattern is working well for our use case, but every payment flow is different. Feel free to fork it, break it, or tell me why I'm wrong.