Travel reporting that matches the booking
Mint Payments reporting is shaped around the acquirer. felloh exposes settlement, fees, refunds and protected funds at the level travel finance actually works.
Migrate from Mint Payments
Mint Payments to felloh: travel-shaped operations on a booking-aware ledger.
Mint Payments handles acquiring well for Australian and APAC travel businesses, but the operational picture is acquirer-shaped. felloh replaces that with a booking-aware ledger that covers payments, refunds, scheduled instalments, trust treatment and supplier disbursements in one record — suited to travel from deposit through to post-trip refund.
Why teams move
Why travel finance teams leave Mint Payments.
The Mint 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.
Scheduled payments run reliably out of the box
Deposit-then-balance and multi-instalment plans run against the booking with network-tokenised cards that stay current through reissue — capture rates on long-lead bookings stay high without engineering work.
Refund handling gains an approval step
Two-stage authorisation, with the booking, supplier-payment status and policy context surfaced inline, replaces single-call refunds.
Supplier disbursements live in the same ledger
Pay suppliers, agents and DMCs from the same record the customer booking lives on. No separate disbursement reconciliation.
Concept mapping
Mint Payments → felloh, side by side.
Most Mint Payments concepts map directly. A few — bookings, refund authorisation, scheduled payments — are felloh-specific because travel demands them.
Mint Payments felloh Note
Merchant ID Brand within unified ledger Multiple MIDs roll up cleanly.
Hosted page Payment Links + hosted checkout Booking-aware payment links replace standalone hosted flows.
Card vault token Automatic tokenisation Network tokens current through reissue.
Recurring payments Scheduled payments Per-instalment scheduling against the booking.
Refund API Two-stage refund flow Submit + authorise with full booking context.
Notification handler Per-event webhooks (HMAC-SHA256) Standard signing, one event per request.
What changes
Three shifts that matter day one.
You can map most of Mint Payments onto felloh directly. These are the differences travel teams actually feel during cutover — and after.
BKG
Bookings become the operating record
Payments, refunds, supplier disbursements and scheduled instalments all attach to the booking automatically.
SCH
Scheduled payments run natively
Deposit-then-balance and multi-instalment plans are first-class — the schedule, the tokens and the recovery flow all live on the booking.
REF
Refunds enforce two-stage authorisation
Refund queue surfaces booking and supplier context to the approver before money moves.
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 Mint Payments migration guide What you gain
What felloh adds that Mint 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 Mint Payments to a booking-aware travel platform.
Bring us one Mint Payments workflow you want to fix and we'll show how felloh wires payments, settlement, refunds and trust evidence around the booking.