Adyen is a strong enterprise gateway but it was not built around the booking. felloh replaces merchantReference workarounds, batched notifications and manual booking matching with a booking-aware ledger that covers payments, refunds, settlement, trust-account evidence and supplier disbursements in one operational record.
The Adyen 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.
Adyen integrations carry the booking reference in merchantReference and rebuild the booking picture in your own code. In felloh, the booking is the record — every payment, refund and settlement attaches to it directly.
Adyen ships batched notifications that the handler has to unpack. felloh sends individual webhook events with a clean HMAC-SHA256 signature — the handler logic shrinks accordingly.
Where Adyen needs explicit storedPaymentMethodId management, felloh handles tokenisation automatically — including importing your existing Adyen tokens where scheme portability is supported — and keeps network tokens current through reissue. Capture rates on long-lead bookings stay high without engineering work.
Adyen has no travel-specific concept of protected funds or ATOL trust treatment. felloh surfaces the trust position against every booking and makes the evidence pack available to trustees, regulators and acquirers without manual extraction.
Most Adyen concepts map directly. A few — bookings, refund authorisation, scheduled payments — are felloh-specific because travel demands them.
You can map most of Adyen onto felloh directly. These are the differences travel teams actually feel during cutover — and after.
The booking is a typed record — references, customer, supplier, departure date — that every payment attaches to. The "what booking is this" question goes away.
Adyen notification handlers built around batch unpacking become single-event handlers. Sign-checking moves from custom logic to standard HMAC-SHA256.
Adyen modifications run in a single step. felloh splits initiation from approval and surfaces the booking, supplier and policy context to the approver before money moves.
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 Adyen migration guideThe 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.
Every payment, refund and settlement lives against the booking it relates to. Finance, customer support and dispute teams all read from the same record.
ExploreRefunds are initiated by one user and approved by another, with the underlying booking, supplier-payment and policy context surfaced inline.
ExploreProtected funds, ATOL Trust positions and trustee reporting are part of the same operating record — not a separate compliance project.
ExploreSettlement files unpack to per-booking fees, refunds and chargebacks; bank transfers match against bookings without manual reference chasing.
ExplorePay suppliers and beneficiaries directly against the bookings they relate to, with the full audit trail attached.
ExploreDeposit-then-balance flows, instalments and balance reminders run from the booking record with network-tokenised cards that stay current.
ExploreCutover 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.
Provision sandbox credentials, wire SDKs into a non-production environment and validate authentication, webhook signing and a sample booking-payment flow.
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.
Move payment collection, refund, settlement and reporting flows brand by brand. Run both stacks in parallel so cutover is reversible at every step.
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.
Bring us one Adyen workflow you want to fix and we'll show how felloh wires payments, settlement, refunds and trust evidence around the booking.
