SSLCommerz payments for a multi-hotel booking platform

How SSLCommerz checkout works

The flow has four steps. Everything that involves your store password happens on your server, never in the browser.

1. Start a session. Your server sends the amount, currency, your own transaction ID and three return addresses (success, fail, cancel) to the session API, along with your store ID and password. An IPN address is strongly recommended too.
2. Send the guest to pay. The response includes a GatewayPageURL. Redirect the guest there to choose a card, mobile banking or another method.
3. Hear back twice. The guest's browser comes back to your success, fail or cancel page, and SSLCommerz separately posts the result to your IPN address, server to server.
4. Validate before you confirm. Call the validation API with the val_id you received. Confirm the booking only if the transaction ID is yours, the amount and currency match what you charged, and the status is VALID or VALIDATED.

Sandbox and live use different hosts (sandbox.sslcommerz.com and securepay.sslcommerz.com), so keep the host in configuration rather than in code. Check SSLCommerz's own developer docs for the current details — this summary follows their v4 docs as of September 2026.

1. One merchant account per hotel, one payment handler

Each hotel has its own SSLCommerz merchant account, so each hotel's money goes to the right place. The tempting shortcut is to copy the payment code into every hotel's site. Instead, one payment handler takes the hotel as a parameter and picks that hotel's credentials — so success, failure and cancellation each send the guest back to their own hotel, with the booking and room inventory updated.

Copies drift. On this platform, one hotel's site had been deployed from another property's build and carried the wrong identity. Adding the next hotel is now configuration, not another copy.

2. Reserve the room only after the gateway answers

The original flow created the reservation first and then asked for a payment page. When the gateway refused, an unpaid booking was left behind, holding a room nobody had paid for. Now the booking asks the gateway for a payment page first, and only creates the reservation when one comes back.

3. Tell the guest the real reason

A refused payment used to show a generic error. The gateway usually says why it refused, so pass that reason on in plain words. A guest who knows what went wrong can fix it and try again; a guest who sees "Something went wrong" often leaves.

Let guests choose how much to pay now

Each hotel's booking site offers full payment or 50% in advance, with a live price summary before the guest goes to the gateway. The amount you send when starting the session is the amount you check again during validation.