Supported does not mean every native payload is parsed.

METHODOLOGY

How support is classified

Strict profile accepted means the current v2 API accepts the declared protocol enum only with its documented evidence format. Native payload accepted would mean the API parses an unadapted source-protocol message directly. That value is false for every row in this normalized API.

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 July 24, 2026.

AP2 · SUPPORTED EVIDENCE PROFILE

AP2: Agentic Payment Protocol

• Strict v2 accepts the declared protocol: yes
• Unadapted native protocol payload accepted: no
• Accepted evidence format: sd-jwt
• Normalization owner: integrator

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

• Project the final closed-payment evidence into the documented API evidence object.
• 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 wider AP2 checkout/delegate chain is not processed natively.
• Conformance vectors: ap2-holder-proof-required

TAP · NORMALIZED PROJECTION

TAP: Trusted Agent Protocol

• Strict v2 accepts the declared protocol: yes
• Unadapted native protocol payload accepted: no
• Accepted evidence format: http-message-signature
• Normalization owner: integrator

What MandateShield verifies

• Normalized RFC 9421-style signature projection
• Method, authority, path and content-digest coverage
• Created, expiry, nonce and signature
• Exact purchase-envelope content digest
• Account-pinned key trust

Integrator responsibilities

• Parse and normalize upstream Visa structured fields.
• Apply the appropriate Visa trust-store and participant onboarding rules.
• Supply the documented normalized components and signature input.

Limits and evidence

• Raw Visa structured fields are not parsed natively.
• MandateShield does not implement the full Visa trust-store profile.
• Conformance vectors: tap-required-component-omitted

UCP · INTEGRATOR NORMALIZATION REQUIRED

UCP: Universal Commerce Protocol

• Strict v2 accepts the declared protocol: yes
• Unadapted native protocol payload accepted: no
• Accepted evidence format: jws
• Normalization owner: integrator

What MandateShield verifies

• Normalized final purchase envelope
• Compact JWS signature and exact input digest
• Account-pinned issuer, audience and protocol
• Registered mandate policy and execution state

Integrator responsibilities

• Resolve UCP version, negotiated capabilities and checkout state.
• Normalize the final total, merchant and checkout facts.
• Create the documented signed JWS projection.

Limits and evidence

• Raw UCP service messages and capability negotiation are not parsed natively.
• UCP interoperability does not replace payment-authority or gateway controls.
• Conformance vectors: No protocol-specific vector is claimed.

X402 · INTEGRATOR NORMALIZATION REQUIRED

X402: x402 payment protocol

• Strict v2 accepts the declared protocol: yes
• Unadapted native protocol payload accepted: no
• Accepted evidence format: jws
• Normalization owner: integrator

What MandateShield verifies

• Canonical atomic-unit string
• Asset decimal exponent
• Asset, network, resource and merchant scope
• Compact JWS and exact input digest
• Registered mandate and replay state

Integrator responsibilities

• Parse the selected HTTP 402 payment requirement.
• Normalize exact asset, network, resource and payee identifiers.
• Construct or submit payment only after the required gateway transition.

Limits and evidence

• HTTP 402 challenges and payment credentials are not parsed natively.
• MandateShield does not call an x402 facilitator or execute settlement.
• Conformance vectors: x402-exact-beyond-safe-integer, x402-one-unit-over-cap, x402-resource-substitution

ACP · INTEGRATOR NORMALIZATION REQUIRED

ACP: Agentic Commerce Protocol

• Strict v2 accepts the declared protocol: yes
• Unadapted native protocol payload accepted: no
• Accepted evidence format: jws
• Normalization owner: integrator

What MandateShield verifies

• Normalized final checkout facts
• Compact JWS and exact input digest
• Registered amount, currency and merchant scope
• Account-pinned issuer trust and replay state

Integrator responsibilities

• Validate and resolve the current ACP checkout session.
• Normalize the final cart, total, merchant and fulfillment context.
• Keep payment credentials and provider submission in the existing payment stack.

Limits and evidence

• ACP checkout sessions are not parsed natively.
• Fulfillment and payment processing remain with the merchant and provider.
• Conformance vectors: No protocol-specific vector is claimed.

CUSTOM · INTEGRATOR NORMALIZATION REQUIRED

CUSTOM: Integrator-defined normalized protocol

• Strict v2 accepts the declared protocol: yes
• Unadapted native protocol payload accepted: no
• Accepted evidence format: jws
• Normalization owner: integrator

What MandateShield verifies

• Documented normalized purchase-envelope fields
• Compact JWS and exact canonical input digest
• Account-pinned issuer, audience and CUSTOM protocol
• Registered mandate, replay and execution state

Integrator responsibilities

• CUSTOM normalization is integrator work.
• Map the source protocol into every required normalized field.
• Sign the exact final envelope with a registered issuer key.
• Maintain source-protocol validation outside MandateShield.

Limits and evidence

• CUSTOM is not a universal parser or automatic adapter.
• Source fields omitted during normalization cannot be evaluated or bound.
• Conformance vectors: jws-final-envelope-substitution

MPP · NOT NATIVELY ACCEPTED

MPP: Machine Payments Protocol

• Strict v2 accepts the declared protocol: no
• Unadapted native protocol payload accepted: no
• Accepted evidence format: none
• Normalization owner: integrator

What MandateShield verifies

No protocol-specific verification profile is claimed for this declared protocol.

Integrator responsibilities

• MPP is not natively accepted as a declared protocol by the current API.
• To use MandateShield beside MPP, an integrator must normalize the final MPP payment facts to CUSTOM and supply the documented compact JWS evidence.
• Keep MPP challenge, credential and payment execution processing outside MandateShield.

Limits and evidence

• There is no native MPP parser, evidence profile or MPP-specific conformance vector.
• A CUSTOM bridge is integrator work and must not be represented as native MPP support.
• Conformance vectors: No protocol-specific vector is claimed.

GLOBAL LIMITATIONS

Protocol compatibility is not payment execution

• MandateShield evaluates normalized authority evidence and purchase facts; it does not hold or validate payment credentials.
• It 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.
• 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.