Sign in
hotel-bookings

Payment Initiated

Called by the client immediately BEFORE it mounts the payment element.

This is what stops a re-prebook from stranding a payment. LiteAPI cannot return a transactionId once a new prebook has replaced it, and a booking stays prebooked right through payment — so without this stamp the backend has no way to distinguish "the user is still choosing" from "the user has paid and we must not touch the transaction id". A browser refresh on the checkout URL is enough to lose the money otherwise.

Deliberately idempotent and deliberately not a state machine: it only ever moves payment_status from unset to processing. The real payment status arrives later from LiteAPI at /book and must win.

post/hotel-bookings/{booking_id}/payment-initiated

Path parameters

booking_idstring uuid required

Response

Successful Response

booking_idstring uuid required
statusstring required
provider_statusstring nullable required
provider_booking_idstring nullable required
hotel_confirmation_codestring nullable required
hotel_idstring required
hotel_namestring nullable required
checkinstring date required
checkoutstring date required
currencystring required
all_in_totalnumber nullable required
booked_totalnumber nullable required
cancellation_feenumber nullable required
refund_amountnumber nullable required
refundable_tagstring nullable required
cancellation_policyobject nullable required
rooms_pricedinteger nullable required
trip_idstring uuid nullable required
stay_tool_call_idstring nullable required
sandboxboolean required
payment_statusstring nullable required
payment_modelstring nullable required
payment_secretstring nullable required
prebook_idstring nullable required
booking_intent_idstring nullable required

Changes