Merchant vs Direct: Understanding Payment Types

The Four Payment Types

The paymentType field returned in every Search option is not a display label — it determines the entire payment flow for that booking. It is a supplier-level setting, not configurable per-request. A supplier either supports a given payment type or it does not.

Before implementing any payment flow, filter your search results by the payment types your platform actually supports. Presenting an option withCARD_BOOKINGto a user when you have no card collection interface will cause every booking in that category to fail at the Book step.

MERCHANT

The platform — not the hotel — collects payment at the time of booking. The supplier is paid by Travelgate on a net basis. No card details are sent in the booking payload.

This is the simplest integration path. Your checkout flow collects payment via your preferred gateway (JusPay for INR, Stripe for international currencies), confirms the charge, and then calls Book. The booking is financially clean and the user receives an immediate, unambiguous confirmation.

MERCHANT is the highest-conversion payment type for consumer-facing applications because the transaction is complete at the moment of confirmation — no uncertainty about when the hotel will charge, and no need for the user to have a credit card accepted by the specific property.

DIRECT

The hotel charges the guest directly — either at check-in or check-out. A valid credit card must be provided at booking time as a guarantee; the card details are included in the Book payload and passed to the supplier.

DIRECT is the standard for B2B2C and whitelabel use cases where the agency manages billing relationships with their clients separately. It is also common for luxury and boutique properties where the hotel has a direct billing preference.

"DIRECT bookings require PCI DSS consideration on your end — card data flows through your system before reaching the supplier. Ensure your infrastructure is scoped and documented accordingly, even if Travelgate itself is not PCI DSS certified."

CARD_BOOKING

A virtual card is issued at the time of booking and charged immediately. The hotel receives virtual card details rather than the guest's personal card. This is common in B2B agency workflows where the agency issues the virtual card from a corporate card programme.

CARD_BOOKING provides the immediate confirmation of MERCHANT with the supplier billing flexibility of DIRECT. The trade-off is integration complexity — you need a virtual card issuance capability in your stack.

CARD_CHECK_IN

A virtual card is issued at booking time but the hotel charges it at check-in, not immediately. This delays the cash flow impact of the booking while still guaranteeing the reservation with a valid card.

Useful when the agency wants to maintain payment control but the supplier's billing process is tied to the arrival date — common with independent hotels and some boutique chains.

JusPay vs Stripe Routing

For MERCHANT payments, the gateway routing is determined by the booking currency:

This routing is implemented in the application layer, not at the Travelgate level. Travelgate does not manage your payment gateway configuration — it processes the booking; your platform handles the charge.

DeltaPrice & Price Protection

DeltaPrice is enforced at the Quote step. If the revalidated price exceeds the Search price by more than the configured tolerance, Quote returns aDELTA_PRICE error rather than a new optionRefId.

The tolerance is set in HotelSettingsInput — typically 1–3% for B2C consumer flows and 0% for corporate booking tools where price certainty is a hard requirement. A high rejection rate on DeltaPrice indicates pricing volatility for a specific supplier; monitor via Travelgate's Stats dashboard.

When DeltaPrice fires, surface both prices to the user — old and new — and give them an explicit accept/decline choice. Never absorb the difference silently. Never retry Quote hoping the price drops; the supplier's current rate is the rate.

Choosing the Right Type