Stripe Security Checklist: 12 Things Most Integrations Get Wrong

These twelve items come directly from patterns we see repeatedly during security reviews — not a generic checklist copied from documentation.

1. Secret keys committed to version control history, even if later removed
2. Publishable key used where a secret key operation was actually needed
3. Webhook signature verification skipped or done against the wrong secret
4. Client-side code trusting amounts sent from the browser instead of the server
5. No idempotency keys on payment-creation requests
6. Test-mode keys left active in a production environment
7. Overly broad restricted API key permissions
8. No monitoring/alerting on webhook failures
9. Customer PII logged alongside Stripe object IDs unnecessarily
10. No rate limiting on public-facing payment-adjacent endpoints
11. Refund/cancellation endpoints missing authorization checks
12. Radar rules never reviewed after initial setup

Most of these are fast to fix once identified — the risk is in not knowing they exist until an audit (or an incident) surfaces them.