Who authorized the AI purchase? IDEMIA’s agentic commerce payment announcement explained

An AI agent can send a store an order after being asked to buy something. But how does the payment system establish that the person authorized the payment as well?

On September 29, 2026, IDEMIA Secure Transactions announced an Agentic Commerce offering for payment providers. It connects authentication, spending conditions and evidence of consent for purchases initiated by AI agents.[1]

This article uses a hypothetical purchase to explain the checks between a shopping agent and the store receiving payment. Information was checked on September 30, 2026.

What IDEMIA announced for AI commerce payments

The announcement concerns establishing a shopper’s permission at the payment stage of an AI-initiated purchase. Its subject is the movement of money, beyond finding a product.[1]

Who the payment offering is for

The intended audience includes domestic and regional payment networks and private-label card issuers. It is not an announcement that every merchant can enable a single setting in its store admin today.[1]

A merchant would normally investigate availability through its payment provider. If an external service supplies checkout, adding a field to the store does not by itself enable a payment-network capability.

Identify the responsible provider before searching for plugins or changing product pages. Ask how the service handles an AI agent placing an order on a customer’s behalf and which capabilities are available under your contract.

What needs checking when a shopping agent submits an order

An agent-initiated order raises questions about who requested the work and how far the authorization extends. A request to find a product is not automatically a request to pay for it.

Imagine someone asking for a commuting bag. A list of options may satisfy the request; immediately ordering an expensive bag may not. Separate the original instruction, the conditions before ordering and the record available afterward.

Stage	Example question
Request	Who asked for which task?
Before purchase	Does the order meet the budget and merchant conditions?
After purchase	Which authorization supported this transaction?

This table explains the concept. It does not reproduce IDEMIA’s actual interface or record format.

Four capabilities supporting purchases by AI agents

The announcement identifies consent-based provision of payment credentials, passkey authentication, usage controls and evidence of consent.[1]

Provide payment credentials after checking consent

IDEMIA describes providing tokenized payment credentials after consent is established, alongside passkey-based authentication during enrollment and payment.[1] A token is payment information used in place of repeatedly exposing the original card details.

Identity and authorization are separate questions. Knowing that the person is the account holder does not determine which product may be bought or the permitted amount.

A correctly authenticated user might still have requested comparison only. When evaluating a payment flow, locate authentication, consent to purchase and payment execution as distinct steps. One technology name should not be treated as a guarantee covering every step.

Limit the amount, merchant and period, and retain consent evidence

The announced controls include merchant, amount, product category and time restrictions, with verifiable consent evidence that can support later transaction enquiries.[1]

This makes the scope of delegation explicit. “At this store, within this budget, during this period” is easier to compare with an order than an unrestricted instruction to shop.

The available controls and records a merchant can access still depend on implementation and contract. The public announcement does not establish the screens available in a particular Japanese payment service.

A consent record also does not eliminate refunds, delivery problems or customer support. Those parts of order handling still need an operating process.

A hypothetical workflow for asking AI to buy something

The example below illustrates the announced concepts. It is not an IDEMIA implementation walkthrough or instructions for a particular card.

The buyer defines a budget and purchase conditions

Consider buying one storage box for an office. Define both product and payment conditions before delegating the purchase.

Item	Illustrative condition
Product	One storage box for under a desk
Product requirements	Fits the available space; specified color
Payment limit	No more than ¥5,000 including shipping
Merchant	A store selected in advance
Deadline	Reconfirm if the specified date has passed

The amount is only an example, not a product limit. Compare the selected item and final order amount with the conditions. A budget that includes shipping differs from one covering the item alone.

The store also needs to present the finalized size, quantity, shipping and total clearly. Conditions often omitted in casual shopping requests become important when another system acts on the buyer’s behalf.

Handle orders outside the conditions and later customer enquiries

An item may fit the budget until shipping is added. That does not authorize the agent to expand the budget. Check how the implementation handles an order requiring renewed approval.

After purchase, a customer may ask which instruction led to the order. Linking the transaction with its approved conditions can provide a starting point for investigation.

For store operations, identify:

1. How support staff locate the order.
2. Which transaction identifiers the payment provider needs.
3. Who can request or inspect consent evidence.
4. How customers receive cancellation and return guidance.

These are operational review points. The existence of a record does not, by itself, establish that a dispute will be rejected or that a payment is legally final.

What Japanese merchants should check about AI commerce payments

A Japanese store can begin by asking its existing payment provider about availability and operating conditions. The announcement alone does not establish deployment across merchants.

Ask your current payment provider about support

Describe the intended order flow. An assistant recommending products is different from an agent initiating orders and payments on a buyer’s behalf.

An enquiry can use this structure:

We would like to confirm support for orders placed by AI agents on behalf of buyers.
Our payment service and plan: [service and contract]

Please explain:
- Conditions for accepting agent-initiated orders.
- Buyer authentication and consent to purchase.
- Controls for amounts, merchants and other restrictions.
- Records available for later enquiries.
- Features available in Japan, additional contracts and implementation timing.

Please distinguish current availability from planned capabilities.

No card details or customer personal information are needed for this initial enquiry. Begin with the service, contract and workflow you want to understand.

Distinguish announced, contracted and tested capabilities

Use separate statuses for a public announcement, availability under your contract and a test in your own environment.

Status	Evidence to retain
Announcement checked	Official URL and announcement date
Contract eligibility checked	Provider response and applicable plan
Store test completed	Environment, conditions and result

The public materials do not confirm Japanese merchant-by-merchant availability, pricing, launch dates or compatibility with other AI payment standards. Keep those items open until verified.

The announcement makes payment authorization and evidence more concrete in the discussion of delegated shopping. A merchant’s next step is to confirm its provider’s support and prepare a process that can answer questions after an order is placed.