OPEN VENDOR SPECIFICATION · V2.4.0

A portable execution invariant for autonomous payments.

The Mandate Execution Boundary separates policy analysis from a cryptographically trusted reservation that a gateway must consume before one exact provider submission.

Execution invariant

  1. decision = ALLOW
  2. enforcement_authorized = true
  3. mode = live
  4. persisted = true
  5. assurance.authority_valid = true
  6. assurance.key_trust = ACCOUNT_PINNED
  7. execution_authorization.state = RESERVED
  8. execution_authorization.consumable = true

Analysis requirements

  1. Resolve the final amount, currency and merchant.
  2. Bind mandate, agent and unique payment-attempt identifiers.
  3. Return ALLOW, REVIEW or BLOCK with stable reason codes.
  4. Represent heuristic prompt and community signals as REVIEW.
  5. Never advertise a v1 result as executable authority.

Strict production requirements

  1. Use an active live credential scoped to one account.
  2. Load the active immutable mandate version from the account registry; do not trust agent-supplied production limits.
  3. Verify the authority signature with a public JWK whose RFC 7638 thumbprint, issuer, audience and protocol exactly match an active account pin.
  4. Require signed iat and exp with a validity window no longer than 24 hours.
  5. Consume a server-issued, five-minute challenge once for the same account, mandate and protocol.
  6. Bind signed authority to the exact canonical final purchase digest; TAP binds the exact content-digest and required request components.
  7. Persist an account-wide idempotency tombstone before returning an executable result.
  8. Atomically reserve the amount against every configured lifetime, UTC-day and UTC-month budget.
  9. Issue a public-key-verifiable signed receipt and commit its public transparency, private execution-audit and RESERVED state records.
  10. Use distinct VERIFY and PROCESSOR credentials; bind each PROCESSOR credential to one exact relying-party audience.
  11. Create a durable ProviderSubmission with the signed permit, require a fresh non-replayed claim before one provider attempt, preserve provider idempotency, check the terminal outcome without trusting the caller report and autonomously COMMIT or RELEASE strong evidence.

Execution transition requirements

  1. Authenticate with a PROCESSOR key bound to the signed audience.
  2. Bind the exact receipt, envelope, audience and transition idempotency key.
  3. Require provider_submission_permitted=true, current state CONSUMED and idempotent_replay=false before provider submission.
  4. Persist the ProviderSubmission ID with the permit and return it from redemption.
  5. Record a caller report or signed webhook only as a non-terminal observation.
  6. COMMIT or RELEASE autonomously only after exact Stripe API or canonical x402 chain verification produces strong provider evidence.
  7. Keep pending, unknown and conflicting outcomes conservative under durable reconciliation retries.
  8. Treat manual processor_result as an authenticated customer-adapter assertion with independent_verification=false.

PORTABLE CONTRACTS

Inspect the same meaning across every integration.

Purchase envelope JSON Schema/schemas/purchase-envelope.jsonAnalysis decision JSON Schema/schemas/decision-receipt.jsonCryptographic evidence JSON Schema/schemas/cryptographic-evidence.jsonSigned decision receipt v2.1/schemas/decision-receipt-v2.jsonProviderSubmission v1 JSON Schema/schemas/provider-submission-v1.jsonProviderEvidence v1 JSON Schema/schemas/provider-evidence-v1.jsonReconciliationRecord v1 JSON Schema/schemas/reconciliation-record-v1.jsonReceipt verification JWKS/.well-known/jwks.jsonCanonical reason-code registry/reason-codes.jsonHosted HTTP reference/openapi.jsonAdvisory threat context/api/v1/threat-intelligence

STABLE REASON CODES

REPLAY_DETECTED

The account already consumed this payment-attempt identifier.

REGISTERED_MANDATE_REQUIRED

No active account-registered mandate matches the production request.

VERIFICATION_CHALLENGE_INVALID

The signed server challenge is absent, expired, consumed or bound elsewhere.

UNTRUSTED_VERIFICATION_KEY

The verification key is not actively pinned to this account and protocol.

TRUSTED_ISSUER_MISMATCH

The signed issuer differs from the issuer registered with the key pin.

TRUSTED_AUDIENCE_MISMATCH

The signed audience omits the relying party registered with the key pin.

SIGNED_INPUT_BINDING_MISMATCH

The signed purchase digest differs from the evaluated envelope.

EXECUTION_AUTHORITY_NOT_ESTABLISHED

Policy passed but the result lacks live account-pinned execution authority.

Status of this specification

This is an open, vendor-published technical contract and reference implementation. It is not represented as an accredited, regulated or consensus industry standard. Compatibility means implementing the published behavior; it does not imply certification by MandateShield.

REFERENCE IMPLEMENTATION

Use the hosted boundary through HTTP, MCP or A2A.

Integration guide →