Migrate from Global Payments

Global Payments to felloh: travel-shaped operations on a unified ledger.

Global Payments handles acquiring at scale, but its reporting and operational surface assume general commerce. felloh replaces acquirer-shaped settlement, manual booking matching and brand-by-brand finance assembly with a single booking-aware ledger that suits travel from deposit to departure.

Why teams move

Why travel finance teams leave Global Payments.

The Global Payments stack does its job, but the operational picture it produces is rarely shaped for travel. felloh keeps payments, refunds, settlement, trust evidence and supplier disbursements connected to the same booking record from day one.

Reporting that matches travel operations

Global Payments reporting is shaped around the acquirer, not the booking. felloh exposes settlement, fees, refunds, chargebacks and protected funds at the level finance, operations and customer support actually work.

Refund handling gains accountability

Two-stage refund authorisation, audited end to end, replaces single-call refunds. The approver sees the booking, supplier and policy context before money moves.

Multi-brand finance rolls up cleanly

Global Payments separates by MID. felloh holds one booking-level ledger across the group, with Risk Analysis, Settlement and Decline Analysis reading at brand, region and group level from the same record.

Travel-specific compliance is native

ATOL Trust positions, protected funds and trustee reporting attach to the booking automatically. Audits stop being a project and become a query.

Concept mapping

Global Payments → felloh, side by side.

Most Global Payments concepts map directly. A few — bookings, refund authorisation, scheduled payments — are felloh-specific because travel demands them.

Global Payments felloh Note
MID Brand within unified ledger Multiple MIDs roll up to one booking-level picture.
Hosted payment page Payment Links + hosted checkout Booking-aware payment links replace standalone hosted flows.
Token vault Automatic tokenisation Network tokens stay current through card reissue.
Refund call Two-stage refund flow Submit + authorise with full booking context.
Settlement reports Per-booking settlement view Files unpack to per-booking fees, refunds and chargebacks.
Async notification Per-event webhooks (HMAC-SHA256) Standard signing, single event per request.
What changes

Three shifts that matter day one.

You can map most of Global Payments onto felloh directly. These are the differences travel teams actually feel during cutover — and after.

BKG

Bookings replace transaction-level reporting

Reporting moves from acquirer reports to booking-level evidence. Finance, operations and customer support all read from the same record.

REF

Refunds enforce two-stage authorisation

Single-call refunds become a queue of pending approvals with the booking and supplier context surfaced inline.

RCN

Reconciliation runs automatically

Settlement files unpack to per-booking fees, refunds and chargebacks. Bank transfers match without manual reference chasing.

The new shape

A booking, a payment, a refund.

The felloh API is built around the booking. The same record carries the customer, the supplier obligation, the payment trail and the trust position — so finance, customer support and dispute teams all read from one place.

See the full Global Payments migration guide
What you gain

What felloh adds that Global Payments doesn't.

The travel-specific layer comes built in. ATOL Trust, supplier disbursements, scheduled instalments, two-stage refund authorisation and automatic reconciliation — all live against the same booking record.

Migration plan

A four-phase rollout — run both stacks in parallel.

Cutover is reversible at every step. Move data and flows brand by brand, with parallel processing while you confirm acceptance and settlement timing match your existing baseline.

01

Setup & sandbox

Provision sandbox credentials, wire SDKs into a non-production environment and validate authentication, webhook signing and a sample booking-payment flow.

02

Data migration

Move customer, booking, beneficiary and card-token records across. felloh imports existing card tokens directly from your current acquirer where scheme token-portability is supported, so customers do not need to re-enter card details for live bookings.

03

Flow migration

Move payment collection, refund, settlement and reporting flows brand by brand. Run both stacks in parallel so cutover is reversible at every step.

04

Cutover & decommission

Switch live volume across, monitor acceptance and settlement timing against your existing baseline, then decommission the legacy integration on a schedule that suits the dispute window.

Move from Global Payments to a booking-aware travel platform.

Bring us one Global Payments workflow you want to fix and we'll show how felloh wires payments, settlement, refunds and trust evidence around the booking.