Hosted checkout
A fast, mobile-first payment page in English and Bangla. If a customer refreshes, goes back or opens two tabs, they are still charged only once.
Sandbox open. No real money moves yet.
Payments that always add up
X-Pay takes payments for Bangladeshi businesses and tracks every poisha from checkout to bank payout, on a ledger that has to balance before anything moves.
Test every outcome, including the ones that go wrong.
Order TERM-1042BDT 1,000.00
Sample data
-
Verified with the providerSignature and amount checked
-
Booked in the ledgerDouble entry, one time only
-
Merchant notifiedSigned webhook delivered
-
Matched to bank statementProvider and bank agree
-
Settled to the merchantConfirmed by the bank
| Journal entry | Debit | Credit |
|---|---|---|
| Provider receivable | 1,000.00 | |
| Merchant payable | 975.00 | |
| Fee revenue (sample 2.5%) | 25.00 | |
| Balanced | 1,000.00 | 1,000.00 |
Poisha
Money is stored as whole poisha. No rounding drift, ever.
2 people
Payouts, fee changes and bank account changes need a second approver.
0 card numbers
Customers pay on the provider's hosted page. We never see card data.
20 scenarios
A release test matrix for the failures that cost real money.
Features
Everything between "pay now" and money in the bank
One system for taking payments, handling what goes wrong and paying merchants out.
Three-way reconciliation
Our records, the provider's report and the bank statement are compared every day. Merchants become payable only when all three agree. Differences go to a queue that two people resolve.
Refunds
Full or partial, never more than was paid. Large refunds need a second person.
Disputes
Deadlines, reminders and evidence upload, with the disputed amount held automatically.
Bank payouts
Daily batches with a cut-off and holiday calendar. A payout counts as paid only when the bank shows it.
Signed webhooks
Every event is signed and retried for up to 24 hours, with a delivery log you can resend from.
Team access
Give each person only what they need, down to a single store. Two-step sign-in included.
Reports and statements
Opening balance, every movement, closing balance. Export it for your accountant.
Links and invoices
No website? Send a payment link or invoice. Opening it twice never creates a second payment.
Fees and reserves
Versioned fee schedules, with the fee frozen on each payment. Later changes never re-price old orders.
How it works
Five steps. Each one proves the last.
Customer pays
Your server creates a session; the customer pays on the hosted page.
We verify
A browser redirect proves nothing. Only a verified provider answer counts.
We book it
One balanced journal entry, however many times the provider calls back.
We reconcile
Provider report and bank statement are matched against the ledger.
You get paid
Approved by two people, sent to your bank, confirmed by the statement.
Who it is for
One system, three ways in
Merchants
See your money clearly
- Pending, available and on-hold balances, explained
- Payment links and invoices without any code
- Refunds and dispute evidence from one panel
- Statements your accountant can actually use
Developers
An API built for retries
- Idempotency keys on every POST
- A sandbox that simulates timeouts, late callbacks and wrong amounts
- Signed webhooks, OpenAPI document and a PHP SDK
- Clear errors, each with what to do next
# Create a payment session
curl -X POST "$XPAY/api/v1/payment-sessions" \
-u "$KEY_ID:$SECRET" \
-H 'Idempotency-Key: session-ORDER-1001' \
-H 'Content-Type: application/json' \
-d '{
"merchant_order_id": "ORDER-1001",
"amount_minor": "100000",
"currency": "BDT",
"description": "School fees",
"return_url": "https://shop.example.com/done"
}'Finance and operations
Controls you can show an auditor
- Append-only ledger: corrections are reversals, never edits
- Maker and checker on every money decision
- Kill switches that stop new money but keep resolving old money
- Hash-chained audit trail of who did what, and when
Security
Designed to be hard to get wrong
The rules live in the database as well as the code, so a bug cannot quietly link one merchant's money to another's or rewrite a journal.
Two-step sign-in
Mandatory for staff. Sensitive actions ask you to confirm it is you again.
Encrypted secrets
Customer details and credentials are encrypted at rest, with rotating keys.
Tamper-evident audit
Append-only events, exported in a hash chain and verified daily.
Kill switches
Pause payments, refunds or payouts in seconds during an incident.
Merchant isolation
Enforced by database keys, so one merchant can never reach another's data.
Restores that cannot resend
A restored copy starts locked and cannot move money until its ledger checks out.
Status
Where X-Pay stands today
Software being finished is not the same as being ready for real money. Here is the honest picture.
-
You are here
Sandbox
The whole system works against a built-in payment simulator. No real money.
-
Ahead
Approvals
Licensing, partner agreements, certification, security and accounting reviews.
-
Ahead
Controlled pilot
A small group of merchants with low limits and a daily finance review.
-
Ahead
General launch
Limits rise only after each recorded review of the pilot's results.
Planned payment channels, once partner agreements are signed: bKash, Nagad, Rocket and bank cards. None is connected yet.
Try every way a payment can go wrong
Create a sandbox account and run real scenarios: timeouts, late callbacks, refunds and disputes. No real money involved.