What problem does selling an extra solve?
A hotel extra should be genuinely useful, available and understandable: what is included, when it happens, what it costs and who delivers it. A guest seeing a promotional card is not yet a sale.
Distinguish services included in the accommodation from separately charged ones. Taking payment for a service the team cannot deliver creates a guest complaint rather than revenue.
Use an example to separate the financial steps
As an illustration, a TRY 2,400 service with a 30% prepayment requires TRY 720 now and leaves TRY 1,680 for later. These are sample figures, not Rezervem default settings.
Write each status separately: eligibility, offer, accepted order, successful bank payment, service delivery, and cancellation or refund where relevant.
1. Assign a real owner to each offered service
Clarify what is sold, who will fulfil it and which record proves fulfilment. A visually attractive offer on Stay cannot replace these operating decisions.
Transfers need a confirmed time and route, spa bookings need available sessions, and room upgrades need valid room inventory. Test one predictable service and one that requires availability approval.
2. Configure the Experience catalogue
Experience separates categories, products and sellable variants. A transfer could offer one-way and return choices with different prices.
Check inclusion and cancellation terms, eligible outlet, sales channel, tax treatment, prices and guest requirements. A catalogue record alone does not make the product available through every channel.
An order should preserve the purchased variant and price after subsequent catalogue edits. Test venue-specific pricing and descriptions in the guest's language. Catalogue setup (Turkish resource).
- Does the catalogue description match the actual service?
- Are price, tax treatment and selling venue configured?
- Is the relevant sales channel enabled?
- Is there a real capacity check for limited services?
3. Match the Stay offer to the guest's moment
A transfer before arrival and a spa offer during the stay have different context. Show only appropriate services to guests authorised for the relevant accommodation.
Display full price, any deposit and the remaining balance with terms. Room number alone is not a stable guest identity; verify the accommodation context.
Test the actual Stay product-listing and checkout screens for the hotel. Backend catalogue code does not mean the channel is activated at every property.
4. Keep Experience orders separate from Pay money movement
An Experience order records the products and their status; the payment system records successful or failed collection. Generating a payment request does not settle it.
The property may use a product-linked Pay request or an enabled integrated checkout. Not every supported sale needs an independent payment link.
For illustration, a TRY 2,000 service with 40% prepaid collects TRY 800 now and leaves TRY 1,200 to be collected later. Do not present the paid deposit as total revenue collected.
Product-linked payment requests (Turkish resource) and Pay explain the separate collection options.
5. Plan the service after the charge
Define which team prepares the service, when it is fulfilled and how its completion will be confirmed. An automatic Hospitality task requires a verified integration.
A purchased service does not always generate a redemption code. Check whether guest messages, order status and staff fulfilment refer to the same transaction.
6. Reproduce five likely failures
Test failed collection, double clicks, stay cancellation, exhausted capacity and refund requests, rather than testing only a successful purchase.
For each case, record guest-facing status, order state, payment state, PMS effect and operational response. Never place card or sensitive identity data in troubleshooting logs.
- Failed payment: can the guest still claim the service?
- Repeated attempt: are duplicate orders or charges prevented?
- Stay cancellation or room change: is the order attached correctly?
- Service unavailable: is approval separate from offer visibility?
- Refund: can the financial and service status be reconciled?
7. Confirm the property-specific launch gates
Experience and Pay functionality may exist while the Stay sales channel, outlet, provider or service workflow is not yet enabled. Verify each prerequisite.
Do not promise that paying for an extra automatically posts it to the PMS folio or confirms a room upgrade. The documented adapter tests do not establish general upsell-write support.
For hotels using other currencies, verify the exact transaction currency, payment provider and settlement path. The current Experience documentation includes TRY-oriented decisions; international checkout should not be assumed.
The source systems remain separate: Stay, Experience, Pay, PMS and Hospitality.
