Live demo

Payments for travel bookings

Travel payment gateway integration that keeps every payment tied to its booking

Connect your booking website or B2B portal to the payment providers your customers use. Checkout happens inside the booking flow, 3D Secure runs where the card requires it, and every authorization, capture, refund and webhook is stored against the booking reference your team works with.

  • Checkout inside the booking flow
  • Multi-currency where your provider allows
  • 3D Secure and tokenized cards
  • Voids, refunds and reconciliation

Secure travel checkout

Travel payment gateway integration inside your booking flow

Customers pay for flights, hotels, tours and transfers on your own checkout page, not through a disconnected payment link. The booking system sends the amount, currency and booking reference; the gateway returns a result the booking can act on.

The same flow serves Flight booking software, Hotel booking engine and Tour operator software: the booking is held, payment is taken, and the supplier confirmation follows only when the payment succeeds.

  • Multi-currency

    Present and settle the currencies your provider and merchant account support.

  • Secure authentication

    Tokenized cards, 3D Secure and the provider's own risk checks.

  • Traceable records

    Transactions, bookings, refunds and settlement references stay linked.

Booking paymentBookingPT-48213
  1. Details
  2. Payment
  3. 3D Secure
  4. Confirmed
Pay in
  • Flight, 2 adults$612.00
  • Hotel, 3 nights$438.00
  • Booking fee$15.00
Total to pay$1,065.00 USD
  • Flight, 2 adults€566.00
  • Hotel, 3 nights€405.00
  • Booking fee€14.00
Total to pay€985.00 EUR
  • Flight, 2 adults£486.00
  • Hotel, 3 nights£348.00
  • Booking fee£12.00
Total to pay£846.00 GBP

Card details go straight to your gateway

Sample amounts. Currencies, methods and fees depend on your gateway and merchant account.

Transaction lifecycle

How payment status and booking status move together

A travel payment is not finished when the card is approved. Pick a scenario to see what the gateway reports and what the booking does at each step.

Paid and confirmed

CapturedConfirmed
  1. 0100:00Booking sends amount, currency and reference to the gatewayPaymentPendingBookingOn hold
  2. 0200:04Gateway approves the card and holds the fundsPaymentAuthorizedBookingOn hold
  3. 0300:09Supplier confirms the bookingPaymentAuthorizedBookingConfirmed
  4. 0400:10Held funds are capturedPaymentCapturedBookingConfirmed
  5. 0500:11Signed webhook stored against the bookingPaymentCapturedBookingConfirmed

Capturing after the supplier confirms means the customer is never charged for a booking that does not exist.

3D Secure challenge

CapturedConfirmed
  1. 0100:00Booking sends amount, currency and reference to the gatewayPaymentPendingBookingOn hold
  2. 0200:03Bank requests a 3D Secure challengePaymentAction neededBookingOn hold
  3. 0300:41Customer completes verification and the payment is authorizedPaymentAuthorizedBookingOn hold
  4. 0400:46Supplier confirms the bookingPaymentAuthorizedBookingConfirmed
  5. 0500:47Held funds are capturedPaymentCapturedBookingConfirmed

The booking stays on hold while the customer verifies. If the challenge fails or times out, the hold is released and nothing is charged.

Price changed

CapturedConfirmed
  1. 0100:00Price revalidated with the supplier before chargingPaymentNot startedBookingOn hold
  2. 0200:02New price shown to the customer for approvalPaymentNot startedBookingRepriced
  3. 0300:30Customer accepts and a payment is created for the new amountPaymentPendingBookingRepriced
  4. 0400:34Gateway approves the card and holds the fundsPaymentAuthorizedBookingRepriced
  5. 0500:39Supplier confirms the bookingPaymentAuthorizedBookingConfirmed
  6. 0600:40Held funds are capturedPaymentCapturedBookingConfirmed

Revalidating before payment stops the agency from absorbing a fare or rate increase it never saw.

Supplier failed after payment

VoidedFailed
  1. 0100:00Booking sends amount, currency and reference to the gatewayPaymentPendingBookingOn hold
  2. 0200:04Gateway approves the card and holds the fundsPaymentAuthorizedBookingOn hold
  3. 0300:12Supplier rejects the bookingPaymentAuthorizedBookingFailed
  4. 0400:13Authorization voided before capture, so no chargePaymentVoidedBookingFailed
  5. 0500:14Customer and operations team notified with both referencesPaymentVoidedBookingFailed

Because the funds were only authorized, they are released with a void instead of a refund. Where the provider captures at once, the same step becomes a refund.

Illustrative sequence. Whether funds are authorized first or captured at once depends on the gateway and your settings.

Under the hood

Requests, webhooks and refunds that carry the booking reference

Every call to the gateway carries the booking reference and an idempotency key, and every event from the gateway is verified before it changes a booking.

  1. 1The booking reference travels as metadata, so the provider dashboard and your admin panel show the same booking.
  2. 2An idempotency key stops a double click or a network retry from charging twice.
  3. 3Amounts are sent in minor units with an explicit currency code.
  1. 1The signature is checked against your webhook secret before anything changes.
  2. 2The event type decides the booking action: confirm, release or flag for review.
  3. 3Repeat deliveries of the same event are recognized and ignored.
  1. 1Partial amounts cover cancellation charges kept by the agency or the supplier.
  2. 2The refund points at the original payment and at the cancelled booking.
  3. 3A reason code goes to the provider and into your records for support and disputes.

Providers that are not connected yet are handled as a Custom API integration. Popular gateways have their own pages: Stripe payments and PayPal payments.

POST /v1/paymentsIdempotency-Key: bk_PT-48213_a1{  "amount": 106500,  "currency": "USD",  "capture": "after_confirmation",  "metadata": {    "booking": "PT-48213",    "pnr": "X7K2LM"  }}
POST /webhooks/paymentsSignature: t=1791012345,v1=5f3ac1…{  "id": "evt_8841",  "type": "payment.captured",  "payment": "pay_3QK19",  "metadata": { "booking": "PT-48213" }}→ 200 OK  booking=PT-48213 status=confirmed
POST /v1/refundsIdempotency-Key: rf_PT-48213_1{  "payment": "pay_3QK19",  "amount": 41800,  "currency": "USD",  "reason": "cancelled_by_customer",  "metadata": {    "booking": "PT-48213",    "retained_fee": 2000  }}

Generic example. Field names follow the API of the gateway you choose.

Travel-specific operations

Payment controls for the things that go wrong in travel

Prices move, suppliers fail and customers cancel. Each control answers a situation that operations teams deal with regularly.

  • Situation01

    The hotel rate rose between search and payment.

    Control

    Price revalidation

    The latest supplier price is confirmed before the customer is charged, and any change is shown for approval.

  • Situation02

    The customer pressed Pay twice on a slow connection.

    Control

    Idempotent booking flow

    Repeated requests return the first result instead of creating a second charge or a second booking.

  • Situation03

    The customer pays in euros and the supplier invoices in dollars.

    Control

    Currency and markup rules

    Checkout currency, booking value, markup and settlement amount are each recorded.

  • Situation04

    Two nights of a five-night stay are cancelled.

    Control

    Voids and partial refunds

    Full or partial reversals are tied to the cancellation or amendment that caused them.

  • Situation05

    A cardholder disputes a charge months after travel.

    Control

    Disputes and chargebacks

    Provider events, authentication results and booking documents are kept together as evidence.

  • Situation06

    A webhook arrives for a booking that is already cancelled.

    Control

    Webhooks and alerts

    Verified events update bookings; anything that does not fit is flagged for a person to review.

Provider coverage

Choose a gateway for your market and customers

Availability depends on merchant approval, country coverage, currencies and payment methods. Many agencies combine a global card gateway with a regional provider and a B2B settlement option.

  • A

    Global card gateways

    Card acceptance, tokenization, 3D Secure, refunds and multi-market checkout.

  • B

    Regional providers

    Local currencies, domestic payment rails and market-specific methods.

  • C

    Digital wallets

    Faster checkout for customers who prefer an approved wallet account.

  • D

    B2B payment flows

    Agent credit, manual payment records and controlled payment workflows.

What each type usually covers
NeedAGlobal card gatewaysBRegional providersCDigital walletsDB2B payment flows
International cardsUsually coveredUsually coveredDepends on the providerNot the usual fit
Local methods and bank railsDepends on the providerUsually coveredDepends on the providerNot the usual fit
3D SecureUsually coveredDepends on the providerDepends on the providerNot the usual fit
Refunds and voidsUsually coveredDepends on the providerDepends on the providerUsually covered
Several currenciesUsually coveredDepends on the providerDepends on the providerDepends on the provider
Agent credit and depositsNot the usual fitNot the usual fitNot the usual fitUsually covered
  • Usually covered
  • Depends on the provider
  • Not the usual fit

Gateways in the integrations directory

These names come from the live All integrations. Merchant accounts and transaction fees are agreed with the payment company you choose.

Settlement without a gateway

  • Wallet balance
  • Bank transfer
  • Pay later

For agents and offline sales, bookings can also be settled from the B2B agent wallet, by bank transfer or as pay later, with each payment recorded by your team.

Project scoping

What we need to scope your payment integration

A clear provider account and transaction workflow let us define accurate scope, testing and delivery. Tick what you already have.

0/5ready

Scoping checklist

Path to go-live

  1. 01

    Sandbox keys

    The platform runs against the provider's test environment.

  2. 02

    Test cases

    Approve, decline, 3D Secure, void and refund, each against a test booking.

  3. 03

    Webhook endpoint

    Signatures verified and every event type mapped to a booking action.

  4. 04

    Production keys

    Live credentials switched on, with failed payments monitored.

Plan your checkout

Gateway work is scoped together with your booking platform. PHPTRAVELS is a one-time license with source code included, self-hosted on your own server; see Pricing for what each plan covers.

Try the demoTalk to us

Payments connect to

Buyer questions

Payment gateway integration FAQ

What agencies ask before adding online payments to their booking platform.

Talk to sales

It connects a travel booking website or portal to a payment provider, so customers pay during checkout and the booking system can securely track authorization, capture, refunds and payment status against each booking.

PHPTRAVELS supports a range of global and regional gateways, listed in the integrations directory. The right option depends on your country, merchant approval, currencies, payment methods and the provider API available for your account.

Yes, when the selected gateway and merchant account support the presentment and settlement currencies you need. Currency conversion, markup and settlement rules are confirmed during project scoping.

3D Secure is included when the provider supports it and it is enabled for your merchant account. The integration handles authentication results, redirects or embedded challenges, and the final payment status.

Yes, if the provider API supports them. Full or partial refunds, voids and cancellation charges are linked to the relevant booking and transaction references.

The payment company does. You open the merchant account with the provider you choose and agree its fees with them directly. PHPTRAVELS connects your platform to that account with the credentials you supply.

Keep exploring

More from the platform