Skip to main content
Agentic commerce needs more than a working demo. A commerce agent can search a catalog, prepare a cart, ask for consent, and create a mock payment intent, but that does not prove the system is ready to touch live payment rails. Grantex Commerce V1 now treats that distinction as a runtime boundary. Sandbox evidence can prove the control plane works. Live mode needs a separate readiness gate, and the approved Shopify live pilot now runs behind that gate.

​
What Works Today

The current Commerce V1 evidence covers the path from closed-beta validation to the approved Shopify live pilot:
  • Grantex-controlled catalog, cart, consent, Commerce Passport, policy, audit, webhook, and mock-provider flows.
  • AgenticOrg handoff through Grantex-only commerce tools.
  • Shopify and other merchant-system connectors as metadata foundations, not credentialed production sync or direct private API execution.
  • Plural behind the provider abstraction, including token, hosted-checkout, status, and signed webhook handling. The current stored credentials validate against Plural UAT-compatible rails, so production Plural settlement is not claimed.
  • OACP trust-artifact foundations for describing commerce capability and policy without turning those artifacts into payment authority.
That was enough for controlled sandbox validation. The live-pilot promotion added a named Shopify merchant, machine-readable live acknowledgements, production ops health, stored secrets, the Plural webhook route, and hosted OACP E2E evidence before live mode was enabled.

​
Why Flags Are Not Enough

Live payment execution depends on legal language, provider contracts, webhook signature behavior, India data-residency review, final user confirmation, merchant support ownership, append-only audit verification, incident runbooks, 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, live provider paths fail closed with live_readiness_blocked.

​
The Required Evidence

The live-readiness gate requires acknowledgements for legal approval, provider contract confirmation, Plural sandbox E2E completion, webhook signature confirmation, India data residency, final user confirmation text, named pilot merchant approval, hosted OACP E2E evidence, production secret review, append-only audit verification, operator runbook approval, and rollback owner assignment. This keeps the release posture clear:
  • Sandbox and mock-provider evidence can continue.
  • Public docs and demos must distinguish the approved Shopify live pilot from broader provider settlement or certification claims.
  • AgenticOrg must keep using Grantex-only commerce tools.
  • Shopify and Plural remain controlled integrations, not shortcuts around the Grantex consent, policy, and audit layer.
  • Live mode starts only after the evidence packet and runtime snapshot both clear.

​
Current Status

As of June 14, 2026, Commerce V1 is live for the approved Shopify pilot merchant mch_shopify_mgx0n6_22 from mgx0n6-22.myshopify.com. The live-readiness snapshot is complete, ops health reports no blockers, catalog search returns the imported Shopify products, and Plural webhook intake reaches signature validation at https://api.grantex.dev/v1/webhooks/providers/plural. That is deliberately scoped. The boundary between “the Grantex live control plane is running” and “a payment provider has certified production settlement” must stay visible in code, tests, docs, and operations.