Security
Your keys
Section titled “Your keys”| Key | Can | Belongs |
|---|---|---|
Publishable (pk_…) |
Open the sheet for a payment your server created | In your app or website |
Secret (sk_…) |
Create payments, cancel them, refund them | Only on your server |
Webhook signing secret (whsec_…) |
Prove an event came from Stack | Only on your server |
- The SDKs refuse a secret key in an app, and
@usestack/noderefuses a publishable key. - Roll key in the dashboard replaces the secret key and turns the old one off immediately. Do it straight away if a secret key leaks.
What your app never sees
Section titled “What your app never sees”- Card numbers. Card details go from the sheet to Stack and on to our payment processor. They aren’t stored or logged, and your app and server never touch them.
- The customer’s PIN or sign-in code.
- Other payments. A
client_secretopens one payment, only with your publishable key.
How payments are protected
Section titled “How payments are protected”- Every payment needs a second step besides being signed in: the sign-in code on a first payment, then Face ID or a fingerprint on a phone, or the Stack PIN.
- Device keys are created in the phone’s Keychain or Keystore behind biometrics. They sign each payment and never leave the device.
- Wrong PINs and codes lock out. Five wrong PINs lock the PIN for 15 minutes. Five wrong guesses at a code make that code useless, and the customer needs a new one.
- Webhooks are signed with your signing secret and timestamped, so they can’t be forged or replayed. See verifying webhooks.
Your side
Section titled “Your side”- Create payments on your server, with prices your server works out.
- Fulfil from the webhook, after checking the signature and the amount.
- Keep secrets in environment variables, never in source control.