Your own booking engine
For the hotel whose site already has its own booking screen: a signed API to sell against the inventory that lives here.
What it solves
Some hotels already have their booking screen built, with their design and their people maintaining it, and do not want to swap it for a widget. What they do not want is keeping inventory in two places: that is where the oversells nobody can explain come from.
You notice it in things like these
- The hotel site sells against a copy of the inventory that somebody updates by hand.
- The website team does not want somebody else's widget inside their checkout.
How it works
It is not a second engine: it is the same one
Availability, prices, taxes, policies, inventory holds and oversell are resolved by the same engine as the front desk and the widget. A second selling path over the same inventory would be two truths, and the first time they disagreed the hotel would have an oversell nobody could explain.
It is not the widget, and it does not cost the same
The widget is our screen placed on the hotel's site. Your own engine is the hotel's screen with our inventory behind it. They are two ways of selling on the same website, they carry different modules and they are priced differently — a plan can include one without the other.
Public key, secret that never travels
Every request is signed with the secret and a timestamp, so a captured request cannot be replayed. The secret is shown once, on creation and on rotation: if it is lost, you rotate. With no declared domains the key is a server key and a request arriving from a browser is rejected — a key with a secret does not belong in a browser.
The price does not travel inside the offer
Between searching and booking, a signed offer travels with the hotel, the room, the plan, the dates and the guests — but not the price, which is recalculated on booking. That way an offer tampered with from the browser does not change what is charged.
The payment intent is created by our server. Always.
The hotel's engine receives a client secret and finishes the payment on its own screen; it never calls the gateway to create the charge. Creating it on the engine side would put the amount and the currency in the browser's hands, break the reconciliation with the guest folio, and make us the merchant of a sale that is not ours. The charge is born in the hotel's account, as at the front desk.
Cancelling does not refund
Cancelling applies that booking's frozen policy and says how much is withheld and how much is due back, but the refund is issued by the hotel from its panel, because the charge was born in its account. The response says so, so the screen does not promise the guest a refund nobody has sent.
Where it lives in the panel
- yaReserva ecosystem
- Web Embed
- Your own booking engine
It sits next to the widget because they are the two ways of selling on the hotel's site. The contract — what it costs and what it includes — is signed in My yaReserva account, under "Your plan type".
What it needs first
A developer maintaining the hotel's website: this is an API, not a screen.
The hotel's payout account ready, or the charge cannot be opened.
Set up your hotel
What it does not do yet
The limits, told by us
- There is no sandbox: whatever you book while testing are real bookings in the hotel. You test with a separate connection, a low per-booking cap, and cancel what you create. The widget does have test keys; the engine does not yet, and it is on the list.
- A connection only sees what it created: reading, cancelling or charging another connection's booking answers as if it did not exist.
- Contracting it carries its own monthly subscription, charged in full even if the hotel generated plenty of commission: commissions credit against the fee, not against a subscription.
Carry on here
Shall we walk through it with your hotel on screen?
Half an hour, your rooms and your rates, and whatever questions you have. No commitment and no card.