Publisher and claim policy
MandateShield publishes and maintains the hosted product, reference implementation, open boundary contract and technical documentation. Product claims are derived from inspectable API behavior and machine-readable contracts. Customer use, revenue, savings, certifications and independent audits are not inferred from the implementation and are not claimed without a named source.
Two deliberately different profiles
The v1 analysis profile evaluates supplied or registered policy facts and always returns enforcement_authorized=false. The strict v2 production profile adds an active live VERIFY credential, immutable account-registered mandate, pinned issuer key, exact issuer/audience/protocol match, server-issued one-time challenge, signed freshness, final-purchase digest binding, durable replay tombstone, signed receipt, public transparency record, private execution audit and a short RESERVED execution authorization. Optional LIFETIME, UTC-day and UTC-month cumulative limits are reserved atomically with that authorization.
This separation prevents a policy-only ALLOW, a caller-supplied key or a sandbox demonstration from being represented as permission to move money. Even a qualifying strict result is only a consumable reservation, not permission to call a payment provider directly.
Execution lifecycle and privilege separation
Verification and payment-gateway transitions use distinct credentials. A VERIFY key can establish authority and reserve cumulative-budget headroom but cannot transition it. APROCESSOR key is bound to one exact gateway audience, cannot verify authority, and must remain outside the model, agent and browser.
Under the current production default, the trusted gateway must atomically transition RESERVED to CONSUMED with an exact provider binding. That transition creates a durable provider-submission record and signs a short-lived permit while provider_submission_permitted=false. It prepares one attempt; it does not authorize the gateway, customer or agent to submit payment.
A customer-deployed credential-isolated execution edge must freshly redeem the exact permit and signed request binding online immediately before execution. Only the first response with provider_submission_permitted=true, status=CLAIMED and idempotent_replay=false grants MandateShield authority for the idempotent provider operation, using the signed provider idempotency key. This single-winner state does not guarantee exactly-once provider delivery. Offline verification, an expired claim or any replay remains non-executable.
Reporting the provider attempt stores a caller observation as a hint. For configured supported profiles, MandateShield then reads the exact Stripe PaymentIntent or canonical x402 chain state without trusting the caller report. Only exact, non-conflicting PROVIDER_API_VERIFIED or CHAIN_FINALIZED evidence can autonomously COMMIT confirmed success or RELEASE confirmed non-submission or failure. Unknown or conflicting outcomes remain fail-closed and reserved; after the settlement deadline their budget allocation is conservatively charged and never automatically released.
These are three distinct state domains: authority moves through reservation and consumption, a permit moves through issuance and one fresh claim, and the provider operation moves through pending reconciliation to a verified terminal outcome. None of those states alone proves the others.
How controls are derived
The boundary normalizes payment-relevant facts shared by agent commerce systems: human authority, amount, currency, final payee, agent identity, consent reference, expiry, signed intent, relying party and unique execution attempt. Strict v2 directly verifies the supported ES256, RS256 or PS256 JWS, AP2-shaped closed-payment SD-JWT projection with RFC 9901 KB-JWT, and normalized TAP-shaped RFC 9421-style evidence profiles described in the product contract. The wider AP2 checkout/delegate chain, raw Visa structured-field and trust-store processing, payment-network settlement and credential verification remain outside the boundary.
Deterministic versus advisory evidence
Amount, currency, merchant, expiry, registered-policy binding, cumulative-budget availability, signature validity, key pinning, issuer, audience, nonce, transaction digest, replay state, API-key scope and legal execution-state transitions are deterministic inputs to a fail-closed result. Prompt-injection patterns are heuristic text signals. Privacy-thresholded cross-account observations are contextual signals. The latter two can require REVIEW but do not create an automatic community block or override cryptographic authority.
How behavior is tested
Automated tests cover valid and malformed envelopes, currency-aware minor-unit conversion, overspend, merchant substitution, expiry, missing consent, advisory prompt-injection handling, ES256 JWS, AP2 closed-payment projection disclosure and KB-JWT integrity, TAP content-digest substitution, missing evidence, privacy-safe receipt transparency, strict batch ordering, cumulative-budget serialization and the client-side reservation/consumption invariant. Adversarial integration tests also cover permit-binding substitution, parallel redemption, idempotent replay, provider outcome conflicts and terminal reconciliation that does not trust the caller assertion. Contract and build checks cover the integrated application; runtime health is reported separately.
Evidence minimization
Signed receipts commit to canonical input and decision digests rather than publishing full purchases. The public transparency lookup records fixed digests, outcome, protocol, receipt key and issuance time. Account-specific mandate, key and execution-audit data remain in the authenticated control plane.
Explicit limitations
- The hosted verification service does not require card, bank, private signing or other payment credentials; customers must not submit them. It does not submit or settle payments.
- Optional first-party Gate adapters run inside customer infrastructure, where they may validate payment credentials, freshly redeem one exact provider-bound permit, submit one operation and report its outcome for reconciliation.
- Gateway reports and signed webhooks are hints, not independent terminal proof. Only configured provider-API or finalized-chain verification can autonomously finalize the authorization.
- A gateway or provider that bypasses provider binding and fresh permit redemption is outside the boundary MandateShield can enforce. Current provider- or facilitator-wide adoption is not claimed.
- It does not replace fraud, sanctions or payment-network controls.
- An authorization does not guarantee a transaction is legitimate.
- The open boundary is not an accredited consensus standard.
- The transparency lookup is not represented as a Merkle ledger.
- Revenue, savings and loss avoidance are never guaranteed.