Operations on one ledger, not assembled from exports
Trust Payments exposes payments and settlement; felloh ties them to the booking, the supplier, the trust position and the reporting evidence in one record.
Migrate from Trust Payments
Trust Payments to felloh: travel-shaped operations on a booking-aware ledger.
Trust Payments is a familiar UK acquirer in travel, but the operational surface still needs the operator to assemble booking-level finance themselves. felloh keeps payments, settlement, refunds, ATOL trust evidence, supplier disbursements and reporting connected to the same booking — out of the box.
Why teams move
Why travel finance teams leave Trust Payments.
The Trust 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.
Refund authorisation comes with real controls
Two-stage authorisation, with the booking, supplier-payment status and policy context surfaced inline, replaces single-call refunds and gives travel finance an audit trail it can rely on.
Reconciliation stops being a monthly project
Settlement files unpack to per-booking fees, refunds and chargebacks automatically. Bank transfers match against bookings without manual reference chasing.
ATOL and trust evidence are native, not bolt-on
Trust positions, protected funds and trustee reporting attach to bookings automatically. Audits and trustee questions get answered from the same data the operations team already reads.
Concept mapping
Trust Payments → felloh, side by side.
Most Trust Payments concepts map directly. A few — bookings, refund authorisation, scheduled payments — are felloh-specific because travel demands them.
Trust Payments felloh Note
Site reference Brand within unified ledger Multiple sites roll up to one booking-level picture.
STPP transactions Bookings + payments Bookings are first-class; payments attach to them.
JWT-signed requests API key + HMAC-SHA256 webhooks Standard signing, one event per request.
Tokenisation (parenttransactionreference) Automatic tokenisation Network tokens stay current through reissue.
Refund call Two-stage refund flow Submit + authorise with full booking context.
MyST dashboard felloh dashboard Booking-aware view across payments, refunds, settlement, risk and reconciliation.
What changes
Three shifts that matter day one.
You can map most of Trust Payments onto felloh directly. These are the differences travel teams actually feel during cutover — and after.
BKG
Bookings become the operating record
No more stitching payments to bookings in operator code. The booking carries every payment, refund, supplier disbursement and trust event against it.
REF
Refunds enforce two-stage authorisation
Approval sees the booking, supplier-payment status and cancellation policy. Audit captures who initiated and who approved.
RCN
Reconciliation runs from settlement files automatically
Trust Payments settlement files no longer need manual unpacking — felloh ties each line back to the underlying booking.
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 Trust Payments migration guide What you gain
What felloh adds that Trust 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.
Booking-aware ledger
Every payment, refund and settlement lives against the booking it relates to. Finance, customer support and dispute teams all read from the same record.
ExploreTwo-stage refund authorisation
Refunds are initiated by one user and approved by another, with the underlying booking, supplier-payment and policy context surfaced inline.
ExploreTrust & ATOL evidence
Protected funds, ATOL Trust positions and trustee reporting are part of the same operating record — not a separate compliance project.
ExploreAutomatic reconciliation
Settlement files unpack to per-booking fees, refunds and chargebacks; bank transfers match against bookings without manual reference chasing.
ExploreSupplier disbursements
Pay suppliers and beneficiaries directly against the bookings they relate to, with the full audit trail attached.
ExploreScheduled payments
Deposit-then-balance flows, instalments and balance reminders run from the booking record with network-tokenised cards that stay current.
Explore 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.
Setup & sandbox
Provision sandbox credentials, wire SDKs into a non-production environment and validate authentication, webhook signing and a sample booking-payment flow.
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.
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.
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 Trust Payments to a booking-aware travel platform.
Bring us one Trust Payments workflow you want to fix and we'll show how felloh wires payments, settlement, refunds and trust evidence around the booking.