Commerce V1 Overview
Current OACP authority docs start at OACP Authority Overview. This Commerce V1 page is retained for historical/contextual payment-control pilot material and must not be used to imply that Grantex owns the AgenticOrg seller/buyer runtime, Shopify connector runtime, or provider rail execution. Grantex Commerce V1 is the trust, protocol, policy, and canonical-artifact authority for agentic commerce. AgenticOrg runs buyer and seller agents. Merchant systems remain operational sources of record. Provider and fintech rails own mandate and payment execution. Grantex keeps OACP artifacts, source/freshness rules, refusal semantics, consent posture, and audit evidence safe without becoming a toll booth for every non-binding agent interaction. This page also references the separate Grantex Commerce payment-control pilot. That pilot is not OACP runtime artifact launch proof. OACP runtime proof is limited to AgenticOrg seller onboarding, read-only Shopify evidence, Grantex internal artifact issuance, AgenticOrg cache consumption, buyer-safe answers, bridge metadata, and provider-owned capability metadata. Public discovery, checkout, payment, order, mandate, refund, return, shipment, live-provider execution, certification, conformance, standardization, and public OACP publication are not enabled by the OACP runtime artifact path.Current Posture
| Capability | Status | Evidence or gate |
|---|---|---|
| Local/internal sandbox | Implemented | Synthetic catalog, cart, consent, passport, payment, webhook, and audit flows. |
| Temporary Grantex Option A smoke | Verified | internal evidence record (operator-internal, available on request) records 14 passed, 0 failed, 6 failed-safe, 0 skipped. |
| AgenticOrg real-staging handoff | Verified externally | AgenticOrg evidence records authority-checked tools and redacted fixture handling. |
| Internal OACP foundation | Implemented through C6W9 | Artifact family, adapter preview, commitment boundary, prepared envelope, reconciliation, eligibility packet, and dry-run verifier foundations are internal and non-executing. |
| Hosted AgenticOrg API-only discovery | Verified externally | AgenticOrg C3 evidence records hosted MCP/A2A discovery against temporary Grantex smoke. |
| Plural sandbox hosted-checkout adapter | Implemented/gated | Token, hosted checkout order creation, order-status polling, and HMAC webhook verification are behind the provider abstraction and require explicit sandbox flags and credentials. |
| Shopify payment-control pilot merchant | Deployed for the separate Grantex Commerce pilot | mgx0n6-22.myshopify.com is imported as mch_shopify_mgx0n6_22; this is not OACP runtime artifact launch proof. |
| Grantex production Commerce V1 discovery | Separate payment-control pilot surface | /.well-known/grantex-commerce belongs to Grantex Commerce V1 discovery, not AgenticOrg OACP runtime public discovery. |
| Machine-readable live-readiness gate | Separate payment-control pilot gate | Runtime snapshot requires explicit legal, provider, security, operations, OACP E2E, audit, rollback, and human approval evidence. Missing evidence still returns live_readiness_blocked. |
| Production checkout control plane | Separate payment-control pilot only | Consent, Commerce Passport, policy, amount-cap, cart, payment-intent, webhook, reconciliation, and audit controls are not enabled by OACP runtime artifact proof. |
| Plural adapter | Separate payment-control pilot adapter | Webhook intake and adapter health are deployed; production Plural settlement is not claimed while credentials authenticate against UAT-compatible rails. |
Start Here
| Audience | Path |
|---|---|
| Product, merchant success, and implementation owners | Read docs/guides/commerce-v1-agentic-commerce-prd.md as the canonical consolidated PRD, then use docs/guides/commerce-v1-agentic-commerce-implementation-prd.md for the implementation summary. |
| Sellers and buyer-experience reviewers | Read docs/guides/commerce-v1-end-to-end-agentic-commerce-flow.mdx for the one-time seller setup, one-time buyer setup, and regular transaction walkthrough. |
| Developers integrating with Grantex Commerce APIs/MCP | Read this overview, then docs/guides/commerce-v1-developer-guide.mdx and docs/api/grantex-commerce-v1.openapi.yaml. |
| Merchants and operators | Read docs/guides/commerce-v1-merchant-operator-guide.mdx, then docs/guides/commerce-v1-operations.mdx. |
| AgenticOrg integration owners | Read this page, the AgenticOrg commerce docs, and the Option A smoke workflow. |
| Reviewers assessing readiness | Read the smoke evidence and production discovery readiness report before any enablement proposal. |
| End users | For OACP runtime, use buyer-safe product questions with source/freshness labels. Purchases, payments, mandates, and orders are outside this runtime proof. |
Architecture
The important boundary is that the agent does not execute payments or become the merchant system of record. AgenticOrg may initiate approved connector sync jobs and may verify provider-owned mandate capability where approved. Grantex owns artifact authority, policy enforcement, refusal semantics, and evidence requirements. For the full consolidated product requirements, usedocs/guides/commerce-v1-agentic-commerce-prd.md as the source of truth.
End-To-End Flow Summary
- Seller starts in AgenticOrg Seller Commerce Agent, creates an onboarding packet, connects systems through approved connector custody, and requests Grantex authority review.
- Buyer completes one-time setup in their preferred channel: account/session linking, safe preferences, and understanding that current OACP runtime answers are non-binding.
- Buyer asks an AgenticOrg-powered agent to discover or compare.
- AgenticOrg uses cached OACP artifacts when TTL, revocation, and risk rules allow; otherwise it asks Grantex to refresh or verify.
- Commitment-bound actions require boundary, envelope, reconciliation, eligibility, and dry-run checks before any future handoff.
- AgenticOrg explains sourced facts, warns about stale or unknown data, and refuses unsupported claims.
Consent And Commerce Passport Lifecycle
The Commerce Passport is scoped runtime material. It may be used during approved smoke runs, but it must never appear in committed docs, PR bodies, logs, raw payload dumps, or chat.Readiness Gate Ladder
Each gate is separate. The approved Shopify live pilot does not imply broad merchant self-service, provider certification, or production Plural settlement. The runtime live-readiness gate still requires machine-readable approval evidence; feature flags alone are not sufficient to start live commerce.Allowed And Blocked
| Enabled now | Controlled or not claimed |
|---|---|
| Local mock demo and internal sandbox work. | Broad public self-serve merchant onboarding. |
| Approved temporary Option A smoke resources and historical evidence. | Provider certification or standards certification claims. |
Shopify live pilot profile and catalog discovery for mch_shopify_mgx0n6_22. | Production Plural settlement claims while only UAT-compatible credentials are validated. |
| OACP artifact-backed AgenticOrg commerce tools and approved capability verification. | Direct payment execution, live provider credentials, or unapproved private merchant API execution from AgenticOrg commerce. |
| Public JWKS references as verification metadata. | Raw passports, bearer tokens, idempotency key values, secrets, DB/Redis URLs, or raw payloads in docs/evidence. |
Related Documents
docs/guides/commerce-v1-agentic-commerce-implementation-prd.mddocs/guides/commerce-v1-developer-guide.mdxdocs/guides/commerce-v1-merchant-operator-guide.mdxdocs/guides/commerce-v1-operations.mdxdocs/guides/commerce-v1-repeatable-option-a-smoke-workflow.mddocs/api/grantex-commerce-v1.openapi.yaml
docs/internal/commerce-v1/
and are available to authorized reviewers on request via
security@grantex.dev.