One payment, five states, and a human at two of them
Version 1 is deliberately small and deliberately manual. Everything below describes what actually happens, including the parts a machine does not do yet.
Where the money is, at every moment
Why the reference is mandatory
A bank credit arrives with an amount, a sender and a free-text line. That line is the only thing tying it to a booking, so it is enforced rather than encouraged, and it is formatted to be visibly distinct from any other payment reference our accountants handle.
A credit that arrives without one is not rejected — it goes to a queue and a human works backwards from the amount and the sender.
Two human queues
Matching credits to bookings, and approving releases. There is no bank API in version 1, so these two queues are the product's real capacity limit. Releases above a threshold need a second approver, and every approval is written to an audit log with the name of whoever clicked it.
The cases that decide whether anyone trusts this
A trust product is judged entirely on its unhappy paths. These are answered in advance so nobody is improvising with someone else's money.
The agency never issues a ticket
The dispute window closes and the traveller is refunded in full. The agency does not need to agree, and nothing about the refund requires their cooperation — that independence is the entire point of the arrangement.
The ticket exists but is wrong
Wrong passenger, wrong route, wrong date. Treated as no valid ticket: the proof-of-issuance check is against the booking as sold, not merely against the existence of a ticket number.
The traveller sends the wrong amount
A short payment is flagged rather than auto-rejected. Small shortfalls are usually intermediary fees, and a system that bounces them creates two problems instead of solving one. A human decides.
The traveller changes their mind
Before release, the money is still theirs in every practical sense, and the agency's cancellation terms apply to the booking rather than to the funds. Escrow does not create a right to cancel, but it does mean nobody is chasing an agency for a refund it has already spent.
The money arrives after the hold expires
The seat may be gone even though the payment is fine. The credit is matched, the booking is marked expired, and the money is returned rather than held against a booking that no longer exists.
Somebody disputes it later
Every state change is logged with a timestamp and an actor, and the traveller's status page stays available for 24 months. The record is the same one both sides see.
What an agency actually builds
A redirect out, two webhooks back. Our own travel brands are merchant number one and use the same public API, so there is no private path that works better than yours.
1 · Create the payment
Server-side call with the booking, the amount, the currency and your customer's email. You get back a payment reference and a portal URL.
2 · Send the traveller
Redirect to the portal URL instead of showing your own bank details. Everything the traveller needs — recipient, IBAN, reference, deadline — lives there.
3 · Listen for two events
payment.held tells you the money is in and it is safe to issue. payment.released tells you it has been paid out. A payment.returned event closes the unhappy path.
The merchant API contract is being written alongside the first pilot integrations rather than published in advance, so that the agencies in the pilot shape it. Ask us for the current draft.
See it from the traveller's side
The four screens a customer moves through, and the page they land on when they search for our name after being told to wire us money.