How to share a Stripe API key with a developer safely
A concrete guide to handing a Stripe restricted key to a developer or contractor without Slack, email, or screenshots. Plus what to rotate when they leave.
Quick answer. To share a Stripe API key with a developer safely: (1) generate a restricted key in Stripe Dashboard (never share your secret key), (2) scope it to the minimum permissions the developer needs (e.g., charges:read for a reporting tool), (3) store the restricted key in a zero-knowledge shared vault, (4) grant the developer per-vault access, (5) when they leave, revoke vault access AND rotate the restricted key on Stripe’s side. The vault prevents leakage; the rotation closes the cached-credential gap. Free with LitePassword for the first user.
Why you should never share your Stripe Secret Key
The Stripe Secret Key (sk_live_...) has full account access — it can create charges, refund money, change settings, delete customers. Sharing it with a developer is functionally the same as giving them your bank password.
What you actually want to share is a restricted key (rk_live_...), which you scope to specific resources and permissions.
Step-by-step: generating a restricted key
- Stripe Dashboard → Developers → API keys → “Create restricted key”.
- Give it a descriptive name like “Acme analytics dashboard read-only”.
- Pick the resources the developer needs and set each to None / Read / Write. For a reporting tool: Charges + Customers + Invoices at Read.
- Click Create. Copy the
rk_live_...value — it shows once.
Where to put the key (not Slack)
This is the critical step. The restricted key is still sensitive — anyone with it can read your Stripe data within the scope you granted.
The wrong places:
- ❌ Slack DM (“here’s the key: rk_live_abc…”)
- ❌ Email (“see attached, password is 1234”)
- ❌ Shared Google Doc
- ❌ Screenshot in any messaging app
The right place: a zero-knowledge shared vault. The key is encrypted on your device, the developer decrypts it on theirs, and the vendor (Stripe, the password manager, anyone) cannot read it in between.
In LitePassword:
- Create or open the “Production credentials” shared vault.
- Add a new secret of type Password. Name it “Stripe — restricted key (Acme analytics)”.
- Paste the
rk_live_...value into the password field. Add a Note describing what it can do. - Save.
- Open Users → Manage Vault Access on the developer’s row. Toggle on Production credentials.
They sign in, decrypt the vault, copy the key into their tool. The value never enters Slack, email, or any channel that keeps a copy.
When the developer leaves: the two-step revoke
This is the part most teams miss. Revoking access in the password manager is necessary but not sufficient.
Step 1 — Revoke vault access in LitePassword. Users page → Revoke Access on their row (or use Manage Vault Access to remove just specific vaults). The vault key rotates automatically. Their cached ciphertext (if any) becomes undecryptable.
Step 2 — Rotate the restricted key in Stripe. Stripe Dashboard → API keys → click the key → Roll. The old key becomes invalid immediately. Generate a new one, put it in the vault, grant access to whoever needs it now.
Why both? Because step 1 closes the password-manager leakage path. Step 2 closes the literal-credential-they-knew path. The developer might still remember the value of the key from when they last copied it. Rotation makes that memory worthless.
Per-key restrictions worth setting
When you create the restricted key, also set:
- IP allowlist if the developer has a static IP. Stripe lets you scope a key to specific IPs. Combined with vault sharing, this means the key only works from the developer’s known IP.
- Read-only on everything except what they edit. Most reporting work is Read on everything. Set Write only where they truly need to write.
- Short rotation cadence. Rotate every 90 days even if nothing’s changed. Cheap; closes the slow-leak attack window.
Summary
- Generate a Stripe restricted key, not the secret key.
- Scope to minimum permissions + IP allowlist.
- Store in a zero-knowledge shared vault. Never in Slack.
- Grant per-user vault access.
- When they leave: revoke vault access + rotate the key on Stripe.
The same pattern works for AWS IAM users, GitHub PATs, and any other restricted-token style credential.