Agentic Commerce for B2B: Is Your Order Portal Agent-Ready?

On 2 June 2026, Worldline, ING and Mastercard announced that an AI agent had bought tickets for the Royal Concertgebouw Orchestra for an ING customer, from a Dutch merchant, and paid. According to Worldline it was Europe's first live end-to-end agentic payment in production.

Agentic commerce is buying and selling where an AI agent searches, compares, orders and, with permission, pays on the buyer's behalf. For a wholesaler or manufacturer, that means a new kind of customer in your webshop or order portal: software that reads your product data, requests your prices and places an order, with no human clicking through your screens.

The first transactions are consumer purchases on a credit card. For a B2B supplier, where customers buy on account at negotiated prices, it's a different story. That makes the question of what to build now more interesting, not less relevant.

What's already happening with agentic commerce in Europe?

Agentic commerce has been running in production in Europe since summer 2026, but only through the card networks. In the Worldline, ING and Mastercard transaction, the customer explicitly approved the purchase before the agent paid, and the payment carried an identifier that told the bank an agent had initiated it. Mastercard reports that all its European issuers are network-enabled for Agent Pay. Visa followed on 2 July 2026 with live agentic transactions at more than thirty European banks, ING among them.

What these examples share: a consumer, a credit card, a fixed price and a one-off purchase. That's the easy case. A buyer ordering 40 items for an installation company at tiered prices, on account with 30-day terms, is another matter.

Which protocols decide how an AI agent orders from you?

There's no single standard. Five initiatives matter, and they partly complement each other:

Stripe's documentation describes ACP as the standard that defines "how AI agents interact with businesses to complete purchases on behalf of buyers". UCP lets a merchant publish its capabilities in a manifest at /.well-known/ucp, and the merchant stays the merchant of record.

For a European B2B supplier, the column that matters most is payment. The AP2 specification says it outright: the first version supports "credit and debit cards", and "real-time bank transfers" are on the roadmap. For none of the protocols did we find a payment handler for iDEAL, Wero, a SEPA credit transfer or buying on invoice.

Why doesn't agentic commerce fit European payment habits yet?

Much of Europe pays online differently from the markets these protocols were designed for. The Netherlands is the clearest case. According to the Thuiswinkel Markt Monitor for Q1 2026, 72% of all Dutch online purchases went through iDEAL, a bank-redirect method, and 8% through a credit card. By value it's 58% against 16%.

iDEAL is also moving to Wero, the pan-European wallet. According to the Dutch payments association, every iDEAL merchant will have switched by the end of 2027, and EPI says all Dutch banks connect to Wero in October 2026, after which iDEAL payments gradually move onto that infrastructure. We found no public statement from EPI or iDEAL about agent payments.

B2B adds another layer. Business customers often buy on account, with a credit limit, payment terms and prices that differ per customer. A 2021 Ipsos study for Dutch e-commerce parties found that 36% of business buyers prefer to pay by invoice. There's no more recent figure, but anyone processing B2B orders will recognise the picture.

The honest picture, then: the protocols for searching, comparing and ordering are usable, and the protocols for paying don't fit a European B2B order yet. That's not a reason to wait. It's a reason to build the layer that doesn't depend on payment first.

What does an order portal need for a buying agent?

An order portal that's ready for AI agents doesn't do anything exotic. It exposes the same information and rules a human buyer sees, in a form software can read and use reliably. These are the parts we build first:

1. Structured product data. Product pages with schema.org markup for name, image, price, currency and availability, as Google asks for merchant listings, plus a product feed. An agent that can't parse your part numbers and specs will order from a competitor.
2. Customer-specific prices and stock through an API, behind a login. ACP and UCP use OAuth 2.0 for this: the buyer links their customer account to the agent, and the agent then sees their own price agreements.
3. An order API, or an MCP server, that enforces the same rules as your portal: minimum quantities, pack sizes, lead times, credit limits. Those rules belong in the API, not in the user interface. How that kind of connection works is covered in MCP explained.
4. Recognising agents. With Web Bot Auth an agent signs its requests cryptographically, and Cloudflare explains how a merchant can then tell whether an agent has come to browse or to pay. That lets you treat a registered buying agent differently from a scraper.
5. Mandates and confirmation per customer account: up to what amount an agent may order on its own, which product groups, and when a person at the customer must confirm. Record which agent placed which order.
6. Payment the way your customer pays now. For business accounts that stays on invoice. An agent ordering within a customer account's agreed terms doesn't need a new payment method.

Points 2 and 5 are where the B2B portals we come across fall short most often. Price agreements sit in an ERP integration that only fills the web page, and limits exist only as a checkbox on a user. If your portal doesn't exist yet, this is the moment to build it API-first. Building a client portal walks through how that project runs.

Who's liable when an AI agent orders the wrong thing?

An AI agent isn't a legal person and can't conclude a contract itself. Whether an order binds is judged under national contract law. In the Netherlands that's Article 3:35 of the Dutch Civil Code: whoever could reasonably rely on a declaration can be held to it, even if the will behind it was missing. A customer who gives an agent access to their account creates that reliance. The risk of a wrong order then lies, in principle, with the party deploying the agent.

In principle, because practice is set by what you agree. No regulator has issued guidance on this. According to its work programme, the European Banking Authority only starts analysing agentic AI in payments in 2027. So put it in your terms of delivery: orders through a linked agent count as orders from the customer, within which limits, and how a customer can cancel an agent order before it's picked. That protects you and gives your customer clarity.

Build now or wait?

Whether to build now or wait depends on which layer you mean. This is how we'd split it for a B2B supplier with 50 to 500 staff:

The top four rows are the layer that serves an ordinary customer better too. According to Statistics Netherlands (CBS), in 2024 only 27% of Dutch companies with 10 or more staff sold electronically through a website, app or EDI, barely up from 24% in 2014. For most B2B suppliers the first step isn't agentic commerce. It's a portal where a human can order without picking up the phone. Build that well and you're ready for the agent.

What an AI agent is technically, and how it decides, is covered in what an AI agent is. Connecting to your ERP falls under API integrations, and the wider costs of a web project are in website development costs. For the rest of the wholesale chain, from stock to quotes, see AI for wholesale.