Your Next Customer Will Never Open Your App

I am writing this from a charging conference in Berlin, where several thousand people are working very hard on the driver's experience. Better apps. Fewer taps. Clearer pricing screens.

Meanwhile, in the same halls, the industry is quietly designing the driver out of the transaction altogether.

The customer is already leaving the interface

Plug & Charge has been shipping for years. You plug the cable into the car, and the vehicle and the charge point complete a digital handshake that verifies the transaction and starts the session. No app. No card. No tap. The car is the account holder, and the person holding the cable is a courier.

That is not a forecast, it is ISO 15118, and it is deployed today.

What makes this interesting now is the next step, which is not the car paying but the car deciding: which charge point, at which price, at which hour, under which constraints. On 10 June 2026 Mastercard introduced Agent Pay for Machines, a service to let agent-initiated transactions be "permissioned, orchestrated and settled at machine speed" — credentials for agents, explicit permission rules, and settlement that clears amounts worth fractions of a cent. It launched with more than thirty partners in an early adoption phase rather than as a finished product, which is the honest way to read it. But the direction is not ambiguous.

Put the two together and you get a customer that never opens your app, never sees your onboarding, and never forgives you for anything.

An agent does not see your UX. It sees your API.

This is the part that should worry anyone who has spent a budget cycle on interface work.

A human customer is a remarkably forgiving integration partner. Show them an ambiguous tariff — a price per kWh, a session fee, a blocking fee that starts after some number of minutes nobody displays — and they will squint, guess, and pay it anyway. Give them an error message that says something went wrong and they will try again, because they want the outcome and they have no better option.

An agent does none of this. It parses. If your tariff object can be read two ways, it will be read the wrong way at scale and consistently. If your charge detail record arrives two days after the session, the agent's reconciliation was wrong for two days. And an error that says something went wrong is the worst possible response you can give a machine, because it carries no information about the one thing the machine needs to know: retry, or do not retry.

Every one of those has been treated as backend hygiene — a data-quality ticket, a nice-to-have on the integration backlog, something to clean up after the customer-facing work is done. When the customer is a machine, they are the customer-facing work. The interface is the API, and it has been running without a designer for a decade.

Know Your Customer becomes Know Your Agent

The commercial change drags a governance change behind it, and the governance change is the harder one.

Know Your Customer establishes who a person is before they are allowed to move money. Its machine-era counterpart has to establish something structurally different: which agent acted, who authorised it to spend, within what limits, and how do you prove that mandate afterwards. Not identity — mandate.

This is not a payments problem that payments companies will solve on everyone else's behalf. It is an accountability design problem, and it lands on the organisation deploying the agent. If a fleet's charging agent spends four times the budget in a week because a price feed was stale, the interesting question is not which model made the decision. It is who set the limit, who could see it being breached, and who is answerable for it — and whether any of that can be reconstructed from the logs after the fact.

Most organisations cannot answer those questions today for agents that only send email.

The gap this exposes

Here is what makes this more than a charging story.

In the enterprise AI work I do, the live debate in most organisations is still whether an agent may be allowed to draft and send a message on someone's behalf. That is the frontier of the governance conversation: a text, to a colleague, in a system where every action is reversible.

In this industry, the agent is about to buy electricity. Real money, real settlement, real counterparties, no undo.

The two conversations are the same conversation, and they are running years apart. The gap is not technical maturity — the payment rails, the credentialing and the protocol layer are further along than most people's governance. The gap is that autonomy arrived in commerce before anyone finished deciding who is accountable for it.

Three questions worth answering before your first machine customer

Not a framework. Three things you can check this quarter.

1. Can a machine read your prices without a human interpreting them? Not whether the data exists — whether it is unambiguous. Take your own tariff structure and ask whether two competent engineers would compute the same total from it.
2. Does your error surface distinguish "retry" from "do not retry"? Every generic failure message is a decision you are pushing onto a caller who cannot make it, and who will make it badly and repeatedly.
3. Who is accountable for an agent's purchase, and can you prove the mandate afterwards? If the answer involves the phrase "we would look into it", you have a governance gap and not a logging gap.

None of these require an AI strategy. They require deciding that the machine on the other end of the integration is a customer, and treating it like one.

The uncomfortable part is that the machine customer will not complain, churn loudly, or leave a review. It will simply route around you — silently, consistently, and at a scale no human customer ever could.