How it works in a nutshell
A customer goes through your normal checkout and submits a booking request.
Their card is authorized (a hold), not charged.
You get notified — by email, in-app, SMS, and a push notification to your mobile app.
You accept or refuse the request.
Accept → the card is charged and the booking is confirmed.
Refuse → the hold is released and the customer is never charged.
If you don’t respond in time, the request expires automatically and the hold is released — nobody is charged.
Note: The customer is only ever charged when you accept. Until then, it’s just a hold on their card.
Turning on Bookings on Request for a product
Bookings on Request is a per-product setting, so you can keep some experiences instant and make others request-only.
Open the product you want to edit.
Find the setting “Bookings require your approval?”
Turn it on and save.
Once enabled, customers booking that product will go through the request flow described below instead of being charged instantly.
CAUTION: On-request products cannot be sold through OTA channels (Bokun, GetYourGuide, Viator). If the product is connected to a channel, disconnect it from every channel before enabling on-request bookings — and vice versa.
What the customer sees
When a product requires your approval, the checkout changes in a few important ways so the customer knows exactly what to expect:
A notice appears above the payment form: “Your card will be authorized (a hold), not charged now. We only take payment if we accept your request; otherwise the authorization is released.”
The checkout button reads “Request booking” instead of “Pay now”.
After submitting, the customer lands on a “Your booking request has been received” page, confirming their card has been authorized but not charged, and that you’ll review the request and email them once it’s confirmed.
That status page updates on its own — the moment you accept, it flips to the confirmed view. The customer can safely close the page in the meantime.
The customer also receives a “We received your request” email letting them know the hold is in place and when they can expect to hear back.
Getting notified when a request comes in
As soon as a customer’s card hold is successfully placed, you’re notified across every channel:
Email
In-app notification
SMS
Push notification to the mobile app (it deep-links straight to the booking)
In your bookings list, requests awaiting your decision are marked with an amber “On request” label, and you can use the “On request” filter to see only the bookings that need your attention.
Note: You’re only notified once the hold has actually gone through, so abandoned checkouts won’t ping you.
Accepting or refusing a request
You can decide on a request from two places — your web dashboard, or the mobile app while you’re on the go. Both do exactly the same thing.
From the mobile app
Open the push notification (or go to the booking in the app).
Review the request.
Tap Accept or Refuse.
When you refuse, you can add a reason and choose whether to let the customer know.
From the web dashboard
Open the booking from your bookings list.
Click Accept to confirm, or Refuse to decline.
Refusing opens a short form where you can add a reason and decide whether to notify the customer.
Note: Acting on a request needs the “Accept booking requests” permission. If you don’t see the option, ask an admin on your team to grant it.
CaptainBook keeps everything in sync, so if someone on your team (or the automatic expiry) has already decided a request, you’ll simply be told it’s already been handled and the screen will refresh.
What happens after you decide
If you accept
The customer’s card is charged for the full amount.
The booking is confirmed, exactly like a normal booking.
The customer receives your standard booking confirmation email.
Note: There’s no separate “your request was accepted” email — accepting simply turns the request into a confirmed booking, with the usual confirmation message.
If you refuse
The card hold is released — the customer is not charged.
The booking is cancelled.
By default the customer is notified that their request wasn’t accepted (you can turn this off when refusing). There’s nothing to refund, since no payment was ever taken.
How long you have to respond
Each request comes with a deadline, shown on the booking. The hold lasts as long as the card network allows:
Credit cards: up to 6 days.
Debit, prepaid, and 3D-Secure cards: up to 24 hours.
In every case, the deadline is capped at the experience’s start time — you’ll always need to decide before the experience begins.
If you don’t respond before the deadline, the request expires automatically: the hold is released, the booking is cancelled, and the customer is emailed to let them know it expired before you could respond — with an invitation to book again. No charge is ever taken.
A note on declined cards
In rare cases, a card can fail when you accept (for example, if the hold lapsed or the bank declines the capture). If that happens, the booking can’t be confirmed and the customer is notified that the payment couldn’t be completed. You may want to reach out to them directly to arrange another way to book.
Quick recap
Bookings on Request hold the customer’s card instead of charging it.
Enable it per product with “Bookings require your approval?” — but not on products sold through OTA channels.
You’re notified everywhere, including push notifications on the mobile app.
Accept charges the card and confirms; refuse releases the hold and charges nothing.
You can decide right from the mobile app or the web dashboard.
Respond before the deadline (up to 6 days for credit cards, 24 hours for debit/3DS, always before the experience starts) — otherwise the request expires on its own and nobody is charged.
Happy booking!
