Skip to guide
AgenticOrgDocs
Open app
Documentation/OACP — agentic commerce, made safe

OACP — agentic commerce, made safe

A purchase, step by step

Walk through one agent purchase: Intent, Cart and Payment mandates, the buyer's passkey, RBI AFA for UPI AutoPay, the arbiter's decision, the payment and the order.

Merchants and agent platform teams5 min readReviewed 2026-10-21
Markdown source
On this page

The journey in one picture

The example uses a synthetic shop, Merchant Example, and a buyer who allows up to ₹2,000.

A purchase with mandates

The buyer agent opens a checkout. Grantex issues the Intent, Cart and Payment mandates, the buyer's passkey signs the cart when the buyer is present, and AgenticOrg verifies all three. The arbiter decides; on allow the payment provider charges once and the order is confirmed; everything is recorded.

Eight steps. The buyer agent opens a checkout priced from verified catalog facts. Grantex issues an Intent mandate for what the buyer allowed, for example up to 2,000 rupees at one shop; a Cart mandate for this exact cart by hash, signed by the buyer's passkey when the buyer is present; and a Payment mandate for the amount, rail and a token fingerprint, never the token itself. AgenticOrg verifies all three. The arbiter applies eight rules and answers allow or refuse; UPI AutoPay may first need RBI AFA. The payment provider charges once, only on allow, behind a switch that is off by default. The ledger records the mandate hashes, the decision and the payment.1Buyer agentOpens a checkoutPriced from verified catalog facts2Grantex · Intent mandateWhat the buyer allowedExample: up to ₹2,000 at one shop3Grantex · Cart mandateThis exact cart, by hashBuyer present? Their passkey signs itpasskey4Grantex · Payment mandateAmount, rail, token fingerprintNever the card or UPI token itself5AgenticOrgVerifies all three mandatesSignatures, revocation, this checkout6AgenticOrg arbiterEight rules: allow or refuseUPI AutoPay may first need RBI AFAIndia: AFA7Payment providerCharges once, only on allowBehind a switch that is off by default8AgenticOrg ledgerRecords it allMandate hashes, decision, payment

The three mandates, in plain words

A mandate is a signed note of what the buyer allowed. Grantex issues all three. Each lives at most 10 minutes.

Mandate Plain meaning Example
Intent "My agent may spend up to this much, at these shops." Up to ₹2,000 at Merchant Example
Cart "This exact cart, and nothing else." One office tote, ₹1,499, by its hash
Payment "Charge this amount, on this rail, to this token." ₹1,499 by card token on Plural

The Cart mandate binds the cart by a hash. Change one item or one price and the hash changes, so the mandate no longer matches.

The Payment mandate never holds the card or UPI token itself. It holds a fingerprint of it.

Step by step: who does what

  1. Find the productOwner: Buyer agent

    The buyer agent reads the shop's catalog through UCP or the ACP feed. Prices and stock come from verified facts.

    Blocked / exception

    Without fresh verified facts the catalog answers with no products.

  2. Open a checkoutOwner: Buyer agent and AgenticOrg

    The agent creates a checkout session. AgenticOrg prices it from the synced catalog and moves it to ready_for_complete.

    Blocked / exception

    An unknown or out-of-stock item keeps the session incomplete.

  3. Intent mandateOwner: Grantex

    Grantex records what the buyer allowed: the description, the spending cap and the shops.

    Blocked / exception

    Grantex refuses when the buyer's passport cap or consent does not allow it.

  4. Cart mandate and passkeyOwner: Buyer and Grantex

    Grantex binds the exact cart. When the buyer is present, the buyer's passkey on their own device signs the cart hash.

    Blocked / exception

    A missing, wrong or replayed passkey signature refuses the cart.

  5. Payment mandateOwner: Grantex

    Grantex binds the amount, the currency, the rail and a fingerprint of the payment token.

    Blocked / exception

    Card data in the request, or an unknown rail, is refused.

  6. AgenticOrg verifiesOwner: AgenticOrg

    AgenticOrg checks all three signatures, the revocation list and that the chain links to this exact checkout.

    Blocked / exception

    Any failed check stops the purchase with its refusal code.

  7. Arbiter decidesOwner: AgenticOrg arbiter

    Eight fixed rules run in order. The answer is allow or refuse, at once.

    Blocked / exception

    The first failing rule is the reason, and it is recorded.

  8. RBI AFA, India onlyOwner: Buyer and their bank

    A UPI AutoPay payment needs the buyer to approve with their UPI PIN in their own UPI app. AgenticOrg returns that step and waits for nothing.

    Blocked / exception

    Completion is refused until verified AFA evidence arrives from the provider.

  9. PaymentOwner: Payment provider

    The payment provider charges once, against the consumed allow decision. The three mandate hashes travel with the order.

    Blocked / exception

    With payment execution off, checkout stops at executor_unavailable and nothing is charged.

  10. Order and receiptOwner: AgenticOrg and the merchant

    The order is created and a signed order update goes to the agent platform. The ledger holds the mandates, the decision and every payment call.

    Blocked / exception

    A failed payment returns the session to ready_for_complete.

What the decision can say

Three possible answers

The arbiter allows, and the payment runs once; or it refuses and names the first failing rule, and nothing is charged; or, for UPI AutoPay, it asks for the buyer's AFA step, and the next attempt gets a fresh decision.

The arbiter decision has three outcomes. Allow: the payment runs once and the order is confirmed and recorded. Refuse: the first failing rule is named and nothing is charged. AFA first, for UPI AutoPay: the buyer approves in their UPI app, and the next attempt gets a fresh decision.AgenticOrg arbiterDecides at onceALLOWThe payment runs onceOrder confirmed and recordedREFUSEFirst failing rule namedNothing is chargedAFA FIRSTBuyer approves in UPI appNext attempt: a fresh decision

When the buyer is not present

Sometimes an agent buys while the person is away. This is called "human not present".

  • There is no passkey step, because nobody is there to touch it.
  • The shop must set stricter limits for these purchases, for example a lower amount cap. Without them, every not-present purchase is refused.
  • The Intent mandate's cap must cover the total.
  • For UPI AutoPay, the AFA exemption never applies.

RBI AFA for India, in plain words

RBI rules ask for an additional factor of authentication (AFA) on some UPI AutoPay payments.

Payment AFA needed?
Setting up the mandate, and the first debit with it Always
A later debit up to ₹15,000 No
A later debit up to ₹1,00,000 for insurance premiums, mutual fund subscriptions or credit-card bills No
A later debit above those amounts Yes
Amount, currency or debit type unknown Yes, to stay safe

A checkout is always a set-up plus a first debit, so AFA always applies there. The limits are settings, so a future RBI change is a configuration change.

What is on by default

The checkout routes, mandates and payment execution each start switched off. With the defaults, a checkout can reach ready_for_complete but never completes, and no money moves. See feature switches.

Implementation references

This guide is checked against repository sources. Enabled features and deployed versions may differ by environment.