Hi Experts!

I have a question and will be grateful if you can help me out with some ideas.

In an online hotel or ticket booking reservation system, normally a user is allocated a specific time to complete their registration / payments etc and during that time the system holds the reservation for that user. If the user is unable to finish their registration during that time the system times out and the user is not allowed to proceed any further. The system unholds the reservation for other users.

My question is, if a user is taken to the payment gateway system (paypal etc) and they spend all of the allocated/hold time on the payment page, and after making a successful payment they return back to the site, will the system still allow them to complete the booking even though the user ran out of his allocated time?

How does this work in a typical booking system?

Many thanks in advance.

Dani AI

Generated

Short answer: the authoritative proof of payment should come from the payment provider (server-to-server), not from the browser return or the PHP session. The common, robust pattern is to create a server-side reservation (with an expiry) before redirecting the user to an external gateway, include a stable reservation token in the gateway request/metadata/return URL, then rely on the gateway’s asynchronous notification (IPN/webhook/PDT) to mark the reservation paid. This is essentially the approach suggested but with a few practical safeguards added.

A minimal, practical flow:

  • Insert a reservation row server-side and mark it held with hold_expires_at.
  • Include the reservation id/token in the gateway call (PayPal custom / Stripe metadata / return URL).
  • Treat the gateway webhook/IPN as authoritative: on receipt validate the event, mark paid, and capture inventory atomically.
  • Have a background worker/cron to expire and release held reservations.
    Example reservation fields:
    
    reservations
  • id (uuid)
  • user_id
  • inventory_id
  • status (held | paid | expired | cancelled)
  • hold_expires_at (datetime)
  • provider (paypal|stripe)
  • provider_ref
  • created_at
    
    PayPal’s IPN/PDT and webhook docs explain that notifications can be asynchronous and why server-side verification is required. ([developer.paypal.com](https://developer.paypal.com/api/nvp-soap/ipn/?utm_source=openai))

Don’t rely on the browser redirect (success_url) or on the original session to decide fulfillment—redirects can be missed, spoofed, or lose session state. Use webhooks and idempotent server-side handlers so the same notification can be processed safely if retried. Stripe’s docs explicitly warn against trusting the redirect alone and show how to use webhooks to fulfill orders. ()

Business decisions: whether a payment that arrives after a hold expired is accepted or refunded is a policy choice. Implement clear logging, show the hold countdown to users, test in the gateway sandbox, and prefer atomic DB checks (row locks or compare-and-set) when moving heldpaid to avoid double-sells.

The best way to handle this is by processing the payment on your website directly.

If you have to use an external payment gateway, the best way to handle that would be to create the reservation before sending them to the payment gateway. After they complete the payment, using a feature like Paypal's IPN (instant payment notification), you would mark the reservation as paid and the transaction would be over. If they don't make the payment, you could setup a cron job to remove all reservations that are 30 minutes old for example and haven't been paid.

In this setup, time wouldn't matter. You have to collect all the required information before sending them to the payment gateway. With paypal, for example, this is kind of a necessity because once you they return to your site their session might not be the same and they wouldn't be able to continue on with registration anyway (made this mistake once). There are ways to make that happen, but they are not that fun to implement from what I have seen/can think of.

Hopefully that made sense.

There might be other ways that are better, but thats how I would do it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.