Versioned field projections. Explicit boundaries everywhere.
The exact strict-v2 and adapter boundary for AP2, TAP, UCP, x402, ACP, CUSTOM and MPP—without turning field decoding into inflated conformance, proof or settlement claims.
SUPPORT CONTRACT
One boundary, explicit adapter ownership.
The strict API accepts seven declared protocol profiles. A separate versioned bridge maps documented fields from an AP2 terminal closed-payment projection, x402 v2 PAYMENT-REQUIRED and an explicitly profiled MPP Payment charge challenge. Every row states who maps, what is verified and what remains outside MandateShield.
Strict profile accepted means the current v2 API accepts the declared protocol enum only with its documented evidence format. Native payload accepted means the versioned adapter directly decodes the specifically listed input shape. It never implies complete source-protocol conformance, delegated authority, payment-credential validity or settlement.
Protocol behavior is derived from the current evidence-format map, public API and conformance contract. External descriptions link to primary official protocol publishers. This matrix was reviewed on .
AP2 · SUPPORTED EVIDENCE PROFILE
AP2: Agent Payments Protocol
Strict v2 accepts the declared protocol: yes
Unadapted native protocol payload accepted: yes
Accepted evidence format: sd-jwt
Normalization owner: MandateShield
What MandateShield verifies
Closed mandate.payment.1 projection
RFC 9901 key-binding JWT
Payment amount and currency
Payee and transaction binding
Account-pinned issuer trust
Integrator responsibilities
Use the compact AP2 presentation for production; claims-object input is development-only.
Do not post an upstream AP2 terminal token unchanged. Re-issue the documented MandateShield strict projection with the canonical input digest and RFC 9901 holder KB-JWT, or use the documented CUSTOM JWS profile.
Validate the wider checkout_jwt hash and delegate chain.
Operate or rely on the appropriate issuer trust registry.
Limits and evidence
Open mandates are not accepted by the strict closed-payment profile.
The native adapter parses only the terminal closed-payment projection; it does not establish AP2 v0.2 conformance or verify the wider checkout/delegate chain.
Canonical payee identity network and payTo exactly match the selected offer
Compact JWS and exact input digest
Registered mandate and replay state
Integrator responsibilities
Supply the selected x402 v2 PAYMENT-REQUIRED offer plus canonical payee identity with a trusted merchant-mapping evidence reference and asset-decimal mapping.
Independently validate the merchant-mapping evidence; the projection endpoint binds but does not fetch or certify it.
Any context asset or resource value must exactly equal the selected offer; the adapter rejects substitutions.
Without the optional first-party Gate, verify PAYMENT-SIGNATURE with the appropriate official scheme implementation or facilitator and submit only after the required gateway transition.
With the exact/EIP-3009 Gate, supply a compatible x402 client, durable encrypted journal, local signature verifier, trusted mappings and canonical chain verifier.
Limits and evidence
The hosted native bridge parses the seller's x402 v2 offer but never receives or verifies PAYMENT-SIGNATURE, wallet authority or settlement.
The optional first-party customer-side Gate is limited to x402 v2 HTTP exact/EIP-3009; it is not a facilitator, hosted settlement service, certification or all-x402 implementation.
Explicit charge intent under the integrator-confirmed MANDATESHIELD_PORTABLE_CHARGE_V1 mapping profile
Canonical payee identity service origin and method exactly match the trusted resource and challenge
Strict-v2 account-pinned JWS over the resulting final envelope
Registered mandate, replay and execution state
Integrator responsibilities
Supply the exact server challenge, trusted target resource, canonical payee identity and explicit portable-charge mapping profile.
Independently validate the same-origin identity evidence; the projection endpoint does not establish TLS or domain control.
Confirm that the selected method specification maps amount, currency and recipient with the documented portable-charge semantics.
Verify the method-specific Payment credential with the applicable MPP implementation.
Keep MPP payment execution and receipt/settlement processing outside MandateShield.
Limits and evidence
The native adapter parses only the Payment charge challenge and does not verify a method-specific credential, server-side challenge store or settlement receipt.
MPP wire support is a validated field projection plus an explicit integrator mapping and a separate MandateShield JWS authority profile, not generic or method-specific MPP conformance.
Conformance vectors: No protocol-specific vector is claimed.
The hosted authority-verification route evaluates normalized evidence and purchase facts; it does not require payment credentials, customers must not submit them, and it does not submit or settle payments.
Optional first-party Gate adapters run inside customer infrastructure, where they may validate payment credentials, attempt an idempotent bound provider operation and report its outcome. MandateShield does not guarantee exactly-once provider delivery.
Separate hosted reconciliation is deliberately narrow. For a configured Stripe PaymentIntents or x402 profile, it stores caller observations as hints and reads the exact provider API or canonical chain outcome without trusting those observations. It never creates or submits the payment.
Only non-conflicting PROVIDER_API_VERIFIED or CHAIN_FINALIZED evidence can autonomously finalize with independent_verification=true. Pending, unknown and conflicting evidence stays fail-closed.
That legacy field means caller-independent checking by MandateShield, not an independent organization, provider attestation, certification or audit.
The hosted normalization bridge does not submit AP2, TAP, UCP, x402, ACP or MPP payments to a provider, facilitator, network or merchant.
The protocol's wider trust, discovery, checkout, credential, fulfillment and settlement chain remains in the integration that owns those functions.
This matrix does not claim provider adoption, permit enforcement, partnership or certification.
CUSTOM is not automatic compatibility. CUSTOM normalization is integrator work and must include every material final-purchase fact the operator expects the boundary to enforce.
PRIMARY SOURCES
Official protocol references
The links below point to product contracts and primary protocol publishers. External specifications can change independently and may carry publisher-specific access or license terms.