Live demo

Travel payment API

Payment gateway API for travel bookings: from checkout to refund

A payment gateway API is how your booking site takes a traveller's money without ever touching the card. This page walks through the calls of one card payment, the statuses a payment moves through, what makes travel payments harder than retail, and how PHPTRAVELS connects your booking flow to the gateway you choose.

  • Session, 3-D Secure, capture
  • Every payment status
  • Cards, wallets, bank, credit
  • No card data on your server

How the calls work

One card payment, call by call

A payment gateway API is a set of web services a payment company opens to merchants. Your server asks it to create a payment for an amount and currency, the traveller enters the card on the gateway's own form, and the gateway talks to the card network and the issuing bank. Your server never sees the card number; it gets back a payment ID and a status.

Four parties take part. The diagram shows them as columns and every message as a numbered arrow. Names differ from one gateway to the next (payment intent, session, order, charge), but the sequence is the same.

A traveller paying for a trip online while a booking website, a payment gateway and a bank exchange payment messages

The dashed arrow is a webhook: the gateway calls your server on its own, so a payment still updates the booking if the traveller closes the browser. The Payment gateway integration page covers how each step is tied to a booking in PHPTRAVELS.

  • Traveller
  • Your site
  • Gateway
  • Card network / bank

  1. 01CheckoutTraveller Your site

    The traveller reviews the trip and presses Pay. The booking is held with the supplier, not yet confirmed.

  2. 02Create payment intent or sessionYour site Gateway

    Your server sends amount, currency, booking reference and an idempotency key with its secret API key. The gateway returns a payment ID.

  3. 03Hosted fields or redirectGateway Traveller

    The card form is served by the gateway, inside your page or on its own page, so card data goes straight to it.

  4. 043-D SecureCard network / bank Traveller

    If the issuing bank asks for it, the traveller confirms the payment in the banking app or with a one-time code.

  5. 05AuthoriseGateway Card network / bank

    The gateway asks the issuer to approve the amount through the card network.

  6. 06Approved, funds heldCard network / bank Gateway

    The issuer reserves the money on the card. Nothing has moved yet.

  7. 07Result to your siteGateway Your site

    The traveller returns to your site with the payment ID. Your server reads the status from the API and confirms the booking with the supplier.

  8. 08CaptureYour site Gateway

    Once the supplier confirms, your server captures the full or a lower amount. Many gateways can also capture at once.

  9. 09WebhookGateway Your siteSent by the gateway on its own

    The gateway posts a signed event (payment captured, refunded, disputed) to your endpoint. Your server checks the signature and updates the booking.

Payment statuses

The life of a payment as a state machine

Every gateway API reports a status for each payment. The words vary, but they map onto the same few states, and your booking logic should react to each one.

  1. created

    Created

    The payment exists with an amount and currency, waiting for the traveller.

    failedFinal

    Failed

    Declined, 3-D Secure not completed or abandoned. Nothing is charged.

  2. authorized

    Authorised

    The issuer approved the amount and is holding it on the card.

    voidedFinal

    Voided

    The hold is cancelled before capture, so the traveller is never charged.

  3. captured

    Captured

    The money is taken and will be settled to your merchant account.

    partially_refundedFinal

    Partially refunded

    Part of the captured amount is returned, for example after a cancellation fee.

    refundedFinal

    Refunded

    The whole captured amount is returned to the card.

An authorisation does not last forever: if it is not captured in time, the hold expires and the bank releases the money. A partially refunded payment can still be refunded further, up to the captured amount.

Why travel is harder

Why travel payments are different

A shop sells something it has in stock. A travel seller takes money for a booking a supplier still has to confirm, often months before the trip. The payment API has to fit that.

  • 01

    Authorise now, capture later

    On-request hotels, group fares and tours are confirmed hours or days after the order. Authorising first and capturing on confirmation means no charge for a booking that never happens.

  • 02

    The supplier can still say no

    A fare can sell out between payment and ticketing. With an authorisation the money is released with a void; after capture it becomes a refund.

  • 03

    Partial refunds after cancellation fees

    Cancelling a stay or a ticket usually keeps a fee. The refund call sends a lower amount against the original payment, as often as the rules require.

  • 04

    Multi-currency

    Travellers pay in their currency while suppliers invoice in theirs. The gateway must support the presentment currency, and your records must keep both amounts.

  • 05

    High-value fraud checks

    Tickets for tomorrow, for someone else, paid with a new card are a classic fraud pattern. 3-D Secure, the gateway's risk scoring and a manual review queue protect high-value orders.

  • 06

    Chargebacks months later

    Disputes often arrive after travel. Keep the authentication result, the booking documents and the gateway events together, so you can answer one with evidence.

Payment methods

Which ways to pay a payment gateway API covers

Cards are only one option. Travellers and agents pay in different ways, and each one is refunded differently.

MethodWhat it isWhen the money arrivesRefunds
CardsDebit and credit cards through the gateway, with 3-D Secure where the issuer requires it.Authorised at checkout; captured at once or when the supplier confirms.Full or partial refund to the same card through the API.
Digital walletsWallet accounts the gateway supports, such as PayPal or a phone wallet holding a tokenised card.At checkout, after the traveller approves in the wallet.Back to the wallet or the card behind it, through the gateway.
Bank transferThe traveller or agent sends money to your bank account and the payment is recorded against the booking.Days later; the booking waits until your team confirms receipt.Paid back by transfer, outside the gateway.
Pay laterThe booking is made now and paid later; your team records the payment when it arrives.After the booking, when the traveller pays.Only what was actually paid is returned.
B2B agent wallet or creditSub-agents pay from a balance they fund in advance or from a credit limit you grant.Deducted at booking; deposits and credit settled on your terms.Credited back to the agent balance.

Bank transfer, pay later and wallet balance are settlement options of the platform itself, not gateways. Agent balances and credit limits are explained on the B2B agent wallet page; bank payments on the Bank transfer payments page.

Ready in PHPTRAVELS

Payment gateway APIs already connected

These gateways are already connected to PHPTRAVELS. You open a merchant account with the provider, enter your API keys in the admin, test in its sandbox and go live. The list is the live one from our integrations directory.

Fees and merchant approval are agreed with the payment company, not with PHPTRAVELS. A gateway that is not here can be added as a Custom API integration, and the Payment gateway integration page explains how each one is set up.

Security

Keeping card data out of your system

The safest card number is the one your server never receives. A payment gateway API is built so it does not have to.

  • Never store card numbers

    Card details go to the gateway, which returns a token or a payment ID. Your database keeps that reference, never the card number or security code.

  • Hosted fields and redirects reduce PCI DSS scope

    PCI DSS applies to anyone who handles card data. When the card form is the gateway's own page or embedded fields, much less of your system is in scope. Your acquirer confirms which self-assessment applies to you.

  • Webhooks verified by signature

    Each webhook carries a signature made with a shared secret. Your server recomputes it and rejects any event that does not match, so nobody can fake a paid booking.

  • Secret keys stay on the server

    The browser only gets a publishable key. The secret key that creates payments and refunds lives in your server configuration, and each request carries an idempotency key so a retry never charges twice.

webhook.php
 1$payload   = file_get_contents("php://input"); 2$signature = $_SERVER["HTTP_X_SIGNATURE"] ?? ""; 3$expected  = hash_hmac("sha256", $payload, $webhookSecret); 4 5if (!hash_equals($expected, $signature)) { 6    http_response_code(400); exit;      // reject 7} 8$event = json_decode($payload, true); 9if (alreadyHandled($event["id"])) exit; // repeat delivery10updateBooking($event["data"]["metadata"]["booking_ref"], $event["type"]);

Generic example. Header names and the signing method follow the gateway you choose.

PHPTRAVELS is self-hosted software, so PCI DSS compliance is assessed for your business and your server, not for the software alone.

See a booking paid, captured and refunded

Book a trip in the live demo and follow the payment in the admin. On the Enterprise plan, PHPTRAVELS also gives you its own REST API and webhooks for your apps and partners.

Planning flights too? The Flights API page explains the supplier side, and Travel APIs lists every API PHPTRAVELS connects.

Try the live demoCompare plansRead the developer documentation

FAQ

Payment gateway API: questions travel sellers ask

Talk to sales

It is a set of web services a payment company provides so a website can create payments, send the card to the bank for approval, capture the money, issue refunds and receive status updates by webhook, without storing card data itself.

The gateway is the part your website talks to: it collects the card securely and passes the request on. The processor moves the transaction through the card networks to the issuing bank. Many providers offer both as one service.

The one that approves your business, supports your customers' countries, currencies and payment methods, and offers separate authorise and capture plus partial refunds. Many agencies combine a global card gateway with a regional one.

Authorising reserves the amount on the traveller's card; capturing takes it. Splitting the two lets you charge only once the supplier confirms the booking, and void the hold if it does not.

In many regions, including the European Economic Area and the UK, strong customer authentication is required for most online card payments, and 3-D Secure is how cards meet it. The gateway API handles the challenge; your booking flow waits for the result.

Not by itself. Using the gateway's hosted fields or payment page keeps card data off your server and reduces your PCI DSS scope, but you still complete the assessment your acquirer asks for.

Yes, if the gateway supports partial refunds, which most card gateways do. You send a refund for a lower amount against the original payment, for example the price minus a cancellation fee.

No. You open a merchant account with the gateway you choose and agree its fees with them. PHPTRAVELS connects your booking platform to that account with the API keys you enter in the admin.

Yes. Any gateway with a documented API can be added as a custom integration, and because the source code is included, your developers can extend the payment flow too.

Keep exploring

More from the platform