Claimable sandboxes: Frictionless Stripe accounts for agents
- Source
- stripe.dev
- Author
- Mathew Varughese
- Date

Context
Stripe now gives out working test accounts without a sign-up, because a coding can build a payment integration in minutes and signing up had become a noticeable delay. A claimable is a full Stripe sandbox, the isolated test environment with test API keys that normally comes after registering, created without an account. The user registers only once the integration works, and the sandbox, with its test payments and other objects, is attached to a new or existing account. Stripe's engineering post, by Mathew Varughese, says it designed this with platforms such as Vercel, Replit and Lovable, and offers it through an API for those platforms, in Stripe's docs, and as a CLI command, stripe sandbox create, built for agents.
Most of the post is about handing out free, unauthenticated keys, served by Stripe's production infrastructure at more than 50,000 sandboxes a day, without adding latency, piling up cost or inviting abuse. Sandboxes come from a pool created in advance, so requests don't wait the few seconds provisioning takes, and unclaimed ones are deleted after a set time so test data doesn't pile up. The CLI and API require an email address, which Stripe shows during the claim to make phishing with collected sandboxes harder, and the keys are a new type with their own rate limits. The CLI couldn't use a browser captcha, so it must solve a proof-of-work puzzle: the server sends a random salt and a hash of that salt combined with a secret number, the CLI tries numbers until one produces the same hash, and the server checks the answer. A larger secret number takes longer to find, and Stripe raises it based on server load and fraud signals tied to the email, which slows bulk requests without a pop-up. Stripe reports that thousands of users a day turn a sandbox into a real account and that more than 100,000 businesses have started this way.
- A claimable sandbox is a working Stripe test environment with test API keys and no registration. The user or their agent builds and tests the integration first, then claims it by signing up or linking an existing account, and earlier objects and API activity carry over.
- Provisioning a sandbox takes a few seconds, so Stripe keeps a pool of pre-created sandboxes refilled by a scheduled Temporal workflow. The pool is partitioned by country, use case and developer platform, and each partition has its own rate limits.
- Unclaimed sandboxes expire after a set TTL and a Temporal sweeper deletes them and their data. Stripe says creating sandboxes is cheap; the cost is storing an unbounded amount of test data indefinitely for accounts no real user owns.
- The CLI cannot show a browser captcha, so Stripe has it solve a proof-of-work puzzle: brute-force a secret number whose hash with a server-supplied salt matches a challenge. The server raises the difficulty based on load and on fraud signals tied to the supplied email.
- Other abuse controls: a dedicated API key type with its own rate-limit tier, per-provider pool partitions so one partner cannot drain the pool, and a required email for API and CLI sandboxes, shown at claim time to blunt phishing with collected sandboxes.
Checking sign-in…
Loading comments…

