Authorisation
The step where a card issuer approves or declines a payment request.
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.
What it means for travel businesses.
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 handles it.
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.
Related terms.
Authorisation code
The reference number a card issuer returns when it approves a transaction.Read termGlossary termAuthorisation hold
A temporary reservation of funds on a card before the merchant captures the payment.Read termGlossary termPre-authorisation
An authorisation that reserves funds on a card before the final amount is captured.Read termGlossary termIssuer
The bank or financial institution that issues a card to a cardholder.Read termGlossary termSettlement
The movement of processed payment funds into the merchant account or bank account.Read termSee how this works around your bookings.
Bring one payment, reporting or cash-position problem. We will show how felloh connects the booking-level money trail behind it.
Book a walkthrough