Release 2.13.0: verify session before paying, single-flight PaymentIntent creation, mppx 0.11.0

[vvillait88]

Summary

Release 2.13.0: a way to get a verify_url before paying, a fix for Stripe rate-limit failures under concurrent identical requests, and the coupled-set move. Worked with Varun.

Verification session without a payment credential. On an identity-gated Checkout the gate runs only on the settle leg, so a buyer with no identity reached the session-bearing 403 only by first sending a payment credential. A Stripe SPT buyer therefore had to mint a token just to learn they needed to verify, and a real buyer on a storefront read the 402 as offering no path to a verify link at all. Now:

• The discovery 402 carries an identity_bootstrap block (header, value, instructions) whenever the store is identity-gated and the request has no identity header.
• A request carrying X-Verification-Session: create (case-insensitive), no identity and no payment credential runs the gate, which returns its existing session 403 with verify_url, session_id, poll_secret and poll_url.
• It is opt-in rather than automatic because discovery scanners replay the Bazaar example body on a schedule: minting on every identity-less 402 would create an AgentScore session and, on goods stores, a pending order for every probe. Gateless merchants neither advertise nor honor the header.
• The generated llms.txt identity section and the Stripe/Link onboarding step name the header.

Concurrent PaymentIntent creation. Storefront logs showed Stripe rate_limit 429s tagged stripe-rate-limited-reason: resource-specific and stripe-should-retry: false, all from createMultichainPaymentIntent, clustered on a scanner's 30-minute cycle: identical requests racing in one process each sent paymentIntents.create under the same idempotency key. Keyed calls now share one in-flight promise, cleared when it settles (success or failure), so parallel identical requests make one Stripe call. Unkeyed calls are unchanged.

Coupled set. mppx 0.11.0 and viem 2.57.0 (dev pins and the viem override), matching pay 0.5.9. The Tempo zero-amount proof domain is still version 3, and 0.11.0's attribution-memo change only removes the custom-memo exemption, which no consumer here uses; the 0.10.1 client already writes the challenge-bound memo and the encoding is byte-identical.

fast-uri advisories. The dependency scan flagged GHSA-58mr-gqgx-xq4g and GHSA-qw65-cvwx-89v3 on the locked fast-uri 3.1.6 (under ajv) and 4.1.3 (under @fastify/ajv-compiler and fast-json-stringify). Both fixes sit inside the declared ranges, so no install re-resolves them, and a top-level override cannot serve two majors at once. The three lock entries are rewritten in place to 3.1.8 and 4.2.1 (the newest in each line, both well past the release-age soak) with their registry integrity hashes; a frozen install accepts the lock and installs those versions at each position, and osv-scanner reports no issues across 898 packages.

Type of change

• Bug fix (no breaking change)
• New feature (no breaking change)
• Breaking change (existing callers must update)
• Docs, tests, or internal maintenance only

Public API

Additive. New export VERIFICATION_SESSION_HEADER from the top-level entry. Identity-gated 402 bodies gain a top-level identity_bootstrap object; a merchant bodyExtras key of the same name still wins. createMultichainPaymentIntent keeps its signature. No migration needed.

Test plan

• tests/checkout_verification_bootstrap.test.ts: the 402 advertises the header only on a gated store with no identity; the header returns the session 403 without payment; name and value match case-insensitively; an identity header or any other value is ignored; a gateless store neither advertises nor honors it. With the new logic disabled, the three behavior tests fail and the three controls pass.
• tests/stripe-multichain/payment_intent.test.ts: concurrent same-key calls make one Stripe call; different keys and unkeyed calls do not share; a later call after settle calls again; a failure reaches every waiter and clears the key. The two sharing tests fail on the previous code.
• Ran locally: lint, typecheck (including examples), knip, test (1835 passed, 4 skipped), build.

Checklist

• Tests cover the new behavior, and the suite passes locally
• Lint, format, and type checks pass
• Docs and README examples updated if the public surface changed
• No secrets, credentials, or personal data in the diff or the tests