01
Accidental refunds happen
Mistyped amounts, refunds against the wrong booking or transaction, refunds on top of refunds — all real, all expensive when they go through unchecked.
Refund Authorisation
Authorise every refund before it goes out.
A role-gated authorisation step that sits between a refund request and the actual refund — so the wrong refund never goes out, and the right one carries an audit trail.
Rolegated approval per refund
Auditwho · when · why retained
Bookingtrail attached to the original payment
Refund decisions attached to the original payment
Booking root
Customer payment to reporting line
£8,420Booking value
BKBooking
Booking
Travel date, lead passenger and package details
ConnectedPYPayment
Payment
Customer payment matched to booking and channel
ConnectedSTSettlement
Settlement
Acquirer settlement and fees visible
ConnectedPFProtected funds
Protected funds
Protected amount held until travel date
ConnectedATATOL
ATOL
Report line traceable back to booking movements
Connected Explainability
Refund decisions attached to the original payment
Authoriser, time, reason and outcome sit against the booking and the transaction the refund reverses — so the audit trail is already in place when a trustee, auditor or customer asks.
CASHWhat has been received, settled and made available.
PROTECTEDWhat is held or restricted until travel.
REPORTINGWhat supports ATOL, APC, trust or audit reporting.
The challenge.
Refunds are easy to get wrong — wrong amount, wrong card, wrong booking, wrong reason. The cost of a bad refund is real money out of the door and an audit trail the auditor cannot rely on.
02
Who refunded this?
Without a clear authorisation step, refund decisions blur into the rest of the operations workload — and the audit trail asks who, when and why months later.
03
Trustees and auditors expect a trail
For ATOL, trust-account and audit reviews, every refund needs to evidence its authorisation as part of the protected-funds picture.
How refund authorisation works.
A refund request becomes an explicit authorisation step that an authorised person — and only an authorised person — can approve or decline. The decision and reason are kept against the booking.
01
Refund requested
The refund request carries the amount, the transaction it refunds against, the booking it relates to and an optional description. It sits in the queue at status PENDING until someone with the refund:approve role acts on it.
Source Transaction
Booking Attached
Status Pending
02
Authorisation or decline
Only users with the refund:approve role see the Authorise and Decline buttons. The authorisation step records the user, the timestamp and, on decline, the reason. The two-step workflow prevents the request-and-process being done by the same person without explicit thought.
Permission refund:approve
Actions Authorise · Decline
Decline reason Recorded
03
Processed to the original rail
Once authorised, the refund moves through to the acquirer or open-banking rail it came from — keeping the audit trail clean by reversing to the original payment instead of routing elsewhere. The status updates against the booking as the refund settles.
Rail Original
Processing Acquirer · A2A
Status Tracked
04
Evidence kept
Every authorised or declined refund leaves an evidence record on the booking — who acted, when, against which transaction, with which reason. When a chargeback, audit or trustee query lands months later, the trail is already in place.
Authoriser Recorded
Reason Captured
Audit trail Preserved
What you get to control.
A clear separation between who can request a refund and who can authorise one — with the workflow and audit trail to defend the decision.
01
Role-gated approval
Only users with the refund:approve role can authorise or decline a refund.
02
Decline reasons
Declined refunds carry the reason against the booking — useful for customer-service follow-up and audit.
03
Authorisation evidence
Authoriser, timestamp and outcome kept on the booking record automatically.
04
One transaction, one trail
The refund record ties back to the original transaction and the booking that produced it — so reconciliation stays clean.
How felloh helps.
Refund authorisation runs inside the same booking-level ledger as the original payment, so the audit trail, customer evidence and trustee reporting all share one source of truth.
01
Fewer expensive mistakes
A role-gated step in the middle catches typos, duplicates and wrong-booking refunds before they go out.
02
Audit-ready by default
Every refund — authorised or declined — leaves the evidence trail trustees and auditors expect.
03
One ledger for refunds
The refund picture shares the booking, transaction and protected-funds context of the underlying payment.
Tighten up the refund workflow.
See how role-gated refund authorisation fits inside the booking-level ledger and the audit trail your trustees and auditors expect.