LakiConnect
Security best practices
API Key Management
- Store API keys in a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager). Never commit them to source control.
- Use separate keys for sandbox and production environments.
- Rotate keys periodically and immediately upon personnel changes or suspected compromise.
- Restrict each key to the minimum RBAC permissions required.
Webhook Security
- Always configure a
webhook_secretand verifyX-LakiConnect-Signatureon every inbound webhook request. - Use
crypto.timingSafeEqual(or equivalent) for signature comparison to prevent timing attacks. - Process webhooks idempotently using
idempotency_keyto handle at-least-once delivery. - Validate that the
master_merchant_idin the webhook payload matches your expected value before acting. - Return
HTTP 200promptly; perform heavy processing asynchronously to prevent timeout-induced retries.
Idempotency
Use unique, deterministic idempotency keys for all payment creation requests (e.g., order-{order_id}-attempt-{n}). This prevents duplicate transactions in the event of network failures or client-side retries.
Transport Security
- All API communication must use HTTPS (TLS 1.2+). Never make API calls over plain HTTP.
- Webhook endpoints must be HTTPS.
- Validate TLS certificates; do not disable certificate verification in production.
PCI & Data Handling
- LakiConnect tokenizes card data server-side. Do not log or store raw card numbers in your application.
- Minimize PII stored on your platform. Use LakiConnect-provided identifiers rather than duplicating sensitive personal data.
- Review your integration annually for compliance with applicable payment security standards.
Production Deployment
- Apply network-level access controls to restrict which services can call the LakiConnect API from your infrastructure.
- Use separate service accounts or IAM roles for each application component that needs API access.
- Enable alerting for unexpected 401/403 response rates, which may indicate key exposure or RBAC misconfiguration.