Merchant-side AP2 v0.2 implementation report: Suede Agent Studio

[JasonColapietro]

We run AP2 v0.2 merchant authorization in production at Suede Agent Studio (https://agents.suedeai.ai), a visual agent builder that publishes user-built flows as pay-per-call services other agents can discover and buy.

Live surfaces:

• Merchant discovery: https://agents.suedeai.ai/.well-known/ap2.json
• Signed merchant JWKS: https://agents.suedeai.ai/.well-known/ap2-jwks.json
• Every protocol we implement, machine-readable: https://agents.suedeai.ai/api/providers

What is implemented on the merchant side:

• Short-lived ES256 merchant-signed Checkout JWTs bound to one exact service call.
• Deterministic verification of v0.2 Checkout and Payment Mandate schemas, SD-JWT disclosures, configured issuer trust, algorithms, time, audience, challenge nonce, key binding, and delegation and checkout hashes. No LLM makes a trust or payment decision anywhere in that path.
• Authorization bound to the canonical run URL and method, the agent and slug, the immutable live deployment, the canonical input digest, the service schema, network, asset, exact atomic amount, payee, payout address, and expiry.
• Durable reservation of mandate and payment nonce identities before settlement, so exact retries are idempotent while changed-body and concurrent replays fail closed.
• Merchant-signed Checkout Receipts for acceptance or rejection.

Two deliberate limits worth stating plainly. Settlement runs on the x402 v2 rail, since the finalized AP2 and x402 v2 binding is not published yet, so we do not claim general AP2 plus x402 compliance. And we do not act as a credential provider, network, or payment processor, so we never claim to issue a protocol Payment Receipt.

We negotiate the extension over A2A at https://github.com/google-agentic-commerce/ap2/v1, emitting the A2A 1.0 A2A-Extensions header and temporarily accepting the sample client X-A2A-Extensions spelling.

Two asks: a review of the merchant flow against the spec's intent, especially anywhere our deterministic verification is stricter or looser than you intend, and consideration as a merchant-side reference deployment. Happy to feed back whatever we learn running this in production.

[Ectsang]

You asked where your verification is stricter or looser than the spec's intent — I compared your published profile against the constraint set covered by the open conformance suite I maintain (goodmeta/ap2-conformance). Three places line up; one is stricter than a payer will expect; one the profile can't answer.

Where the profile lines up with the suite's rules

• supportedCheckoutConstraints is exactly checkout.allowed_merchants + checkout.line_items — the two checkout constraint types the suite covers.
• receiptReferenceRule: "sd-hash-final-sd-jwt" matches the receipt rule the suite pins: reference = sd-hash of the final SD-JWT segment (AUTH-17).
• unknownConstraints: "rejected" matches the suite's closed-world rule (unknown ⇒ fail, AUTH-15/SPEC-39).

Stricter than a payer will expect

supportedPaymentConstraints declares six types and omits payment.budget and payment.agent_recurrence. With statefulOpenPaymentConstraints: false that reads as deliberate — budget enforcement needs cross-presentation accumulation, which you have declared out of scope. The consequence is worth stating for payers, though: a well-formed mandate that openly carries payment.budget is refused outright, not enforced. Fail-closed is the safe direction; a payer-facing reason for the rejection would make it legible rather than surprising.

The question the profile can't answer

unknownConstraints: "rejected" fires only on constraints that appear. Concretely: an issuer mints an open mandate with payment.budget.max = 50 as a selectively disclosable claim; the holder presents it with the budget withheld. Nothing unknown is visible, so rejection never triggers. If your verifier then evaluates the remaining constraints and finds them satisfied, a mandate whose budget nobody enforced passes as clean. The AP2 SDK has the same shape — its one presence assertion (agent_recurrence requires budget and amount_range) takes its requirement from the presentation being examined rather than from the verifier's own expectations, which is the gap described in #339. Your profile already requires iat/exp/aud/nonce as required claims; the constraint-level equivalent is a required-constraint set asserted regardless of disclosure. Which does your verification do when the budget is withheld: fail the mandate, or evaluate the remainder?

On the reference-deployment ask: the deployment exposes no verification endpoint in the agent card or well-known paths (the obvious paths return 404), so there is nothing for the suite to drive vectors against. The profile comparison above is the full extent of what is checkable from outside — if you ever expose an endpoint that takes a presented mandate and returns violations, the suite runs against it unmodified.