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

OACP — agentic commerce, made safe

A purchase, step by step

Walk through one purchase as it works today: the buyer's agent opens a checkout, the arbiter checks your signed facts and limits, the buyer pays on your own Shopify checkout or Plural page, and the order reaches you. Agent-executed payment with mandates is built and switched off.

Merchants and agent platform teams8 min readReviewed 2026-10-30
On this page

A purchase today: the buyer pays on your page

The example uses a synthetic shop, Merchant Example, that has chosen where its buyers pay on the Sell Everywhere page.

The buyer pays on your page

The buyer's checkout is ready. The arbiter checks the shop's signed facts and limits and records its decision. The buyer gets a link to the shop's own Shopify cart or Plural payment page and pays there. The shop gets the order.

Five steps. A buyer's checkout is ready in a chat or an AI app. The AgenticOrg arbiter checks the shop's signed facts and records its decision. The buyer gets a link to the merchant's own payment page: its Shopify cart or its Plural payment page. The buyer pays there and authenticates the payment themselves. A Plural payment becomes an order on the Orders page with an email to the merchant; a Shopify order is in the merchant's Shopify admin. AgenticOrg never takes the money.1BuyerCheckout is readyIn Telegram, ChatGPT or another app2AgenticOrg arbiterChecks the shop's factsDecision sealed in the ledgerrecorded3AgenticOrgHands over your linkYour Shopify cart or Plural page4BuyerPays on your pageCard, UPI or net banking, with 3-D Secure or PIN5MerchantGets the orderOrders page and email, or Shopify admin
  1. Find the productOwner: Buyer agent

    The buyer's agent searches your catalog through UCP, the ACP feed, the AgenticOrg MCP server or the AgenticOrg bot on Telegram. 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 opens a checkout and chooses shipping, or store pickup where your shop has store locations. AgenticOrg prices it from the verified catalog and your shipping rates and moves it to ready_for_complete.

    Blocked / exception

    An unknown or out-of-stock item, or no shipping option for the buyer's country, keeps the session incomplete.

  3. Arbiter decidesOwner: AgenticOrg arbiter

    Before any link exists, the arbiter checks your signed facts and your order limits, including the daily maximum. The allow is used once, for exactly this checkout.

    Blocked / exception

    A refusal names the rule and the reason, for example daily_amount_cap_exceeded, and no link is issued.

  4. Payment linkOwner: AgenticOrg

    Complete answers requires_escalation with continue_url: your Shopify cart with the items in it, or a Plural payment page under your own Plural account. Asking again returns the same link while it is valid.

    Blocked / exception

    payment_setup_incomplete means your payment method is not fully set up; payment_handoff_unavailable means the shop has no payment link for this channel, or that the items cannot be paid in its Shopify checkout: an item that is not from its Shopify store, an item sold by a unit such as weight, or more than 9,999 of one item.

  5. Buyer paysOwner: Buyer and your payment page

    The buyer opens the link and pays on your page by card, UPI or net banking, authenticating with 3-D Secure or their UPI PIN.

    Blocked / exception

    A Plural link lasts 30 minutes; after that the buyer asks for a new one.

  6. OrderOwner: Your payment provider and AgenticOrg

    Plural confirms the payment through its signed webhook or the check AgenticOrg runs every minute, and the checkout becomes an order on your Orders page, with the delivery address the buyer gave and an email to your administrators. A Shopify order is in your Shopify admin.

    Blocked / exception

    A payment for the wrong amount never becomes an order; it is logged so you can refund it in Plural.

No mandate, passkey or spending cap is asked for on this path. The agent holds no payment credential and moves no money, and the buyer authenticates on the payment page. See Getting paid to set it up.

Agent-executed payment with mandates (switched off)

AgenticOrg also has a path where the purchase completes without leaving the chat: the payment provider charges against signed buyer mandates. It is built but switched off. Payment execution stays off until a payment-provider sandbox run has passed, and a shop that chose where buyers pay always gets a payment link instead. The rest of this page explains how that path works.

The example uses 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. This path is switched off.

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, as it is today, 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

On the mandate path 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.

On today's path a buyer who pays by UPI on your Plural page approves the payment with their UPI PIN there, as with any online payment.

What is on by default

The checkout routes, the AgenticOrg network, mandates and payment execution each start switched off. Once checkout is on and you have chosen where buyers pay, a ready checkout gives the buyer a link to your own payment page. Agent-executed payment stays off, so no money moves without the buyer paying on that page. See feature switches.

Implementation references

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