DEV Community: Bartosz Siminski

x402: AI agents and the future of payments

Bartosz Siminski — Wed, 07 Oct 2026 16:37:09 +0000

Autumn is here, and the technology world keeps moving forward, whether we like it or not. You have probably seen cashierless stores where you can shop without stopping at a checkout. Now imagine that same convenience extending to the way we book and pay for everyday services.

One evening, you say at home, “I need to book a haircut.” Your smartphone connects to your favorite salon’s booking system, and your AI agent finds an available appointment. “Would tomorrow at 6 p.m. work?” it asks. You simply reply, “Yes.”

You arrive without cash or a payment card. When the appointment ends, the salon marks the service as completed, and your agent pays the agreed amount under the permissions you have already granted. If you have asked it to, it also books your next visit. You say goodbye and leave.

It is an appealing vision of a future experience. Making it widely available requires connected booking systems, reliable confirmation that the service has been delivered, and clear authorization to spend your money. x402 could provide part of the payment infrastructure behind it.

Until recently, experiences like this felt like science fiction. Today, the technology needed to build parts of them is already taking shape. Payment cards and terminals will not disappear overnight, but payment could increasingly happen in the background, within limits we choose.

AI agents could become an everyday interface to local services, shopping, reservations, and work. With an agent connected to a smartphone and the right services, we could book a medical appointment, compare offers, find an available beauty appointment, order a pizza, research a holiday, or manage a subscription.

The key question is what happens when that agent needs to pay.

The challenge with today’s payment systems

Much of the digital world was designed for people navigating websites, filling in forms, and pressing buttons.

Online purchases often involve customer accounts, authenticated sessions, payment gateways, card details, and sometimes additional verification such as 3D Secure. These systems already support many automated payments, but buying from an unfamiliar provider can still require a person to complete the setup.

That is manageable when someone buys a pair of shoes. It becomes cumbersome when an agent needs to purchase a single piece of data, call a specialist AI tool, or use a new API halfway through a task. Repeating account creation and billing setup for every provider adds friction, especially when each purchase is worth only a few cents.

This is one of the problems x402 aims to address.

What is x402?

x402 is an open payment protocol built around the long-reserved HTTP status code 402, “Payment Required.” It gives services a shared way to tell software that payment is needed and provide machine-readable payment instructions.

An agent, application, or other client requests a resource: an API response, a file, paid content, data, or a digital service. The server can respond with HTTP 402 and specify the price, accepted payment method, network, and recipient. x402 can also be integrated with MCP tools.

In compatible implementations, this allows a buyer to pay without creating a separate customer account or obtaining an API key from every seller. The buyer still needs a funded wallet or another supported payment arrangement, signing capability, and permission to spend. A service may also require identity or access checks.

Current widely documented deployments use stablecoins, such as USDC, on supported blockchain networks. x402 is designed to accommodate multiple payment schemes and networks, but that does not mean every implementation accepts bank transfers, cards, or ordinary currency payments.

It is also important to distinguish payment from the rest of the interaction. x402 does not, by itself, discover a salon, negotiate an appointment, operate its calendar, or decide whether you authorized a purchase. Those functions belong to the agent and the services around it.

How an agent pays with x402?

Consider a simple fixed-price API request.

The agent requests a resource. The service replies, “This costs one cent, payable in USDC,” together with the necessary payment details.

The agent’s payment software checks the offer against the user’s spending policy. If the request is permitted, it prepares a signed payment payload and retries the request with that payload attached. The server verifies it, often through a payment facilitator, and handles settlement before returning the resource in the typical fixed-price flow.

The distinction matters: preparing a signed payment authorization is not the same as independently transferring the money before retrying the request. The exact sequence and settlement timing depend on the payment scheme and integration.

x402 also supports approaches such as usage-based payments and batch settlement. With batch settlement, many small interactions can be authorized individually and settled together, reducing the overhead of putting every payment on-chain. This is particularly relevant for services priced by token, API call, or unit of compute.

The economics still depend on network costs, facilitator fees, and the chosen implementation. Sub-cent pricing does not automatically make every individual payment economical.

From a protocol to real products

In September 2025, Coinbase and Cloudflare announced plans for the x402 Foundation. Cloudflare also introduced x402 support in its Agents SDK and MCP tooling. The foundation began operating under the Linux Foundation in July 2026, providing neutral governance for the protocol.

The surrounding products have continued to develop. On September 30, 2026, Cloudflare launched a closed beta of its Monetization Gateway for eligible US-based sellers and buyers. It reported production use cases covering model inference, web search, financial data, and PDF generation.

Stripe now documents support for x402 stablecoin payments in USDC on Base, alongside its separate Machine Payments Protocol, or MPP. Availability depends on the product, geography, and account eligibility; this is not yet a universally available payment option for every business.

These developments show that x402 is moving into practical infrastructure. They do not mean that every local service is ready to accept autonomous bookings and payments.

Will pay per use change subscriptions?

Many digital services are sold through monthly subscriptions, even when we only use them occasionally. For some agent workflows, a different model may be more useful: pay for the specific resource needed to complete a task.

One document analysis. One query to a premium database. One use of a specialist tool. A small amount of model inference.

This could change how knowledge, data, and digital services are monetized. A data provider could charge per query, while a specialist AI tool could earn revenue whenever another agent uses it. Where costs permit, prices could fall below a cent, with small charges accumulated and settled together.

Subscriptions are unlikely to disappear. Frequent users may still prefer predictable bills, bundled access, or negotiated pricing. Pay per use could become an additional way to sell services, particularly to occasional buyers and agents trying a new provider.

A business can already make structured service information available and build a compatible paid API. Completing a booking or taking payment for an appointment still requires a booking system, payment integration, and clearly defined terms. Exposing a calendar or price list alone is not enough.

When agents buy from other agents

Imagine telling your agent, “Organize a weekend in Kraków. My budget is PLN 1,200. Find a hotel near the center, dinner on Saturday, and something interesting for my child.”

Your agent could work with a hotel’s system, a restaurant’s booking service, a transport provider, and other agents or APIs. Some information might be free. A specialist recommendation might be paid. A reservation might require a deposit, while another purchase could require full payment.

How often do we want to get away, only to postpone it because planning takes time? An agent could research reviews, compare locations, put together an itinerary, and make reservations within the permissions we set.

Making this work across providers requires more than a common payment mechanism. Services need compatible ways to describe offers, exchange requests, confirm reservations, and handle cancellations. MCP can expose tools to agents; agent-to-agent protocols can support coordination; x402 can handle payment for compatible resources. Frameworks such as Google’s AP2 address verifiable authorization for agent purchases.

Payment could therefore become part of an ongoing interaction between systems. A user would set the goal, the budget, and the boundaries, while the agent would handle permitted purchases along the way.

What this could mean for businesses

If more customers are represented by AI agents, a website will be one of several ways to reach them. Businesses may also need interfaces that software can use directly.

That means making prices, availability, service details, cancellation terms, and purchase options accessible in a structured form. A well-designed page will still matter, but so will the ability to answer an agent’s request accurately and complete a transaction reliably.

For local businesses, this could become an additional source of customers. A salon, restaurant, repair shop, hotel, personal trainer, tutor, or cleaning company could receive requests through an agent acting on a customer’s preferences.

Price, availability, reviews, distance, response time, and cancellation terms could all influence which provider an agent recommends. There will be no single universal ranking formula: the choice will depend on the user’s priorities and the agent’s access to trustworthy information.

Who controls the agent’s spending

Giving an agent a wallet is only the beginning. Someone must define what it can buy, from whom, within which budget, and with what level of approval.

An agent might be allowed to spend a few cents on data automatically, while a larger purchase requires confirmation. Recurring payments could follow a policy the user has approved in advance. Booking a follow-up appointment would require its own permission, rather than being assumed simply because the agent paid for the previous visit.

These controls belong to the wallet, agent platform, authorization framework, and business integration. x402 provides the payment exchange; it does not automatically supply a complete spending policy or establish that a seller’s service is trustworthy.

A hybrid model seems a plausible starting point. Agents would handle small, permitted purchases independently and ask us about larger decisions. Their autonomy could expand as reliability improves and users choose to delegate more.

x402 matters because it is one of the building blocks for an internet where software can buy resources while working on behalf of people and businesses.

Today, a business asks, “Does my website work well on a phone?”

Increasingly, it may also ask, “Can an AI agent understand my offer and use my services?”

And as users, we may ask, “Can I trust my agent to make this decision within the limits I have set?”

Over the coming years, voice-enabled AI concierges could take on more of our everyday errands. How widely and how quickly that happens will depend on useful integrations, reliable payments, and trust.

What would you ask your agent to take care of first?

If Anyone Can Build Software Now, Why Haven’t You Started?

Bartosz Siminski — Thu, 24 Sep 2026 16:10:09 +0000

I asked my developers how much code they write by hand today. These are people who love programming and have devoted years of their lives to mastering it. Their answer surprised me: none. They now use that hard-earned expertise to guide AI, make technical decisions, and judge whether what it builds is good enough.

For founders and developers, the implication is uncomfortable. If software is getting easier for you to build, it is getting easier for your competitors too.

Capital Used to Buy the Ability to Build

For years, a founder needed technical skills or the money to hire a development team. Getting from an idea to a working product could take years.

That gave well-funded startups an advantage. A team in San Francisco could raise millions, hire engineers, and build while someone with the same idea and a smaller budget struggled to get started.

AI is lowering the cost of that first step. A small team can now build and test a prototype quickly. Having a product is no longer convincing evidence that you have a defensible business.

Your Next Competitor Is a CFO

Imagine a finance director who has spent ten years watching her team reconcile invoices, spreadsheets, and data from an aging ERP system.

She knows where month-end closing gets stuck. She knows which exceptions the software misses. She knows other finance directors dealing with the same problem.

Until recently, that knowledge might not have been enough to start a software company. She could not code, and hiring a development team would have required money she did not have.

Now she can use AI tools to build an initial prototype and put it in front of those contacts. If the problem is painful enough, she might even win her first paying customer before looking for outside funding.

She will still need technical expertise to make the product secure and reliable. But she can build an MVP and find out whether anyone wants it first. That changes who gets a chance to become a founder.

The New Founder Bottleneck Isn’t Code

The finance director knows something a team of talented developers may spend months trying to learn: which problem is worth solving, how finance teams actually work, and who makes the decision to buy.

She can call the people who live with that problem. She knows what they cannot afford to get wrong. Their feedback can shape her product from the first version.

That does not guarantee her success. A finance team already has a way to close its books, however frustrating it may be. She still has to persuade them to change their process, trust a new supplier with sensitive data, and pay for the result.

But she can begin with the problem and the customer. Software is no longer the thing she must acquire before she can test either one.

A Product Can Launch in Weeks. A Business Cannot.

ChartMogul analyzed 6,525 software companies and found that only about one in fifty reached $25 million in annual recurring revenue within ten years of starting to monetize. The others did not necessarily fail; many may have built viable businesses at a smaller scale. But launching software and building a company at scale are very different achievements.

AI can help a founder get a first version into customers’ hands sooner. Then the harder work begins: winning the next customer, making the product dependable, and finding a way to sell and support it reliably.

The finance director can show her prototype to a potential customer and learn that it cannot handle a particular type of invoice. She can fix that case and return with a version the customer can actually try. A short conversation has given her a concrete product decision and AI has made it cheaper to act on it.

A founder who builds faster without having those conversations may simply reach the wrong destination sooner.

Who Has an Advantage Now?

San Francisco still offers powerful advantages: investors, experienced founders, talent, and connections that can help a company grow. Money can fund sales, integrations, support, and the engineering needed to serve larger customers.

What it no longer buys so easily is a head start based solely on the ability to build software.

The finance director outside that ecosystem may have a smaller budget. But she knows the problem, knows the buyers, and can now show them a working solution. If she wins their trust and iterates faster than a better-funded competitor, the bigger development team may have arrived at the wrong product first.

The Problem You’ve Stopped Noticing

Paul Graham advised founders to fix things that seem broken, even when the problem does not look big enough to become a company.

The finance director may have spent ten years looking at exactly that kind of problem. She knows who faces it and what the existing tools get wrong. What changed is her ability to test a solution without first raising millions.

If anyone can build software now, why haven’t you started?

Think of one problem you know from the inside. This week, speak privately with five people who face it. If one of them wants a better way, build the smallest version they are willing to try.

Test

Bartosz Siminski — Sat, 10 Jan 2026 11:18:26 +0000

Test

How to use Cursor + MCP to build AI app in 5 minutes on SAP ERP and S/4HANA On-Premise

Bartosz Siminski — Thu, 27 Mar 2025 08:28:44 +0000

The emergence of new AI models and the dynamic changes that are taking place before our eyes in the application development process raise the question of how this new technology can be used to rapidly create products integrated with the SAP platform.

The integration of SAP with AI and development tools such as Cursor offers speed and is becoming a key ingredient for modernizing SAP systems at a moderate cost, on top of which this technology is available today in an On-Premise systems.

In this article, we discuss how to apply the latest AI models like Claude Sonnet 3.7 to create an application connected to SAP using Cursor and the MCP protocol, without the need for a Business Technology Platform or cloud infrastructure.

Shortcut — watch the live demo here: Build an SAP HCM app in 5 minutes

What is Vibe Coding?

Vibe Coding is an approach to software development that uses AI to transform natural language descriptions into fully functional program code. Previously, it was a consultant who collected functional requirements and then worked with developers to create an extension.

Now, instead of writing code by hand, users describe verbally what they need and artificial intelligence generates, tests and refines the code itself.

What is Cursor?

Cursor is a new product, a highly optimized coding assistant designed to create applications together with AI. It allows you to create apps in minutes/hours instead of weeks/months.

Cursor leverages advanced AI models, such as OpenAI GPT-4o, o1, GPT-4-mini, Claude 3.5 Sonnet, or 3.7 Sonnet, and other local LLM models, to speed up coding processes, allowing developers to create applications with AI.

Can Vibe Coding and Cursor be used with SAP?

Vibe Coding, combined with Cursor and MCP (Model Context Protocol), creates a powerful system for SAP development, enabling natural language-driven creation of both ABAP backend elements and modern React frontends, while integrating with SAP On-Premises systems.

Here’s how it works:

Vibe Coding: The developer describes the desired SAP functionality in plain English (e.g., “Create a purchase order approval app with a Fiori-like interface”) to create a functional specification based on business requirements.
Cursor AI: Translates requirements into technical specification using:
Input provided by the user and pre-defined project rules
List of available APIs in SAP (for example, ABAP modules that serve the data),
Utilizing the MCP protocol for custom operations.
MCP Protocol: Acts as middleware between Cursor and SAP systems to access available APIs, list provided services, and deploy configuration to the SAP system.

*Let’s see how it works * we will build an app step by step to visualize the whole process for better understanding.

Let’s Build an app on SAP On-Premise with AI in 5 minutes
We will build a web application for SAP that displays a list of employees in the SAP HCM module via a web browser, all hosted directly in SAP.

Our goal is to build the application in less than 5 minutes to demonstrate the true value that new AI tools bring to the SAP platform.

Our application will consist of two basic components:

An ABAP function module that provides the data for the app,
A React app that utilizes the data from SAP HCM to visualize it

Step 1: Create function module in ABAP
Let’s go to Cursor. We will create an ABAP function module needed to serve the data by simply typing a Vibe Coding prompt for Claude Cursor AI. We will use the AI model called Claude Sonnet 3.5:

Write a function module that returns information about employees

It took AI 10 seconds! to generate operational ABAP code, which we can now save and activate directly on SAP from Cursor. This function module is automatically available to the Cursor API via our SAP add-on, so Cursor can access it and see how it can use it to retrieve the data.

Step 2: Create a React App to Display Employee Data
Let’s create an app that will show us this data. Now, we will ask Claude AI to create the app for us automatically, just by typing:

Create a React application that shows basic information about employees, then publish it on SAP.

It takes Cursor and its AI around 2 minutes to set up everything for us, including:

Creating all the needed project files,
Automatically calling SAP to read the description of the API (from step 1),
Writing all the React code needed for the application to work,
Installing all the necessary dependencies and setting up build scripts
Running it, so we don’t have to do it manually

Step 3: Deploy and Run the App on SAP
The last step is to publish the app on the SAP Application Server. We will again utilize our MCP add-on, which handles all the steps. We simply ask AI to publish it on SAP by typing:

publish an app on SAP

Are you already familiar with our AI Add On for SAP On-Premises? Let AI bring value to your team and organization. Contact us today to implement these AI technologies in your SAP On-Premise system.

Jump to our site to for more: SAP Build Partner
Or if you like to play with AI tech: AI Website Builder

Let's stay in touch! We can help you with:

Integration of AI tools with SAP infrastructure
Custom MCP Add-On development for SAP
Building custom applications hosted on SAP
Building custom AI applications around SAP

DEV Community: Bartosz Siminski

x402: AI agents and the future of payments

The challenge with today’s payment systems

What is x402?

How an agent pays with x402?

From a protocol to real products

Will pay per use change subscriptions?

When agents buy from other agents

What this could mean for businesses

Who controls the agent’s spending

If Anyone Can Build Software Now, Why Haven’t You Started?

Capital Used to Buy the Ability to Build

Your Next Competitor Is a CFO

The New Founder Bottleneck Isn’t Code

A Product Can Launch in Weeks. A Business Cannot.

Who Has an Advantage Now?

The Problem You’ve Stopped Noticing

If anyone can build software now, why haven’t you started?

Test

Test

How to use Cursor + MCP to build AI app in 5 minutes on SAP ERP and S/4HANA On-Premise

What is Vibe Coding?

What is Cursor?

Can Vibe Coding and Cursor be used with SAP?

Would like to connect? Join my LinkedIn. My brands: Instago Inc. (AI Website Builder), Haergi Ltd. (AI on SAP).