Loading...
Loading...
Send Stripe publishable and secret keys securely during development handoffs.
Stripe credentials come in a zoo of prefixes, each with a different blast radius. The publishable key (pk_live_, pk_test_) ships in browser bundles. The secret key (sk_live_, sk_test_) authorizes any Charges, Refunds, Payouts, or Customers call. Restricted keys (rk_live_, rk_test_) carry a per-resource permission matrix you configure in the Dashboard. Webhook signing secrets (whsec_) are a separate primitive — they sign payloads Stripe POSTs to your endpoint, and developers regularly paste them into the same Slack thread as sk_live_ values by mistake.
Pasting these into Teams, Notion, or a tracked email thread is concretely hazardous. Stripe's incident response assumes leaked sk_live_ values are exploited within minutes — they scan public GitHub, npm tarballs, and pastebin mirrors and roll your key automatically when spotted. That auto-roll is useless for private leaks: a key in a Jira comment is invisible to those scanners. The Dashboard's keys page shows last-used timestamps but not who used the key.
PasteOnce fits the moment a Stripe credential has to leave the Dashboard's reveal modal and arrive in a teammate's terminal or .env file. You copy from dashboard.stripe.com/apikeys, encrypt in the browser, send a one-time link, and the recipient pastes the value into Doppler or their CI provider. Pair it with the restricted-key flow rather than the unrestricted secret-key flow, and Roll Key the moment the handoff completes.
Client-side encrypted. We can't see your data.
Your data is encrypted in your browser before it leaves your device.
Messages are automatically deleted after being read once.
We never see your data. Only encrypted blobs pass through our servers.
Links work exactly once. Refresh the page and it's gone forever.
Your sensitive data is encrypted in your browser using AES-256-GCM. The encryption key is generated randomly and never sent to our servers.
Only the encrypted blob is stored in our database, with an automatic expiration time. We literally cannot read your data.
When your recipient opens the link, the encrypted data is fetched and immediately deleted from our servers using an atomic Redis GETDEL. The key in the URL hash decrypts the message in their browser.
Open Developers > API keys > Create restricted key, then check only the resources the recipient needs (Read PaymentIntents, no access to Payouts). The rk_live_ value carries that matrix. Most contractor handoffs require five resources at most.
On dashboard.stripe.com/apikeys click Roll key, set an expiration of 1 hour on the old value, then confirm. The previous sk_live_ keeps working for that hour so you can swap it without downtime, and is dead afterwards.
If your recipient needs both the secret key and the webhook signing secret, deliver them through two PasteOnce links with separate hashes. Mixing them in one paste means a single intercepted link compromises both sides of your integration.
Note your Idempotency-Key header pattern (UUIDv4, 24-hour replay window) alongside the credential. A contractor who reuses keys without that convention can double-charge customers; the convention is part of the credential's safe-use envelope.
You hire an agency to build a subscription flow. Generate an rk_test_ with Write on PaymentIntents, Subscriptions, Customers, Prices, and Products only. Send the value with a 6-hour TTL. They drop it into Doppler; flip to a fresh rk_live_ at launch.
Your team is moving the /webhooks/stripe handler from Heroku to Vercel. The new endpoint needs the same whsec_ that signed events your old handler verified. Reveal it once on the Dashboard and paste it into Vercel's encrypted environment variables via a single link.
A partner needs read access to Charges across your Connect platform for reconciliation. Create an rk_live_ with Read on Charges and BalanceTransactions only, no Connect-application access. Send the key plus the relevant acct_ list with a 24-hour TTL, and revoke when the report ships.
A regular sk_live_ has full account permissions. An rk_live_ has a permission matrix you set when creating it, with three levels per resource: None, Read, Write. The rk_ prefix is the only visible difference; both authenticate the same way.
The pk_live_ ships in client bundles, so it is not technically secret. But pasting it alongside an sk_live_ in one Slack message defeats channel separation — handle pk_ values through PasteOnce too and the recipient never has to think about which prefix is safe where.
Only if it leaks somewhere Stripe's scanners can see — public GitHub repos, npm packages, public gists. Private channel leaks (Slack, Teams, wikis, Jira screenshots) are invisible. Roll Key yourself on the Dashboard for any uncertain handoff.
Use the vault for steady-state storage. Use PasteOnce for the one-shot delivery from the person revealing the value on dashboard.stripe.com to the person saving it into the vault. Vaults persist credentials; PasteOnce moves them between vaults.