Auth · capture · refund · no-show
Auth-only at booking. Deposits + balance for high-value reservations. Capture at fulfilment. Refund on cancellation. No-show fees against the same vault token. topropay handles the payment lifecycle; your booking software handles the inventory.
Booking payment lifecycle
Every booking touches between two and four of these stages on topropay. The same vault token threads through all of them.
At the moment of booking, the platform issues an auth-only on the buyer's card — the amount is reserved against the buyer's credit line but isn't yet captured. A vault token represents the credential for everything that follows.
Where the merchant takes a deposit + balance, the deposit captures immediately and the remaining balance stays as an open authorisation — or as a scheduled capture closer to the fulfilment date.
At check-in, fulfilment or the configured cut-off, the platform captures the outstanding amount — partial or full. The auth-to-capture window respects scheme rules (typically 7 days card-present, longer for travel and hospitality).
Cancellations refund against the original vault token, partial or full per the merchant's policy. No-show or late-cancellation fees capture from the same authorisation without re-prompting the buyer.
Key benefits
Four properties that show up the moment a merchant stops treating booking and payment as two separate stacks and treats them as one lifecycle.
The buyer commits without their card being charged immediately. The merchant has a reserved amount they can capture, partial-capture or release per the booking outcome — the scheme rules and the merchant's own cancellation policy.
Deposits run as a capture; the balance runs as a separate authorisation against the same vault token, scheduled to capture at fulfilment. The platform handles the two-stage lifecycle without forcing the merchant to invent it in their own code.
Cancellation refunds reverse against the vault token. No-show or late-cancellation fees capture against the same token — no need to re-prompt the buyer for card details, no fresh authorisation cycle to fail.
Reservations, deposits, balance captures, refunds and no-show fees from every connected acquirer normalise into one reconciliation feed — tagged by booking ID, customer, channel and currency.
How booking with payment runs end to end
What happens between the buyer clicking confirm in your booking software and the row appearing in your finance ledger.
The merchant's booking system shows availability per slot, room type or service. topropay isn't involved in the inventory or slot mechanics — those sit with the merchant's booking software.
At the moment of confirmation, card data captures into the PCI L1 vault from the merchant's hosted checkout or embedded fields. A vault token is returned for the booking record.
The platform runs an auth-only against the buyer's card via the routing engine across connected acquirers. A successful auth holds the amount; the buyer's statement may show a pending line.
When the booking is fulfilled — guest arrives, appointment begins, ticket is presented — the merchant or scheduled job triggers capture. Partial-capture is supported.
Cancellations refund against the vault token; no-show fees capture against the existing auth. Operator-side controls require justification on every refund and log the actor identity.
Settlement files from every connected acquirer normalise into one feed — booked, captured, refunded and disputed receipts in the same export, tagged with booking ID.
Main use cases
Six recurring booking shapes — hotels, appointments, tours, transport, restaurants and professional services.
hotel booking payment gateway flows on topropay — auth at booking, optional deposit capture, balance capture at check-in, refund on cancellation, no-show capture per the merchant's policy.
appointment booking and payment system for salons, clinics, fitness studios and consultancies — vault tokens drive both pay-at-booking and pay-at-visit flows on the same merchant record.
Booking with payment for tours and experiences — deposit at booking, balance closer to the date, full refund inside the cancellation window, partial refund outside.
Vehicle rental, ticketing and short-haul transport — auth-only at reservation, capture at pick-up or boarding, refunds on cancellation per the carrier's rules.
Restaurants holding tables with a per-cover deposit or a card-on-file for no-show capture; both ride the auth-only + scheduled-capture engine.
Professional-services bookings where the fee is partly paid at booking and partly billed afterwards — same vault token covers the second invoice.
Platform features
Twelve capabilities behind the booking payment surface — from auth-only and partial capture through deposit + balance and no-show flows to scheme programme posture.
Funds reserved against the buyer's card; capture deferred to fulfilment.
Per-scheme capture windows respected — 7 days card-present, longer for travel and hospitality.
Capture less than the original auth — e.g. final bill is below the held amount.
Two-stage flow — deposit captures immediately, balance is a separate auth captured at fulfilment.
Same token drives refunds on cancellation and no-show / late-cancellation captures.
Capture jobs scheduled relative to the booking date — e.g. 24 hours before, on check-in, on first scan.
Booking ID, customer, slot reference and policy carried as metadata on every authorisation event.
Per-BIN, per-currency routing across the connected panel; soft declines cascade inside the same auth.
Selective 3DS2 at booking; stored-credential transactions (capture, no-show) exempt from challenge per scheme rules.
Card data captures into the platform vault before any acquirer sees it; PAN never lands on the merchant's booking system.
Chargebacks on booking flows aggregated into one queue with evidence-pack templates per vertical.
Settlements, fees, refunds and chargebacks from every connected acquirer in one normalised ledger, tagged by booking ID.
Industry relevance
topropay's booking-flow posture targets licensed merchants across Europe, the UK, APAC and LATAM. The merchant supplies the booking software (or uses an off-the-shelf partner); topropay supplies the payment orchestration, vault, routing and reconciliation. Adult content, unlicensed gambling and other grey-market verticals are out of scope regardless of booking shape.
Trust & compliance
One audited environment plus scheme capture-window rules per vertical (card-present, lodging, vehicle rental, ticketing). Sub-merchants inherit the posture across every booking surface.
Ready to wire booking to payment
A 30-minute flow review covers the booking-side software you already use, the auth-only / capture / refund / no-show shapes relevant to your vertical, and a sandbox you can test against before any commercial commitment.
Frequently asked
Definitions, lifecycle questions, the "free" disambiguation, deposit + balance, cancellation refunds, no-show captures and the practicalities of pairing your booking software with topropay.
An online booking and payment system on topropay covers the payment side of a booking flow — auth-only at the moment of booking, optional deposit capture, scheduled balance capture at fulfilment, refunds on cancellation, and no-show / late-cancellation fee captures. topropay supplies the payment orchestration; the merchant's booking software supplies the inventory, slots and availability.
topropay focuses on the payment side. For the booking-and-payment-system shape, merchants pair topropay with their existing booking software (hotel PMS, salon scheduler, ticketing engine, OTA-side connector). topropay's REST API exposes the payment primitives the booking software calls — authorise, capture, refund, void, schedule capture.
The booking payment system on topropay runs an auth-only against the buyer's card at the moment of booking. The authorisation holds the amount against the buyer's credit line; nothing is captured until the merchant triggers it. Auth-to-capture windows respect scheme rules per vertical (card-present, lodging, rental, ticketing).
Free online booking and payment system is a phrasing buyers use when looking for booking software without a per-seat subscription fee. topropay is the payment side — there are subscription-free and open-source booking platforms that integrate with topropay on the payment leg; the merchant pays per-transaction on the payment side rather than a per-seat booking fee. topropay itself isn't free; pricing is per-transaction.
A truly $0 booking + payment combination doesn't exist commercially in this space — the schemes (Visa, Mastercard, Amex) charge interchange and assessment fees on every transaction, and a regulated payment provider needs to cover those costs. The closest is a per-transaction-only model with no monthly or per-seat fee on either the booking software or the payment side, which topropay can deliver on the payment leg when paired with a per-transaction-priced booking partner.
The online booking payment system supports a deposit + balance split — the deposit captures immediately at booking, the balance runs as a separate authorisation scheduled to capture at fulfilment. Both reference the same vault token, so refunds and no-show captures work consistently across the two.
Appointment booking and payment system rebook flows are handled on the merchant's booking-software side. topropay's contribution is that the vault token issued at the first booking carries over — rebooks don't require the buyer to re-enter card details, and reminders / cancellation links can point at hosted refund or rebook surfaces if the merchant wires them up.
A hotel booking payment gateway flow on topropay typically runs as: auth-only at reservation, optional deposit capture, balance capture at check-in or check-out, refund on cancellation per the hotel's policy, and no-show capture per the hotel's no-show fee. Visa and Mastercard each have specific lodging-flow rules around the auth-to-capture window and the late-cancellation exception.
Booking with payment for travel and experiences is typically deposit-at-booking + balance-closer-to-date, with full refund inside the cancellation window and partial refund outside. The merchant configures the schedule per product; topropay handles the per-stage authorisation and capture events.
The best online booking and payment system depends on the vertical — hotels need PMS-deep integration, restaurants need short-deposit flows, ticketing needs high-volume burst capacity, salons need recurring + tip flows. topropay's role is the same in each — the payment orchestration — and the merchant pairs it with a vertical-specific booking platform.
Yes. Multi-currency settlement is supported per the merchant's configured currencies; bookings can be priced in the buyer's local currency and settle into the merchant's home currency or stay in the buyer's currency for treasury reasons. The routing engine picks the optimal connected acquirer per currency.
Cancellation refunds run against the vault token issued at booking. The merchant triggers the refund from the dashboard or via API; partial refunds are supported (e.g. for cancellation outside the free-cancellation window). Refunds reverse through the same connected acquirer that cleared the original auth.
No-show captures run against the open authorisation — the merchant captures the configured no-show fee from the held amount and releases any remainder. For merchants whose no-show fee exceeds the held amount, a separate auth + capture against the vault token covers the difference, subject to scheme rules on stored-credential transactions.
topropay exposes REST endpoints the booking software calls — authorise, capture, refund, void, schedule capture, fetch transaction. Any booking platform that can make HTTP requests can integrate. Direct plug-ins for common booking platforms are also available; the dashboard lists currently-supported integrations.
Most booking-flow merchants go from contract to first booking in 1–3 weeks. The variables are KYB depth, the merchant's booking software's integration shape, and any vertical-specific scheme programme registrations (lodging, rental). Sandbox covers the full auth → capture → refund flow from day one.
Related