WebMCP checkout makes human authorization a KYA boundary
Cashfree's WebMCP-based checkout gives AI agents structured access to order and payment-method information while leaving final review and payment authentication with the customer. The KYA control objective is to preserve that boundary as verifiable evidence, not merely a user-interface step.
Daily signal: Public reporting on November 6 says Cashfree launched Checkout for Agents across its hosted checkout, payment forms, and payment links. Agents can read defined checkout data and select a payment route, but customers retain final approval and authentication. This is product infrastructure, not a regulatory rule or formal adoption of KYA.
What changed
Machine-readable checkout reduces the need for an agent to infer buttons and fields from a page designed for people. Cashfree says its implementation exposes defined actions, identifies agent-assisted activity, masks personal information before sharing it, and keeps sensitive payment steps with the customer. Public reporting also says card details cannot be entered through the WebMCP route and UPI authentication remains inside the customer's own app.
This creates a useful separation between preparation and authorization. The agent may inspect the payable amount, items, and available methods, then select a route for presentation. It does not thereby gain authority to authenticate the payment. KYA should make this separation explicit in the mandate, runtime policy, interface design, and audit record.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak checkout control | KYA control for structured agent checkout | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Records only the customer account or browser session. | Distinguishes the represented customer, active agent, agent provider, merchant, checkout service, and final human authenticator. | Customer reference, agent instance, provider, merchant, session, software version, authentication actor, lifecycle state, and event time. |
| Agent mandate | Treats access to checkout data as permission to complete a purchase. | Defines what the agent may inspect, compare, select, and present, while reserving commitment and authentication for the customer unless separately authorized. | Task, allowed fields, permitted actions, merchant and item scope, amount ceiling, expiry, reserved action, approval rule, and mandate version. |
| Wallet and custody | Lets the agent handle reusable payment details or infer that a visible method is spend authority. | Keeps sensitive payment information and authentication outside the agent interface and binds the selected route to the final customer act. | Displayed method class, masked data, selected route, funding source reference, authentication channel, payment result, refund state, and reconciliation. |
| Tool and venue access | Allows broad page control with unclear data reach and unrestricted form interaction. | Exposes an allow-listed set of structured checkout functions with field-level minimization, merchant acceptance, and immediate cutoff. | Available function, requested function, disclosed field, policy decision, denied action, merchant configuration, connection state, and removal time. |
| Audit trail | Stores only the final payment response. | Links agent recognition, order snapshot, disclosed data, method selection, customer review, authentication, settlement, and exception under one task reference. | Task ID, order hash, agent indicator, tool action, data disclosure, selection, customer decision, authentication result, settlement reference, and exception. |
| Security and abuse | Relies on the final authentication step while ignoring manipulated orders, substituted merchants, or repeated prompts. | Tests order integrity, destination binding, data minimization, prompt frequency, session changes, method substitution, replay, and emergency suspension before authentication. | Integrity result, merchant binding, anomaly, blocked action, replay check, approval attempt count, alert, cutoff, investigation, and restoration decision. |
| Jurisdiction fit | Assumes one checkout design is sufficient wherever the merchant or customer is located. | Maps agent-assisted checkout, data disclosure, payment authentication, consumer consent, records, liability, refunds, and complaints to each serving market. | Country, serving entity, customer class, payment method, disclosure version, consent, data condition, liability owner, record period, and remedy route. |
Agent recognition is not agent authorization
A browser signal that marks an action as agent-assisted improves visibility, but it does not prove who deployed the agent, whom it represents, or whether the current purchase falls within a valid mandate. Recognition should trigger policy evaluation, not automatic trust.
The merchant and payment provider should verify the relationship among the customer, agent, task, order, merchant, selected method, and current session. If the amount, items, merchant identity, delivery terms, or payment route changes after review, the system should require a fresh customer decision rather than reuse an earlier approval.
The customer act needs transaction binding
Human involvement is effective only when the customer sees the material terms and authenticates the same transaction that is executed. A generic approval, stale session, or prompt detached from the order can become a rubber stamp.
The authorization record should bind the customer act to an immutable order snapshot, merchant, amount, currency, selected method, delivery destination where relevant, and expiry. The agent should not be able to alter these fields after authentication or reach the systems that change its own permissions.
Practical KYA checklist
- Assign a stable task reference to the customer, agent instance, merchant, checkout session, and order.
- Publish a narrow function allow list and minimize every field disclosed to the agent.
- Separate order preparation, method selection, customer review, payment authentication, settlement, and refund authority.
- Keep reusable payment details, authentication factors, and mandate administration outside the agent's reachable interface.
- Require fresh review when material order or payment terms change.
- Preserve the exact order snapshot, disclosed fields, tool actions, policy decisions, customer act, and payment outcome.
- Detect merchant substitution, changed amounts, repeated prompts, replay, session switching, unusual method selection, and abandoned authentication.
- Provide immediate session cutoff, permission removal, payment investigation, refund handling, and safe restoration.
- Map consent, data use, authentication, liability, records, and customer remedy for each market and payment method.
Bottom line
Structured checkout can make agent activity easier to constrain and audit, but the decisive control is the authorization boundary. KYA must prove what the agent was allowed to prepare, what the customer actually reviewed, which transaction the customer authenticated, and whether the executed outcome remained inside that exact scope.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.