Authorisation is the step in a card transaction where the issuer checks whether the payment can proceed and either approves it (returning an authorisation code) or declines it (returning a decline code and a reason). An approval reserves the funds but does not necessarily move money — that happens at capture and again at settlement, which can be hours or days later. The same payment can be authorised, voided, partially captured, fully captured, refunded and disputed across its lifetime.
Travel payments glossary
Authorisation
The step where a card issuer approves or declines a payment request.
Why it matters in travel
A booking can look paid from the sales screen long before finance has settlement evidence in the bank account, so treating authorisation and settlement as the same event is one of the most common reconciliation mistakes in travel. A pre-authorised deposit may sit on hold for days, a balance captured weeks later may not settle until after the customer has travelled, and a refund may be authorised but not move funds until the next settlement batch.
Confusing authorisation with settlement is the source of a lot of travel-finance error. Sales celebrates a record day on the basis of authorisations that may yet capture or void; finance plans cash against authorisations that have not actually settled; suppliers expect payments funded by money that is still on hold. Drawing the distinction sharply at the booking level is what keeps the picture honest.
The travel businesses that treat authorisation correctly distinguish authorised, captured, settled, refunded and voided states at the booking level — and surface anything that has been in a transitional state too long. The businesses that treat any "approved" as paid run on the assumption that everything will settle, until something does not.
How felloh helps
felloh keeps payment state attached to the booking so finance, operations and sales can distinguish authorised, captured, settled, refunded, voided and failed payments without guessing. When the state changes, every system reading from the booking ledger sees the change at the same time.
The dashboard’s Bookings and Transactions views show every state transition against the same record, so an authorised deposit never gets confused with a settled balance. Webhooks fire on every state change so downstream systems — booking platform, accounting, CRM — stay aligned without polling.
For finance teams reporting on real cash, the result is that the topline finally matches the bank statement. Sales sees authorisations, finance sees settlements, and both teams are reading the same record rather than arguing about which number is right.
Where this shows up in risk and disputes.
Authorisation touches more than one workflow at felloh. Start with the pages most travel teams reach for next.
- Financial Control
Control refunds, exceptions, supplier exposure and payment risk against the same booking record.
Explore - Financial Protection Data
Authentication, settlement, protected funds and refund history kept with the booking for dispute defence.
Explore - Payment Optimisation
Acceptance, decline and authentication evidence so you can act on the patterns that matter.
Explore
More on payment risk and disputes.
Real-world context from the felloh team and customers, written for travel finance and operations.
UpdatesEnhance Your Payment Success with felloh's AI Decline Analysis for the Travel Industry
felloh's AI Decline Analysis surfaces real-time insight on why card payments fail and the best next step — for higher acceptance on travel bookings.
Read article
InsightsMinimising Payment Risks of phone payments: The Smart Way for Travel Merchants
Phone bookings are still essential in travel, but they carry payment-security risk. How to keep last-minute trips moving without exposing the business.
Read article
Connect the dots.
See how payments, settlement, refunds and reporting evidence connect around every booking.