Skip to Content
Security Checklist

Security Checklist

This checklist covers security best practices for merchants integrating with Gatelithix. The gateway is designed for PCI DSS 4.0.1 Level 1 service provider posture — following these guidelines ensures your integration maintains the smallest possible PCI scope.

API Key Security

  • Never expose secret keys in client-side code. Keys prefixed sk_test_ and sk_live_ are secret. They must only be used in server-side code.
  • Use publishable keys for client-side tokenization. Keys prefixed pk_test_ and pk_live_ are safe for browser JavaScript and mobile apps. They can only create tokens.
  • Store keys in environment variables or a secret manager. Never hardcode API keys in source code or commit them to version control.
  • Use separate test and live keys. Never test with live keys. Sandbox keys (sk_test_, pk_test_) ensure no real charges are created.
  • Rotate keys periodically. Generate new keys and revoke old ones via the dashboard . Rotate immediately if a key is compromised.
  • Restrict key access. Limit which team members and systems have access to live secret keys.

PCI Scope Reduction

Gatelithix is designed to minimize your PCI compliance burden. When you use tokenization correctly, card data never touches your servers.

The safe pattern:

  1. Client-side: Use Hosted Fields or the publishable key to tokenize the card in the browser. The raw card number goes directly to the Gatelithix vault.
  2. Server-side: Use the returned gateway token (tok_test_... or tok_live_...) for all payment operations. Your server never sees the card number.

What this means for PCI compliance:

  • Your servers are out of PCI scope for card data storage and transmission.
  • You only handle gateway tokens, which are not considered cardholder data.
  • Gatelithix manages encryption, vault storage, and PCI compliance for the card data.

Request Security

  • Always use HTTPS. The API rejects plain HTTP requests. Ensure all API calls use https://.
  • Include Idempotency-Key on all write operations. This prevents duplicate charges from network retries. Use a UUID for each unique request.
  • Validate webhook signatures. Before processing any webhook event, verify the X-Paylithix-Signature header using HMAC-SHA256 with your webhook signing secret.

See Webhooks for the complete signature verification guide including timestamp tolerance.

Logging Restrictions

  • Never log full card numbers. PANs, CVVs, and expiry dates must not appear in your application logs.
  • Never log API secret keys. Treat sk_test_ and sk_live_ keys as passwords.
  • Safe to log: Gateway tokens (tok_test_...), payment intent IDs, X-Request-Id values, amounts, and statuses.
  • Mask card data if displayed. If you show card info to users, display only the last 4 digits (e.g., **** **** **** 4242). The API provides last4 and bin fields for this purpose.

Monitoring

  • Track X-Request-Id values. Log the request ID from every API response for correlation and debugging.
  • Monitor rate limit headers. Watch X-RateLimit-Remaining to proactively throttle before hitting limits.
  • Set up webhook endpoint health monitoring. Monitor your webhook endpoint’s response times and error rates.
  • Review the dashboard regularly. Check dashboard.gatelithix.com  for API key activity, payment metrics, and webhook delivery status.

Next Steps

Payment RoutingPCI Compliance