Context
Surfaced by a production consumer (Sippar) in solana-foundation/pay-kit#212. They pay the Gemini endpoints on gateway-402.com server-side with @solana/pay-kit and want to amortize the payment-channel open/close across many small calls to the same host.
The correct mechanism is the MPP session scheme (reusable channel, cumulative vouchers), not the upto scheme, which is single-settlement by the canonical x402 spec. The client side is already there (createSessionFetch). The blocker is the gateway: the session flow is end-to-end only if the resource server advertises a session challenge.
Problem
generativelanguage.google.gateway-402.com currently returns only x402-upto in its 402 (payment.schemes: ["x402-upto"], decoded 2026-07-02). Sibling hosts on the same gateway already return MPP challenges:
embeddings.alibaba.* and addressvalidation.google.* return MPP session challenges.
So the gateway runs both stacks; the Gemini host just does not expose a session route.
Request
Expose an MPP session challenge on the Gemini host (generativelanguage.google.gateway-402.com), the same way sibling hosts already do, so high-frequency consumers can open one channel and settle per-call via cumulative vouchers instead of open/settle/finalize per call.
Why it matters (consumer numbers, mainnet)
Per the consumer's own measurements, the channel leg is already fast (~2.7s open + settle + finalize incl. inference), and the deposit is fully refunded. Their per-call overhead is dominated by funding a fresh payer wallet per call, which a reused session channel removes. With a session, calls 2..N need no fresh open and no re-deposited ceiling, cutting both the per-call latency and the ~$1 float per in-flight request.
Sippar has offered to be the test traffic once a host advertises the session challenge.
Related: solana-foundation/pay-kit#212, solana-foundation/pay-kit#175 (payment-channel v1 profile).
Context
Surfaced by a production consumer (Sippar) in solana-foundation/pay-kit#212. They pay the Gemini endpoints on
gateway-402.comserver-side with@solana/pay-kitand want to amortize the payment-channel open/close across many small calls to the same host.The correct mechanism is the MPP
sessionscheme (reusable channel, cumulative vouchers), not theuptoscheme, which is single-settlement by the canonical x402 spec. The client side is already there (createSessionFetch). The blocker is the gateway: the session flow is end-to-end only if the resource server advertises asessionchallenge.Problem
generativelanguage.google.gateway-402.comcurrently returns onlyx402-uptoin its 402 (payment.schemes: ["x402-upto"], decoded 2026-07-02). Sibling hosts on the same gateway already return MPP challenges:embeddings.alibaba.*andaddressvalidation.google.*return MPP session challenges.So the gateway runs both stacks; the Gemini host just does not expose a session route.
Request
Expose an MPP
sessionchallenge on the Gemini host (generativelanguage.google.gateway-402.com), the same way sibling hosts already do, so high-frequency consumers can open one channel and settle per-call via cumulative vouchers instead of open/settle/finalize per call.Why it matters (consumer numbers, mainnet)
Per the consumer's own measurements, the channel leg is already fast (~2.7s open + settle + finalize incl. inference), and the deposit is fully refunded. Their per-call overhead is dominated by funding a fresh payer wallet per call, which a reused session channel removes. With a session, calls 2..N need no fresh open and no re-deposited ceiling, cutting both the per-call latency and the ~$1 float per in-flight request.
Sippar has offered to be the test traffic once a host advertises the session challenge.
Related: solana-foundation/pay-kit#212, solana-foundation/pay-kit#175 (payment-channel v1 profile).