American Express published an open framework this week called Intent Intelligence. The idea is simple. Before an AI agent buys something on a customer's behalf, the customer approves the request. That approval creates an Intent ID and a Proof of Intent Token. The token then issues a payment credential limited to that one approved purchase. The agent never sees the real card number.

Amex says it is working with EMVCo and the x402 Foundation on this, and that it hasn't seen a rise in disputes from agentic purchases yet. Yet is the important word.

Why this matters if you build checkout

Until now, most agent payment demos have been a bit hand-wavy. The agent has some credential, it clicks buy, everyone hopes it bought the right thing. That works in a demo. It falls apart the first time a customer says "I never asked for that."

A proof of intent gives you something you can point at. Who approved, what exactly they approved, and when. For a merchant, that's the difference between winning and losing a chargeback dispute.

It also changes who holds risk. If the credential is scoped to a single purchase, a leaked agent session is a much smaller problem than a leaked card.

What your checkout needs to handle

We'd treat this as a build task now, not a "watch this space" item. A few things to get ahead of:

Accept scoped credentials. Single-use, amount-capped, merchant-locked credentials behave differently from a normal card. Test that your payment flow doesn't choke on them, especially around retries and partial fulfilment.
Store the intent alongside the order. Keep the Intent ID on the order record. When a dispute lands six weeks later, you want one query, not a forensic dig through logs.
Make the approved item unambiguous. If your catalog has vague variants or messy titles, the thing the customer approved and the thing you shipped can drift apart. Clean SKUs and clear variant data matter more when a machine is doing the ordering.
Plan for price changes between approval and capture. What happens if the price moves by 4% after the customer said yes? Decide that rule now. Don't let the agent decide it for you.

The part nobody has solved

Intent tokens prove the customer approved a request. They don't prove the agent understood the request. "Get me running shoes for the marathon" can turn into a very specific, very wrong purchase and still carry a valid token. Verification of intent is not verification of interpretation. Your returns and support flow still has to cope with that.

Our take

Payment networks are moving first because they own the dispute problem. Merchants will feel it second, when agent-initiated orders start showing up with these tokens attached. The teams that already log intent, scope their credentials, and keep catalog data tidy will have an easy time. Everyone else will be patching checkout under pressure.

None of this needs a big rewrite. It's a few unglamorous changes to how you record and validate an order. Do them before agent traffic is a meaningful share of your sales, not after.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!