Skip to main content
Update, 20 October 2026. The OACP authority work this post anticipates is now merged and deployed in Grantex: signed and revocable artifacts, mandates, countersigned arbiter decisions, and UCP and ACP surfaces. It is not yet turned on in production: the first OACP issuer key and the public status list are operator steps. Live execution still depends on the readiness evidence below. Current status: OACP runtime launch closure PRD.
Agentic commerce needs more than a working demo. A commerce agent can search a catalog, prepare a handoff, ask for consent, and verify provider capability metadata, but that does not prove the system is ready to touch live payment, bank, POS, order, refund, or fulfillment rails. This article is retained as a readiness-boundary note. The current OACP split is that AgenticOrg owns merchant self-service runtime and buyer/seller agent channels, while Grantex owns OACP authority and artifact verification. Merchant configuration, including Shopify today and future WooCommerce/ERP/bank/provider refs, is not by itself live execution approval.

​
What Works Today In The Current OACP Split

The current OACP runtime path covers:
  • AgenticOrg merchant self-service config scoped by tenant, merchant, and seller agent.
  • Shopify read-only Admin GraphQL runtime sync when the merchant provides valid credentials.
  • WooCommerce, ERP, PIM, OMS, WMS, custom API, bank-owned rail, fintech rail, and custom provider setup as pending-adapter config, not fake-live support.
  • Grantex OACP authority requests, ES256-signed artifact issuance or refusal, artifact verification, and protocol adapter governance.
  • AgenticOrg OACP cache and buyer-channel answers with source/freshness labels.
  • Plural/Pine provider-owned capability verification where configured, without claiming payment execution.
  • Offline POS handoff packets and verified confirmation evidence refs without Grantex executing POS transactions.
That is enough to prepare buyer-safe answers and handoffs. It is not a claim that every merchant, channel, provider, bank, POS, or order path is live.

​
Why Flags Are Not Enough

Live payment or order execution depends on legal language, provider or bank contracts, webhook signature behavior, data-residency review, final buyer confirmation, merchant support ownership, audit verification, incident runbooks, monitoring, and rollback ownership. Those are not just deployment details. They are part of the safety model. Commerce V1 therefore exposes a machine-readable live-readiness snapshot. The snapshot reports only safe values: booleans, requirement keys, env names, and blocker strings. It does not carry passports, bearer tokens, provider secrets, raw payloads, DB URLs, Redis URLs, or webhook secrets. If any readiness acknowledgement is missing, provider, bank, POS, or merchant execution paths must fail closed with a precise blocker.

​
The Required Evidence

The readiness gate requires acknowledgements for legal approval, provider or bank contract confirmation, sandbox E2E completion, webhook signature confirmation, data residency, final user confirmation text, merchant approval, OACP E2E evidence, production secret review, audit verification, operator runbook approval, support ownership, and rollback owner assignment. This keeps the release posture clear:
  • Shopify runtime sync can continue when credentials are valid.
  • Future WooCommerce/ERP/bank/provider configs can be saved as pending-adapter setup without implying live support.
  • Public docs and demos must distinguish OACP authority evidence from provider settlement, bank authorization, POS confirmation, channel approval, or certification claims.
  • AgenticOrg must preserve OACP artifacts, source/freshness labels, and fail-closed blockers across buyer channels.
  • Execution starts only after the evidence packet, provider/bank/POS approval, and runtime readiness snapshot all clear.

​
Current Status

As of June 25, 2026, the current public OACP posture is not a broad live-payment or live-order claim. AgenticOrg owns merchant self-service config and Shopify runtime sync; Grantex owns authority artifacts; provider, bank, POS, and merchant systems own execution. Public wording must keep those owners separate. That boundary must stay visible in code, tests, docs, and operations: “OACP authority artifacts are available” is different from “a merchant/provider/bank has approved live execution.”

​
Ownership

Grantex is owned by Orchestrum Technologies LLP. Inventor and owner: Sanjeev Kumar. Ownership contact: sanjeev@orchestrum.in or mishra.sanjeev@gmail.com.
Last modified on October 20, 2026