Overview
CrediBill implements production-grade security measures. This guide explains the security features and best practices for integrating with CrediBill.Authentication & API Keys
API Key Types
CrediBill uses different API keys for different purposes:| Key Type | Prefix | Usage | Security |
|---|---|---|---|
| Secret Key | cb_ | Server-to-server API calls | Keep secret, never expose |
| Publishable Key | pk_ | Client-side operations | Safe to expose in frontend |
| Webhook Secret | whsec_ | Verify webhook signatures | Keep secret, rotate periodically |
API Key Security
Never commit API keys to version control:- Go to Settings → API Keys
- Click Regenerate next to key
- Update your app with new key
- Delete old key
- Monitor for failed requests
- After accidental exposure: Immediately
- Regular rotation: Quarterly
- After employee departure: Immediately
- After suspected compromise: Immediately
Using API Keys
Webhook Security
Signature Verification
All webhooks must be verified. This prevents attackers from forging webhook events.Verification Implementation
Common Signature Verification Mistakes
Replay Attack Prevention
CrediBill includes built-in replay attack prevention through:- Timestamp validation: Reject webhooks older than 5 minutes
- Event ID deduplication: Track processed event IDs
- Nonce tracking: Prevent reusing old webhooks
Credential Management
Encrypted Storage
All payment provider credentials are encrypted using AES-256-GCM:Best Practices for Credentials
Never log credentials:- Go to provider dashboard
- Generate new API credentials
- Update in CrediBill settings
- Rotate out old credentials
- Delete old credentials from provider
Transaction Security
Race Condition Prevention
CrediBill prevents race conditions where multiple webhooks update the same transaction:Idempotency
Every payment operation should be idempotent. Include anIdempotency-Key header on server-side requests.
Data Protection
Data Retention
CrediBill retains data according to:- Transaction records: 7 years (regulatory requirement)
- Webhook logs: 90 days
- Customer data: Until account deletion
- Payment method tokens: Until removed by customer
PCI Compliance
CrediBill is PCI DSS compliant:- ✅ Never stores raw card numbers
- ✅ Encrypted transmission (TLS 1.2+)
- ✅ Secure credential storage (AES-256-GCM)
- ✅ Access logging and monitoring
- ✅ Regular penetration testing
- ✅ Never accept raw card data on your server
- ✅ Use CrediBill’s tokenization for cards
- ✅ Don’t log or store card numbers
- ✅ Use HTTPS for all communication
- ✅ Validate SSL certificates
Network Security
TLS/HTTPS
All CrediBill endpoints require HTTPS. Verify TLS by making requests overhttps:// and ensuring your server enforces HTTPS for webhook endpoints.
TLS Certificate Validation
Monitoring & Alerting
Security Events to Monitor
Audit Logging
Access Control
Role-Based Access
Implement role-based access control:API Key Scoping
Incident Response
If Credentials Are Compromised
- Immediately revoke the exposed key/credential
- Generate new key/credential
- Update all applications with new credentials
- Review logs for unauthorized usage
- Monitor for suspicious activity
- Contact provider to revoke provider credentials if exposed
- Document the incident
If Payment Data Is Exposed
- Assess scope: Which data was exposed?
- Notify users: If PII/payment method exposed
- Contact CrediBill: Report the incident
- Enable monitoring: Watch for fraudulent activity
- Review logs: Understand how exposure occurred
- Implement fixes: Prevent recurrence
If Webhooks Are Being Spoofed
- Verify signature: Ensure proper verification
- Check logs: Look for pattern of invalid signatures
- Check IP source: See where invalid webhooks come from
- Block IP: Add to firewall if needed
- Rotate webhook secret: Generate new secret
- Update endpoint: If verification code has bug
Compliance
Supported Standards
CrediBill complies with:- PCI DSS 3.2.1: Payment Card Industry Data Security Standard
- GDPR: General Data Protection Regulation (EU)
- CCPA: California Consumer Privacy Act
- HIPAA: Health Insurance Portability (if applicable)
- SOC 2 Type II: Service Organization Control
Your Compliance Responsibilities
Privacy:- ✅ Collect customer data with consent
- ✅ Provide privacy policy
- ✅ Allow data deletion (GDPR right to be forgotten)
- ✅ Handle data breaches
- ✅ Keep PII secure
- ✅ Never store raw card numbers
- ✅ Use tokenization for cards
- ✅ Maintain HTTPS
- ✅ Validate SSL certificates
- ✅ Log and monitor access
- ✅ Maintain transaction records (7 years)
- ✅ Keep audit logs
- ✅ Reconcile with provider regularly
- ✅ Report suspiciously large transactions
- ✅ Comply with local regulations
Security Checklist
Before going to production:Setup
- All credentials in environment variables (not hardcoded)
- API keys rotated (first time setup)
- Webhook secret saved securely
- HTTPS enabled on webhook endpoint
- SSL certificate valid (not self-signed)
Code
- Webhook signature verification implemented
- Timing-safe comparison used
- Timestamp validation implemented
- Replay attack prevention in place
- Idempotency keys used for payments
- Error messages don’t expose credentials
- Logging doesn’t log sensitive data
Monitoring
- Invalid webhook attempts logged
- Failed API auth attempts monitored
- Security alerts configured
- Audit logs enabled
- Payment anomalies monitored
Operational
- Key rotation plan documented
- Incident response plan documented
- Team training completed
- Backup credentials stored securely
- Regular security reviews scheduled