Live demo

Payments for travel software

Paddle API integration: when a merchant of record fits a travel business

Paddle sells software, SaaS and digital products on your behalf as the merchant of record. That makes it a strong fit for a travel technology company billing its own subscriptions, and usually the wrong tool for taking money for flights, hotels and tours. This page explains the difference, how a Paddle integration works, and how to connect it to PHPTRAVELS when your use case fits.

  • Merchant of record, not a gateway
  • Built for software and subscriptions
  • Signed webhooks
  • Connected as a custom integration

Two different models

Merchant of record vs payment gateway

A payment gateway moves money for you: you are the seller, the payment company processes the card, and tax, invoices, refunds and disputes stay your responsibility. A merchant of record goes one step further and becomes the seller in the eyes of the customer and the tax authorities. When someone buys through Paddle, Paddle sells to them, collects and remits the sales tax or VAT, issues the invoice, handles chargebacks and then pays your share out to you.

That model saves a software company a great deal of tax and compliance work, but it also means Paddle decides what it is willing to resell. Its platform is built for software, SaaS and digital products, not for travel services delivered by airlines, hotels and tour operators. The general mechanics of card payments are covered on the Payment gateway API page.

A payment flow diagram showing a customer paying online while payment, tax and payout responsibilities pass between a seller and a payment provider
QuestionPaddle (merchant of record)Payment gateway
Who is the seller?Paddle is the seller of record. The customer's receipt and card statement come from Paddle's side of the sale.You are the seller. The gateway only processes the payment on your merchant account.
Who handles sales tax and VAT?Paddle calculates, collects and remits sales tax and VAT in the places it sells to.You do, through your own tax registrations, accountant and invoicing.
Who issues the invoice?Paddle issues the invoice or receipt to the buyer.Your own system issues it, for example the booking invoice in your admin.
Who handles chargebacks?Paddle deals with disputes and chargebacks as the seller.You answer disputes with evidence through the gateway's dashboard or API.
What can you sell?Software, SaaS, subscriptions and digital products, within Paddle's acceptable-use rules.Physical and service sales the gateway approves, including travel bookings for many travel merchants.
How do you get paid?Paddle pays out your earnings after its fees, on its payout schedule.Captured payments settle to your merchant or bank account, minus the gateway's fees.

Fees, supported countries and the exact list of allowed products are set by Paddle and change over time. Check Paddle's own terms before you plan on it.

Decision helper

Is Paddle right for what you sell?

Start from what the customer is paying for. Pick the scenario closest to your business.

01

Travellers pay for flights, hotels and tours

The customer is buying a trip that an airline, hotel or tour operator delivers. Payments often need authorise now and capture later, partial refunds after cancellation fees and multi-currency checkout.

Our view

Use a payment gateway

Check Paddle's acceptable-use rules before using it for travel bookings. Most travel businesses take booking payments through a payment gateway such as Stripe, PayPal, Adyen or a regional gateway.

02

You sell your own travel software or SaaS

You are a travel technology vendor and agencies pay you a monthly or yearly subscription for your booking tool, API access, a plugin or a white-label portal.

Our view

Paddle can fit

This is the kind of sale a merchant of record is built for: Paddle bills the subscription, handles the tax in each country and pays you out, so you do not register for VAT everywhere your customers are.

03

You sell bookings and software

Your agency runs a booking site for travellers and also licenses its platform or tools to other agencies.

Our view

Use both, kept apart

Take booking payments through a ready gateway in the booking flow, and bill the software subscriptions through Paddle. Two flows, two sets of records, each with the right tax treatment.

How it works

How a Paddle integration works, end to end

Paddle Billing works with products and prices you create in Paddle, a checkout opened by Paddle.js, and webhooks that tell your server what happened.

  1. 01

    Products and prices

    You create each plan once in Paddle, for example a monthly and a yearly price, and keep the price IDs in your system.

    pri_…
  2. 02

    Paddle.js checkout

    Your page loads Paddle.js and opens the checkout as an overlay or inline frame with the price ID and your own customer reference.

    Paddle.Checkout.open()
  3. 03

    Transaction completed

    The buyer pays, Paddle charges the card or wallet, applies tax and creates a transaction, and a subscription when the price recurs.

    txn_…
  4. 04

    Signed webhook

    Paddle posts an event such as transaction.completed to your endpoint, signed in the Paddle-Signature header.

    transaction.completed
  5. 05

    Your system acts

    Your server verifies the signature, then activates the account, renews the plan or records the payment.

    200 OK

Keep the API key on your server only. The browser uses a separate client-side token, and the sandbox and live environments each have their own keys, prices and webhook secrets.

Webhook security

Checking the Paddle-Signature header

A webhook can be faked by anyone who knows your endpoint URL. Verifying the signature on every event is what makes it safe to activate an account from a webhook.

paddle-webhook.php
 1$raw    = file_get_contents("php://input"); 2$header = $_SERVER["HTTP_PADDLE_SIGNATURE"] ?? "";  // ts=…;h1=… 3parse_str(str_replace(";", "&", $header), $sig); 4 5$expected = hash_hmac("sha256", $sig["ts"] . ":" . $raw, $endpointSecret); 6if (!hash_equals($expected, $sig["h1"] ?? "")) { 7    http_response_code(400); exit;            // not from Paddle 8} 9if (time() - (int) $sig["ts"] > $tolerance) exit; // too old1011$event = json_decode($raw, true);12if (alreadyHandled($event["event_id"])) exit;      // repeat delivery13if ($event["event_type"] === "transaction.completed") {14    activatePlan($event["data"]["custom_data"]["account_id"]);15}16http_response_code(200);

Illustrative example in plain PHP. Follow Paddle's current documentation, or its official SDK, for the exact format.

  1. 01

    Use the raw body

    The signature is computed over the request body exactly as received, so read it before any JSON parsing changes it.

  2. 02

    Timestamp plus hash

    The header carries a timestamp and an HMAC-SHA256 hash made with your endpoint's secret key. Rebuild it and compare in constant time.

  3. 03

    Reject old and repeated events

    Refuse events whose timestamp is too old, and store each event ID so a repeated delivery is not processed twice.

  4. 04

    Sandbox first

    Build and test against Paddle's sandbox with test cards, then switch the keys, prices and secret to live.

PHPTRAVELS and Paddle

Connecting Paddle to PHPTRAVELS

An honest answer first, then the options.

Paddle is not a ready connector

Paddle is not in the PHPTRAVELS payment gateway list and has no published setup guide. The ready gateways, shown below, are the ones built for taking booking payments.

  • For booking payments: a ready gateway

    Enable a ready gateway such as Stripe payments or PayPal payments in the admin with your own merchant account. Checkout, refunds and the booking reference are already wired into the booking flow, as explained on the Payment gateway integration page.

  • For software sales: Paddle as a custom integration

    When your use case fits Paddle's rules, our developers can connect it as a Custom API integration: Paddle.js checkout on your page, a verified webhook endpoint, and payments recorded against your customers. The work is quoted before it starts.

  • Or build it yourself on the source code

    PHPTRAVELS is self-hosted and ships with its full source code, so your own developers can add Paddle for subscriptions alongside the booking engine. The Pricing page lists what each licence includes.

Ready for booking payments

Payment gateways already connected to PHPTRAVELS

For traveller and agent payments, these gateways are ready: you open an account with the provider, enter your keys in the admin, test and go live. The list is the live one from our integrations directory.

Sub-agents can also pay from a prepaid balance or credit limit through the B2B agent wallet, which needs no gateway at all.

FAQ

Paddle API integration: common questions

Talk to sales

Not as a ready connector. Paddle is not in the PHPTRAVELS payment gateway list. If your use case fits Paddle's rules, for example selling your own software subscriptions, it can be added as a custom integration or built by your developers on the included source code.

Paddle is a merchant of record built for software, SaaS and digital products, so it is generally not the tool for flights, hotels or tours. Check Paddle's acceptable-use rules before using it for travel bookings; most travel businesses take booking payments through a payment gateway such as Stripe, PayPal, Adyen or a regional gateway.

The company that legally sells to the customer. It is responsible for collecting and remitting sales tax or VAT, issuing invoices, handling refunds and chargebacks, and appears on the customer's statement. With Paddle, Paddle takes that role and pays you out.

A gateway processes payments for you while you stay the seller and keep the tax and dispute work. Paddle becomes the seller itself, which removes that work for software sales but limits what you can sell through it.

When you sell your own software rather than trips: a booking tool, an API, a plugin or a white-label portal that agencies pay for by subscription. Paddle can then bill them and handle tax in each country.

Paddle sends events such as a completed transaction or a renewed subscription to a URL you register. Each request carries a Paddle-Signature header with a timestamp and a hash, which your server checks with the endpoint's secret key before acting.

Yes. Paddle has a separate sandbox environment with its own account, API keys, prices and test cards. Build and test there, then move the configuration to the live environment.

Yes, as two separate flows: the booking engine takes traveller payments through a ready gateway, and Paddle bills your software subscriptions. Keep their records apart so each sale has the right tax treatment.