Adding SSLCommerz to your website, properly

SSLCommerz is the gateway most Bangladeshi businesses end up using, because it is the one that takes cards, bKash, Nagad, upay and internet banking through a single contract. Integrating it is not hard. Integrating it safely is where sites go wrong, and the failure is always the same shape: the website believes the customer's browser instead of the gateway's servers, and an unpaid order is marked paid.

Updated 19 September 2026

The short version

There are three calls, not one: create a session, receive the IPN notification, then call the validation API to confirm it.
Never confirm an order from the browser redirect alone. The redirect is a convenience for the customer; the IPN is the record.
Always re-check the amount and your own transaction ID against your own database before you deliver anything.
Sandbox and live are separate environments with separate store IDs, and your server must support TLS 1.2 or newer.

The two ways to show the payment page

SSLCommerz offers an embedded checkout, where the payment options appear inside your own page through their JavaScript, and a hosted checkout, where you redirect the customer to SSLCommerz and they come back afterwards.

The choice is cosmetic. Whichever you pick, the backend work is identical, and the backend work is the part that matters — the API calls must be made from your server, never from the browser, because anything the browser sends can be edited by the person sitting in front of it.

The three calls

Everything else is detail around these:

1. Create the session

Your server posts the order to SSLCommerz with your store ID and password, the total, your own unique transaction ID, and the URLs to send the customer back to on success, failure and cancellation. You also give an IPN URL. SSLCommerz returns a session, and you send the customer to the payment page.

2. Receive the IPN

When the payment finishes at the bank's end, SSLCommerz posts the result to your IPN URL — server to server, with no customer session involved. This arrives whether or not the customer's browser made it back to your site, which is precisely why it exists. It carries a status of VALID, FAILED, CANCELLED, EXPIRED or UNATTEMPTED, plus a validation ID.

3. Validate

Take the validation ID from the IPN and call the SSLCommerz order validation API from your server. Only what that call returns is authoritative. Until it says the transaction is valid for the amount you expected, the order is not paid.

The five mistakes

Every one of these has been shipped to production by somebody, and each one lets an order through unpaid.

Confirming the order on the success URL

The success URL is a page in the customer's browser. Anyone can open it directly. If landing on it is what marks the order paid, then typing the address is what marks the order paid.

Trusting the IPN without validating it

The IPN is a plain HTTP POST to a public URL. Treat its contents as a claim to be checked, not a fact. The validation API call is the check.

Not comparing the amount to your own record

Look up your transaction ID in your own database and confirm the amount and currency match what you asked for. If they do not, something has been tampered with, and the order should be held rather than fulfilled.

Processing the same notification twice

Notifications can arrive more than once. If your handler is not idempotent — if it blindly creates a booking each time — one payment becomes two rooms, or two despatched orders. Key it on your transaction ID and make a repeat a no-op.

Ignoring the risk flag

SSLCommerz returns a risk level with each transaction. A flagged transaction is not a decline; it is a request that you look before you hand over the goods. Sites that ignore it find out later, through a chargeback.

Details worth knowing before you start

Sandbox and live are separate

Different URLs and different store credentials. A depressing number of launch-day failures are a live site still pointing at the sandbox, or the other way round. Keep them in environment variables, never in the code.

There are per-transaction limits

SSLCommerz documents a minimum and a maximum amount per transaction. If you sell anything expensive — a long stay, a bulk order, a property deposit — check your ceiling before you design the checkout around it.

Record what you actually receive

The gateway reports both the amount the customer paid and the amount that will reach your account after the bank's commission. Your books should be built on the second one. Teams that record only the first spend their first reconciliation wondering where the money went.

TLS 1.2 or newer

SSLCommerz will not talk to an older server. On cheap shared hosting this is worth confirming before you write any code, not after.

Refunds are an API, not a phone call

There is a refund API and a transaction query API. If your staff will ever cancel a booking, wire them up now — otherwise every refund becomes a manual process somebody has to remember.

See it end to end

Our Aura Residences demo runs a complete hotel booking through a simulated SSLCommerz checkout, including the card that triggers an OTP step and the card that declines, so you can see what each path does to the booking. It is a demonstration rather than a live gateway — no real money moves — but the flow and the states are the real ones.

Try the booking and checkout demo See the payment states on their own

Questions we get asked

Do I need a company to get an SSLCommerz account?+

SSLCommerz is a merchant account, so they ask for business documents, bank details and a working website before approving a live store. You can register for a sandbox store immediately and build against it while the live application is in progress, which is what we normally do.

What does it cost?+

SSLCommerz sets a percentage per transaction under your own merchant contract, and it varies by payment method and by merchant. Get the rate card in writing directly from them — it is a permanent cost on every sale, and no developer can quote it for you.

Can I take bKash without SSLCommerz?+

Yes, bKash has its own merchant API. Whether that is worth a second integration depends on how much of your volume is bKash. Going through one gateway means one reconciliation and one support contact; going direct can mean a better rate on that method.

Our site already has SSLCommerz. How do I know it was done properly?+

Two questions will tell you. Ask whether the order is confirmed by the IPN or by the customer returning to the site, and ask whether the validation API is called. If nobody can answer, it is worth an audit before it costs you a chargeback.

Want this looked at for your own business?

A short call, no charge, and a straight answer about what it would take.

Book a scoping call