Production Readiness Checklist
API Keys
- Use live keys for production only. Never use
zfi_test_keys in production orzfi_live_keys in development. - Store keys in a secrets manager. Use AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or your platform’s built-in secrets (Vercel, Railway, etc.).
- Never commit keys to version control. Add
.envto.gitignore. Use GitHub’s secret scanning to catch accidental commits. - Scope keys to minimum permissions. If a service only reads payments, give it a
payments_readkey instead offull_access. - Rotate keys on a schedule. Quarterly rotation is a reasonable baseline. Rotate immediately if compromise is suspected.
- Use separate keys per environment. Development, staging, and production should each have their own API key.
Webhooks
- Verify every signature. Use the SDK webhook handlers which do this automatically. If building a custom handler, follow the Webhook Security guide.
- Implement deduplication. Track processed event IDs to prevent double-processing if a webhook is retried.
- Use HTTPS endpoints. Required for production webhook delivery.
- Return 200 on receipt. Acknowledge the webhook immediately, then process asynchronously if the operation is slow.
- Set a webhook secret. Configure
ZENDFI_WEBHOOK_SECRETand do not reuse your API key as the webhook secret.
Network
- Enforce HTTPS everywhere. Your API, webhook endpoints, and frontend should all use HTTPS.
- Restrict CORS. In Express or similar frameworks, limit CORS origins to your frontend domain:
- Set security headers. Use Helmet.js or equivalent:
Payments
- Use idempotency keys. For every payment creation request, include an
Idempotency-Keyheader to prevent duplicate charges on network retries. - Validate amounts server-side. Never trust amounts from the client. Calculate pricing on the server.
- Use metadata for tracking. Attach order IDs, user IDs, and other references to payments via the
metadatafield. This makes reconciliation straightforward.
Application
- Keep the SDK updated. Run
npm update @zendfi/sdkregularly to pick up security patches. - Handle all error types. Implement error handling for
AuthenticationError,ValidationError,RateLimitError,PaymentError, andNetworkError. - Log appropriately. Log payment IDs, statuses, and error codes. Never log full API keys, webhook secrets, or customer PII in plaintext.
- Implement rate limiting on your endpoints. Even though ZendFi rate-limits API calls, you should also rate-limit your own customer-facing endpoints.
Environment Isolation
Test and live modes are completely isolated. Data created with a test key is invisible to live keys and vice versa. This isolation is enforced at the platform level — you cannot accidentally cross environments even if you misconfigure your application.Secrets Management Patterns
Per-Environment .env Files
Runtime Validation
Validate that required secrets exist at startup:Error Handling Strategy
Never expose internal details in error responses to your customers:Monitoring
Track these metrics to detect security issues early:| Metric | Alert Threshold | Indicates |
|---|---|---|
| Failed webhook verifications | > 0 | Possible spoofing attempt |
| 401 error rate | Spike above baseline | Key compromise or misconfiguration |
| 429 rate limit hits | > 50/hour | Abuse or integration bug |
| Payment failure rate | > 20% | Integration issue or attack |
| Unprocessed webhook events | Growing over time | Handler failure |
Dependency Security
Keep your supply chain clean:npm audit signatures to verify package provenance and tools like Socket or Snyk for continuous monitoring.
Incident Response Plan
Have a plan ready before you need it:- Detect: Monitor error rates, failed verifications, and unusual API activity.
- Contain: Rotate the compromised key immediately (
zendfi keys rotate <id>). - Assess: Check the audit log for unauthorized actions.
- Remediate: Update all services with the new key, patch the vulnerability.
- Review: Conduct a post-incident review and update procedures.