01
Confirmed, not assumed
The result is settled between us and the acquirer before it is written down as successful, and your server is told the same thing over the webhook rather than over the customer's connection.
Payment gateway
Eleven ways to pay. One integration.
Cards and mobile wallets, live today, behind one hosted checkout and one REST API. Your customer picks how to pay; you get one place to watch it, one settlement, and one record per payment that still answers a question months later.
Live today
Cards
Mobile Banking
- Currency Bangladeshi Taka only.
- Fees A percentage of each successful transaction. No setup fee, no monthly fee, no annual fee.
- Not offered There is no bank-transfer or internet-banking method.
The mechanism
How a payment runs
Four steps, and only two of them are yours to build.
-
01
Your server creates a session
One authenticated POST — the amount, your order reference, where to send the customer back. It returns a checkout URL. Your API key travels in a header; nothing about the payment is decided in the browser.
-
02
The customer pays on our page
Redirect them to that URL. The card form is ours, on our domain, so card details never reach your servers and there is nothing on your side to build or to secure.
-
03
We confirm it with the acquirer
A customer returning to your site is not proof that money moved. The outcome is confirmed against the acquirer or the wallet before a transaction is marked successful.
-
04
Your server hears it on a signed webhook
HMAC-SHA256 over a timestamped payload, in an X-Webhook-Signature header you verify. If your endpoint is down the delivery retries with backing-off gaps, and every attempt is kept as a record you can read.
Why it holds up
We hold the bank integrations ourselves
Most gateways in this market resell one aggregator's connection. We built and run the card connections to four acquiring banks, and a separate direct integration to each of the five mobile wallets.
-
Fewer hands between you and the money
Your payment reaches the acquirer through our own integration, not through a reseller sitting in front of another gateway. That is one less party who can be the reason a payment did not arrive — and one less to wait on when you need an answer.
-
A failure is ours to diagnose
When something breaks we read our own logs against the acquirer's response instead of opening a ticket with an intermediary. You are talking to the people who wrote the integration.
-
One acquirer having a bad day is not your outage
Because each connection is separate, a problem at one bank stays at one bank rather than taking every card on your checkout down with it.
One trunk, separate lanes. The banks are unlabelled on purpose — who we acquire through is a commercial matter, not a marketing claim.
The other half of the job
What happens after the customer pays
A gateway is judged on the part that happens once the checkout page has closed. This is ours, stated plainly.
02
Settled on your agreed cycle
Which of the two is set out in your merchant agreement. Each release is reviewed and completed by our operations team rather than fired automatically, so bank holidays, bank cut-offs and any open review on your account can push it to the later end.
03
One row answers one question
Every payment keeps its own reference, the acquirer's reference and the processor's raw response, with an audit trail beside it. When a bank asks about a single transaction eight months later, there is one row that answers it — and you can re-run reconciliation on it from the dashboard.
04
Reports your finance team can open
Transaction and settlement reports download as PDF, and the transaction report also comes out as CSV. Files, not screenshots of a dashboard.
Beyond the checkout page
Five ways to ask for money, one place to watch it
Not every payment starts on a product page. The same account, the same settlement and the same reports sit behind all of these.
Ways to take a payment
-
Hosted checkout
The default. One API call, one redirect, every method on one page.
-
Your payment link
A single link you can put in a bio, a message or a printed order form. One per merchant account — one link, not a set of them.
-
Payment invoices
Bill a named customer for a named amount. Raise them one at a time, in bulk from a spreadsheet upload, or on a repeating schedule.
-
Subscriptions
Recurring plans with the awkward part handled: a renewal that fails is retried after four hours, then a day, then three days, before the subscription is marked past due.
-
Card EMI
Instalments on supported issuing banks, chosen by the customer at checkout.
In the merchant dashboard
-
Every transaction, searchable
By reference, by method, by status, by date — with the processor's own response attached to each one.
-
Settlement tracking and reports
What has been released, what is still to come, and downloadable statements behind both.
-
Re-run a reconciliation
Ask us to check a specific transaction against the processor again, from the transaction itself.
-
Email and SMS to your customer
Payment notifications go out on both channels, so a buyer is not left wondering whether it went through.
For the people integrating
A plain API, and libraries only where they help
We publish five libraries because they save real time. Everything else is an HTTP call you already know how to make.
-
A plain HTTPS REST API
JSON in, JSON out, key in a header. No proprietary client is required and nothing needs installing to make the first call.
-
A sandbox before you have an account
Create sessions and run payments end to end without moving real money. Going live means swapping the key; the endpoints and the payloads do not change.
-
Webhooks you can actually verify
Signed, timestamped, retried when your endpoint is down, and every delivery attempt is recorded rather than lost.
Official libraries
- PHP Packagist
- Node.js npm · beta
- WooCommerce plugin
- WHMCS module
- Laravel example app
No library is required. The API is the contract.
Getting started
Going live
Two tracks that run in parallel: your developers build against the sandbox from day one while the merchant account is reviewed.
-
01
Build against the sandbox today
Sign up, generate test keys, integrate. Nothing in this step waits on a contract or a sales call.
-
02
Send your merchant application
Business registration, tax details, ownership, identity documents for your authorised representative, your website or app, bank account details, and what you sell.
-
03
Swap the test key for a live one
The integration does not change. Same endpoints, same webhook contract — you replace the key and start taking real payments.
We do not publish a fixed approval time. How long a review takes depends on how complete your documents are, your business type, whether your site or app is ready to look at, and checks by our banking partners — so we would rather tell you where yours stands than quote an average.
What it costs
You are charged when you get paid
A percentage of each successful transaction, set by the method the customer chose — a wallet and an Amex card do not cost the same, so we publish a rate for each rather than one blended number. Nothing is charged for a payment that did not go through, and there is no setup, monthly or annual fee.
See the rate cardFive attempts, four charges. The one that failed costs nothing.
Who we answer to
Licensed, certified and accountable
-
Payment Service Operator
Licensed by Bangladesh Bank under its regulatory framework for payment service operators.
-
ISO 27001:2022
Certified for information security management.
-
e-CAB membership 1032
Member of the e-Commerce Association of Bangladesh.
-
BASIS membership AS-20-02-822
Member of the national association of software and IT-enabled service companies.
Have Questions? Let's Talk!
Book your free 15-minute consultation with our payment experts.