What it takes
A gateway integration is a session-open call, a notification handler and a settlement that is idempotent under the same lock the existing one uses. The surface is small because the rest of billing does not change.
How a taka reaches your account
The local page. Which gateway is integrated, how bKash and Nagad are actually reached, whose merchant account the settlement lands in, and what adding a new rail costs — written narrowly, because a payment claim is a claim about code.
One integration, and the honest shape of it
SSLCommerz is the gateway that is integrated. The platform opens a payment session against it, hands the viewer to the gateway's own page, and settles the transaction when the notification comes back. That code is written, deployed and covered by a verification playbook that checks the settlement lock in the source that is actually running.
bKash, Nagad and cards are reached through that aggregation rather than as direct integrations, and the distinction matters enough to write it on the page. A viewer paying with bKash sees bKash and it works; what does not exist is a direct relationship between this platform and bKash, and a page claiming one would not survive a technical due-diligence call.
Your merchant credentials are configured during onboarding. The integration is built and waiting on an account that has to be yours, because the settlement has to land in it.
Rails, and what each one really is
| Rail | How it is reached | Status |
|---|---|---|
| SSLCommerz | Direct integration in the billing service | Built; your credentials at onboarding |
| bKash | Through SSLCommerz aggregation | Available that way; no direct integration |
| Nagad | Through SSLCommerz aggregation | Available that way; no direct integration |
| Cards — Visa, Mastercard | Through SSLCommerz aggregation | Available that way; no acquirer relationship here |
| Stripe, PayPal, other non-BD gateways | Not integrated | No code; a build against a published API |
| Carrier billing | Not integrated | See the telco page — a different order of work |
What the platform does and does not touch
The platform never holds funds and there is no revenue share, because there is no mechanism for one. It names a price, opens a session at the gateway, and records what came back. Settlement is between the gateway and your merchant account.
A price is never taken from the buyer. For a subscription the amount comes from the plan row; for a one-off purchase it is resolved from the service that owns the item immediately before the session is created. A client that posts its own amount is ignored, which is what makes the checkout an instruction rather than a suggestion.
Settlement is idempotent. The notification handler reads the pending record under a row lock, so a gateway that delivers the same notification twice — which they do — settles it once. Every payment attempt survives as a row with a state, so a transaction that failed is a fact you can read rather than an absence you have to infer.
Adding a rail you already use
What decides the estimate
Whether the gateway has a published API and a sandbox, whether it notifies or expects polling, and whether refunds are in scope. The integration is rarely the hard part; the reconciliation usually is.
What it is not
It is not a setting, and we will not describe it as one. A gateway that is not in the table above has no code here, and that stays true until it does.
Questions
Is bKash supported?
Through SSLCommerz aggregation, yes — a viewer can pay with bKash. There is no direct bKash integration in the platform, and we write it that way deliberately: the difference is invisible to your viewer and very visible in a technical review.
Whose merchant account does the money go into?
Yours. The credentials configured at onboarding are your own, settlement goes to your account, and the platform is not in the funds path at any point.
Do you take a cut of transactions?
No. There is no revenue-share mechanism in the billing service to take one with.
What if the gateway sends the same notification twice?
It settles once. The handler reads the pending record under a row lock, and a verification playbook asserts that lock is present in the deployed source rather than trusting that it was written.
Already have a merchant account?
Then most of this is configuration rather than work. Send us which gateway and we will tell you whether it is a credential or a build.