The internet got very good at moving information. It's still surprisingly bad at moving money. I think that gap is about to close, and this is the hypothesis I can't stop thinking about.
A few nights ago I got stuck on a question that felt almost too simple: what if software could just pay?
Not open a checkout page. Not redirect me to Paystack. Not wait for me to type my card number and an OTP. I mean actually pay, by itself, the same way it already sends an API request or fetches data from another server.
That question sent me down a rabbit hole, and it led me somewhere I didn't expect. Over the last thirty years, the internet became incredibly good at moving information around the world in milliseconds. It never got that good at moving money. Almost every payment still stops and waits for a human to step in.
This is an essay about what happens when that stops being true.
Payments Were Built for Humans
If you think about it, almost every payment you have ever made follows the same shape. You decide to buy something, you tap a button, you enter your card or open your banking app, you approve an OTP, and you wait for a success screen. We have done it this way for so long that it feels like the natural order of things.
The problem is that every step in that flow quietly assumes a person is present. It assumes someone is there to read a screen, tap a button, and decide whether to continue. That made complete sense, because for decades humans were the only ones buying anything on the internet.
Software does not think like that. An AI agent does not understand why it has to stop working just because a checkout page appeared. It does not care about dashboards, pricing tiers, or billing portals. It only knows it needs a service to finish the job you gave it.
Imagine asking an AI to build a report on traffic in Lagos. Halfway through, it realises it needs satellite imagery from one company, weather data from another, and map data from somewhere else. It knows exactly what it needs. But instead of continuing, it hits three pricing pages asking it to sign up, pick a plan, enter a card, and create an account. The agent is not stuck because it cannot understand the task. It is stuck because the internet still expects a human to take over.
That is when I started wondering what it would look like if payments worked the way API requests do.
Start With Something You Already Understand
Forget APIs for a second. Think about Uber.
Today, the flow looks like this:
- You request a ride.
- A driver accepts.
- The ride ends.
- You pay.
Now imagine tomorrow. You tell your assistant, "Get me to the airport." It orders the ride for you. Uber replies that the trip costs ₦8,200. Your agent approves the amount and pays. The driver shows up, you travel, and it is done. You never opened the app, and you never tapped confirm.
Or take something even more ordinary. Your fridge notices you are low on milk, so it places an order, pays for it, and a delivery shows up later that day. You did not open an app, choose a plan, or approve anything in the moment, because you already told it what it was allowed to do.
Most people do not need to understand HTTP to want that. They just recognise the story. And underneath that story sits a real technical problem: how does the software actually pay for the small pieces it uses along the way? That is where a protocol like x402 comes in.
One Answer Is x402
Somewhere in that rabbit hole, I came across x402, and the idea behind it is simpler than the name suggests.
Picture a convenience store. You pick up a bottle of water, walk to the counter, hear that it costs ₦500, pay, and leave. You did not open an account with the store or subscribe to a monthly plan just to buy one bottle. You paid for exactly what you wanted, at the moment you wanted it.
x402 tries to make the internet work the same way. Instead of signing up for an API, choosing a plan, entering a card, waiting for a webhook, and copying a key before your first request, your software simply asks for what it needs. The service replies with something like, "This request costs ₦20." Your software pays. The service confirms the payment and returns the data. Payment becomes part of the conversation instead of a separate journey you have to leave and come back from.
The trick is that x402 does this by reviving an old, unused part of the web. When a client asks for a paid resource, the server answers with an HTTP 402 "Payment Required" response and the price. The client pays, usually in a stablecoin, and retries the same request with proof of payment attached. The server verifies it and returns the resource. The whole exchange happens in a single round trip, with no account and no manual checkout.
So is x402 just a way for APIs to charge each other? In its current form, mostly yes, and that is the point. It is built for machine-to-machine payments, the tiny purchases software makes while doing its job. This is not a small experiment either. It started at Coinbase in 2025 and now sits under neutral foundation governance, with names like Visa, Mastercard, Stripe, Google, and AWS attached to it. By early 2026, a little over a year after launch, it had already processed more than 165 million transactions, at an average of around thirty cents each. Those are not human purchases. They are machines paying machines, in amounts too small for a card network to bother with.
Which brings the Uber story back into focus. When you say "get me to the airport," you experience one clean action. Underneath, the agent might be quietly buying live traffic data, route options, and pricing from several services. x402 is what lets those machine-to-machine purchases happen without an account for each one. The part where your actual fare reaches the driver still rides on more familiar rails. The interesting shift is everything happening underneath, out of sight.
Different Technologies, Same Destination
The more I read, the more I realised x402 is not happening on its own. It is one piece of a much bigger movement, and the other pieces are already here.
Account-to-Account (A2A) payments move money straight from one bank account to another, skipping the card networks entirely. Nigeria has NIP. India has UPI. Brazil has Pix. Different names, same idea: fewer steps, lower cost, faster settlement.
Agentic and conversational checkout is arriving too, and Nigeria is right in the middle of it. Paystack recently launched Paystack Index, which lets you ask an assistant like Claude or ChatGPT to buy airtime, send money through Zap, or order food on Chowdeck, and the assistant actually completes the transaction instead of just explaining how. What I find most interesting is not the conversation. It is the fine print: you set the permissions and spending limits, and the agent can only act inside them.
AI agents themselves are becoming capable enough to make real decisions on your behalf, which is what makes all of the above suddenly matter.
On the surface these look like three different projects. One is about APIs, one is about bank transfers, one is about user experience. But I do not think they are solving different problems. I think they are solving different parts of the same problem: how do we make moving money feel as natural as sending a message or making a request?
For years, the internet became brilliant at moving information. Money never caught up. Every payment still needs approval, a card, an OTP, or a switch to another app. Information evolved much faster than money did, and that gap is finally starting to close.
The next version of the internet isn't about moving more information. It's about moving value.
And I don't think the goal is simply faster payments. The best payment is not the fast one. It is the one you barely notice happened at all.
The Next Step Is Autonomous Payments
Here is where my own hypothesis starts to form. If payments keep getting simpler and more programmable, we stop asking how people pay and start asking how the internet pays.
Autonomous payments are not about replacing humans. They are about letting software handle the small decisions that do not really need us anymore. Your phone already does plenty without checking in each time:
- It downloads updates overnight.
- It backs up your photos.
- It syncs your files across devices.
- It refreshes your mail and messages.
You allowed all of that once, and now it simply happens. So why should payments be the one thing that always needs you standing there?
Imagine you are building an AI travel assistant, and you ask it to plan a trip to Kigali. Along the way it needs weather data, flight prices, hotel availability, maps, and exchange rates. Today it can find those services, but it cannot really pay for them, so everything stalls the moment a checkout page appears.
Now imagine a different version, where the agent already has permission to spend small amounts on your behalf. It pays as it goes:
- ₦50 for weather data
- ₦100 for richer flight options
- ₦20 for maps
- ₦80 for hotel availability
Then it hands you a finished travel plan, with no interruptions and no ten separate approvals. Just like your phone silently backs up your photos today, your assistant silently pays for the services it needs tomorrow. Not spending money however it likes, but spending it within rules you already agreed to. That difference is the whole thing.
The Missing Layer Isn't a Wallet. It's Trust.
At first I thought the answer was machine wallets. Give every agent a wallet, let it hold money, let it pay for whatever it needs. Simple. Except it isn't.
If you have ever left an EC2 instance running on AWS for a few days, you already know why. The problem was never that AWS let you create resources. The problem was waking up to a bill you did not expect. That is exactly why AWS gives you budgets, alerts, limits, and permissions. It does not stop you from building. It puts guard rails around what can happen.
Autonomous payments need the same thing. Not unlimited wallets, but programmable trust. You would create a wallet for your agent not by handing it your money, but by handing it rules, for example:
- No more than ₦5,000 in a single day.
- No single payment above ₦500 without asking me first.
- Only pay for maps, weather, and travel data. Block every other category.
In this design, your agent never talks straight to a payment provider. Every payment passes through a policy engine first, which asks a few plain questions:
- Is this service trusted?
- Is this within today's budget?
- Has the spending limit already been reached?
- Does this need human approval?
If every answer checks out, the payment goes through. If not, it simply says no. The agent is not deciding how much freedom it has. You decided that before it ever spent a single naira.
This is the part most conversations skip. Everyone talks about how software can pay. Very few people talk about how software should be allowed to pay. And you can already see the serious players betting on the second question. Paystack Index shipped with spending limits on day one, not as a feature to add later. The moment software can spend your money, those limits stop being a setting and become the actual product.
The goal isn't making payments autonomous. It's making autonomous payments trustworthy.
So Where Does Blockchain Fit Into This?
You might have noticed I went this far without leaning on blockchain, and that was on purpose. I don't think blockchain is the main story here. The main story is programmable payments. Blockchain just happens to be one of the first technologies that made them possible.
Software has exchanged information over the internet for decades. One server asks another for data, and it responds. Money never worked that cleanly, because it dragged along banks, card networks, processors, and settlement windows, all built around a human making the payment. Then blockchains showed up, and for the first time software could hold a wallet, sign a transaction, and send or receive money entirely on its own.
Whether or not you like crypto, that was a real shift. It was less about inventing new money and more about making money programmable. I think a lot of us misread this during the early Web3 years, when the loud conversation was about decentralizing everything. Underneath the noise, something quieter was happening: storage, identity, and compute were all becoming programmable, and now payments are heading the same way.
The important part is that this future does not have to belong to blockchain alone. Imagine your bank exposing the same programmable capability. Your agent would not care whether the money moved over a blockchain, an instant bank transfer, or a rail nobody has built yet. It would just ask, "Can I pay for this?" and let the infrastructure sort out the rest. The future belongs to whichever technology makes moving money feel as effortless as moving information.
The Internet Is Learning to Exchange Value
When the internet went mainstream, its superpower was sharing information. You could email someone across the world in seconds, search almost anything, and build an app that talked to another app thousands of miles away. Information became effortless to move. Money did not. Even now, paying for something online still feels like briefly leaving the internet, filling a form, switching apps, approving, and waiting before you return to what you were doing.
I think that is starting to change, and not because of one protocol, one company, or one blockchain. When you zoom out, the pattern is hard to miss. A2A payments make moving money between accounts faster and cheaper. x402 makes payment a native part of a request. Agentic checkout like Paystack Index makes paying feel like a conversation. Capable AI agents tie it all together. They solve different problems, but they push toward the same future, where software can find a service, understand its price, pay for it, get the result, and keep working without waiting for anyone to click a button.
Honestly, I don't think most people will notice when it happens. Nobody thinks about TCP/IP before sending a message on WhatsApp, and one day we probably won't think about payment rails before software pays for something. It will just happen.
This is not abstract for me. I have been building an operating agent with a few friends for a hackathon, with a simple goal: give people across Africa access to digital services through something as familiar as making a phone call. As we built it, one question kept surfacing. What happens when the agent needs to pay? Not next week, not after creating an account, but right now, mid-task. That question is what started this whole rabbit hole.
Maybe the future of payments is not about making people better at paying. Maybe it is about making payments disappear, not because money disappears, but because software becomes trusted enough to handle it for us. I don't know exactly what that looks like yet. Maybe x402 becomes the standard. Maybe banks expose programmable payment APIs. Maybe someone builds something that replaces both.
What I do know is that the question has changed. For years we asked how people pay on the internet. I think the next decade is about a different one entirely.
How does the internet pay itself?
About the Author
Over the last few years I've built fintech systems at Skurel, working on fraud detection and OTP infrastructure. I won the GTCO Squad Hackathon, one of the largest in Nigeria, with a product called Recivo. I facilitated Build with Paystack, where I taught more than fifty students how to integrate Paystack and design production-ready payment flows rather than just checkout buttons. And through Koded Labs, I keep shipping products that touch payments in one way or another.
Lately my curiosity has drifted toward the layer beneath all of that. Not just building things that accept payments, but understanding how money actually moves across the internet, and what changes when software becomes trusted to move it on our behalf.
If you're building in fintech, infrastructure, or AI, or you just think a lot about where payments are headed, I'd genuinely love to talk.
Top comments (0)