BFSI: merchant enablement and agentic commerce

Scenario and ownership

This is a reference example for an acquiring bank's merchant-enablement pilot, not an already integrated banking product or a claim of live payment execution.

In this synthetic example, an acquiring bank wants to help a fictional Shopify merchant become usable by agentic buyer interfaces. The bank can offer an institution-managed or reviewed hosted AgenticOrg workspace, but merchant/provider/platform contracts still determine actual availability.

AgenticOrg owns seller/buyer runtime. Grantex owns trust/policy/canonical artifacts. Shopify owns merchant catalog/inventory/order truth. The bank/fintech/provider owns payment/mandate execution and customer authorization. OACP is not a reason to make Grantex the engine for every buyer message.

Build one synthetic merchant path

1. Assign a merchant owner, bank integration owner, provider contact and channel owner.
2. Configure merchant-scoped Seller Commerce Agent onboarding and source/channel settings.
3. Obtain read-only access to a sandbox Shopify store with a fictional catalog through the merchant's approved process, or prepare a CSV or JSON file of fictional products to upload on the Sell Everywhere page.
4. Sync synthetic products/variants/images/price/inventory and compare samples with the sandbox store.
5. Send the bounded Grantex authority request and verify/cache issued artifacts.
6. Ask product questions about the fictional catalog through the configured web or agent bridge.
7. Inspect source, freshness, supported facts and refusal behavior.
8. Prepare a provider/POS handoff and confirm that no order/payment state is fabricated.
9. If the pilot includes payment, have the merchant choose its own Plural account in Sandbox on the Sell Everywhere page, and confirm a ready checkout returns a link to that payment page and a paid sandbox order appears on the Orders page.

Process map

This is a bank-led reference pilot with configured merchant, channel and provider paths. A prepared handoff is never a completed transaction.

1. 1
   Bank and merchant setupOwner: Bank integration owner and merchant owner

   Agree identities, read scopes, provider contract and publishing state.

   Human decision

   Owners approve the pilot scope and any channel publication under their own processes.

   Blocked / exception

   Unapproved access or publishing state keeps the channel off.

2. 2
   Merchant-source evidenceOwner: Merchant source owner and configured AgenticOrg sync

   Read-only sync supplies product, price and inventory snapshots for sample checks.

   Blocked / exception

   Missing scopes or stale source facts stop unsupported buyer promises.

3. 3
   Trust artifactsOwner: Grantex authority and AgenticOrg runtime

   The bounded authority request and cache retain scope, source and freshness.

   Blocked / exception

   Invalid or stale artifacts cannot support commitment-bound requests.

4. 4
   Buyer channelOwner: Channel owner and AgenticOrg buyer runtime

   A configured bridge answers from supported merchant artifacts.

   Blocked / exception

   Unsupported channels or facts are refused until the integration is approved.

5. 5
   Provider capabilityOwner: Bank/provider integration team

   A configured provider path checks non-sensitive capability evidence.

   Human decision

   The customer and provider complete any required authorization outside this map.

   Blocked / exception

   Capability evidence alone does not prove a mandate or payment.

6. 6
   Authoritative handoffOwner: Provider, POS or merchant system

   A prepared packet awaits provider, POS or merchant confirmation.

   Blocked / exception

   Absent or failed confirmation stays pending or failed; no paid or placed state is fabricated.

Plural payments and mandates

Arrange the provider onboarding contact, merchant account, sandbox/live access, allowed capability contract and human authorization journey. AgenticOrg can verify provider-owned capability evidence directly through its configured path. Store non-sensitive references, not raw mandate/payment credentials.

What runs today: the payment hand-off. A merchant saves its own Plural client ID, client secret and webhook secret (Sandbox or Production), which AgenticOrg encrypts and never shows again. When a buyer's checkout is ready and the arbiter allows it, the buyer gets a link to a Plural hosted payment page under the merchant's own account, pays there and authenticates the payment, for example with 3-D Secure or a UPI PIN. AgenticOrg never holds the money. A payment confirmed for the right amount, by Plural's signed webhook or the once-a-minute status check, becomes an order with an email to the merchant's administrators; any other payment is refused and logged so the merchant can refund it. Settlement, refunds and disputes stay with the merchant's Plural account.

A credential/token capability check is not proof of a completed mandate or an allowed payment in every geography. Agent-executed payment, where AgenticOrg charges against buyer mandates, needs the provider's real contract, authorization, settlement/error/refund handling and institution approval. It stays switched off; for mandates the OACP runtime remains prepared/non-executing.

Channels and protocol payloads

UCP/ACP/schema.org/AP2/A2A/MCP-style payloads and bridges are not automatic marketplace placement. Agree each target's supported contract, authentication, publication/approval requirements and actual customer journey. WhatsApp/Telegram need configured credentials and channel rollout; ChatGPT/Claude/Gemini/Perplexity need appropriate client/platform setup.

A merchant that turns on Sell everywhere is listed in AgenticOrg's own network once its profile is published: buyers reach it from ChatGPT and other MCP apps through the AgenticOrg MCP server, from the AgenticOrg shopping bot on Telegram, and on the open web through its UCP profile. Google, Microsoft Copilot and Perplexity are shown as registration pending. See Sell everywhere.

Physical-store POS

An offline POS bridge prepares a store-linked handoff and reconciles authoritative provider/POS confirmation. It must preserve merchant/store context, expiry, source, reference and duplicate handling. Do not call a paid receipt successful because an agent displayed a prepared packet.

Pilot success criteria

Verify accurate catalog facts, stale-source refusal, cross-merchant isolation, invalid webhook rejection, channel authentication and non-fabricated transaction state. Keep public discovery off until the publishing path is approved and validated. Measure the complete buyer journey rather than counting adapter names.

Next: Capability status and gaps, Commerce guide, API and agent clients, Team adoption.