A payment gateway can be highly secure and still be integrated insecurely. In travel portals, integration mistakes can lead to tickets issued without payment, payments without tickets, or tampered amounts. This checklist covers the practices developers should follow when connecting a payment gateway to a travel booking engine.
1. Let the gateway handle card data
- Use the gateway's hosted checkout, redirect or secure fields, so card numbers never touch your servers.
- Never log or store full card numbers or CVV.
- Use tokens provided by the gateway for saved payment methods.
Keeping card data out of your systems greatly reduces your security and compliance burden.
2. Create the order on the server
The amount to charge must be calculated on your server from the booking, not taken from the browser. Create a payment order through the gateway's server-side API with the exact amount and currency, and link it to your booking ID.
3. Verify every payment response
- Never trust a "payment successful" redirect alone; it can be faked.
- Verify the gateway's signature on callbacks and webhooks using your secret key.
- Confirm the payment status with the gateway's API before issuing a ticket.
- Check that the amount and currency paid match the booking exactly.
4. Use webhooks for reliability
Customers close browsers, lose connections and get stuck on bank pages. Webhooks let the gateway notify your server directly when a payment succeeds, fails or is refunded, so bookings are completed even if the customer never returns to your site.
5. Make processing idempotent
Gateways may send the same webhook more than once. Your code should recognise a payment it has already processed and not issue a second ticket or a second wallet credit. Store gateway payment IDs with a unique constraint and check them before acting.
6. Handle the payment-to-ticketing handover
- Issue tickets only after payment is verified.
- If ticketing fails after payment, alert operations and start a retry or refund flow.
- If a payment confirms after the booking expired, refund automatically.
7. Protect secrets and access
- Store API keys and webhook secrets in environment configuration, never in code repositories.
- Use separate keys for test and live environments.
- Restrict admin access to refunds and payment settings, with audit logs.
- Rotate keys if a leak is suspected.
8. Log and monitor
- Log payment requests, responses and webhooks with sensitive data masked.
- Alert on spikes in failures, mismatched amounts or unusual refund activity.
- Reconcile gateway settlements with bookings daily.
9. Test failure scenarios
- Payment success, failure, cancellation and timeout.
- Duplicate webhooks.
- Tampered amounts and invalid signatures.
- Full and partial refunds.
In practice: catching a tampered amount
During a security review, a tester changed the amount in the browser before redirecting to the gateway and paid a much smaller sum. Because the portal created orders server-side and compared the paid amount with the booking total before ticketing, the booking was flagged and no ticket was issued. Without that check, the tester would have received a ticket for a fraction of its price.
Frequently asked questions
Do we need PCI DSS certification?
Requirements depend on how you handle card data. Using hosted checkout from a compliant gateway, and never touching card numbers, usually reduces your obligations significantly. Confirm specifics with your gateway.
Should we support saved cards?
Only through the gateway's tokenisation, which stores card details with the gateway and gives you a token to reuse.
Key takeaways
- Keep card data with the gateway and calculate amounts on the server.
- Verify signatures, statuses and amounts before issuing tickets.
- Use idempotent webhook handling, protected secrets and active monitoring.
Our payment gateway integration follows these practices for every travel portal we build.
