Nagad Payment Integration: Merchant Onboarding and Technical Questions

Header image: conceptual illustration.

Nagad is a major mobile financial service in Bangladesh, and many merchants add it alongside bKash. Official information is on Nagad's website, and MFS regulation is published by Bangladesh Bank. This guide lists the onboarding and technical questions merchants should raise. Specific requirements and technical details come from Nagad or your aggregator's documentation; ask for the current version.

Onboarding questions

• Is my business type eligible, and can a non-Bangladeshi entity be onboarded directly or only via an aggregator?
• Which documents are required (for local entities, typically trade licence, registration and bank details)?
• Which products are available: online checkout, in-app, refunds, payouts?
• What settlement schedule and bank apply?
• Who is my support and escalation contact?

Technical questions

1. Documentation and sandbox. Request the current API documentation and sandbox credentials.
2. Authentication and signing. How are requests signed or encrypted, and how are keys rotated? Keep keys server-side.
3. Flow. What is the sequence from initialising a payment to customer authorisation and completion?
4. Callbacks. How are results delivered, and how do I verify them?
5. Status verification. Is there an endpoint to confirm the final status before I mark an order paid?
6. Duplicates. How does the API treat a repeated order ID? Keep your own rule regardless: one active attempt per order, a new attempt only after the previous one definitively failed or expired, and at most one paid attempt (idempotency).
7. Refunds. Full/partial, API or manual, timelines.
8. Reports. Transaction and settlement exports with unique IDs.

Implementation tips

• Store the Nagad transaction reference alongside your order ID.
• Map statuses to your internal model (`pending`, `succeeded`, `failed`, `expired`, `reversed`).
• Check status for any payment pending beyond your threshold.
• Show customers clear messages; never ask for wallet PIN or OTP in your own interface.

Hypothetical test list

*Example only.* Success; customer cancels; timeout during completion; duplicate submission; callback delivered twice; refund. Each should leave one consistent record.

Reconciliation

Daily, compare paid orders with Nagad transaction reports and settlement totals. Investigate any "paid at provider, not marked paid" item first, because the customer is waiting.

What Nagad is

Nagad is a mobile financial service operating under the Bangladesh Post Office, widely used for peer transfers, bill payments and online merchant purchases. For merchants it is a wallet rail: the customer authorises a debit from their Nagad balance and the merchant receives a confirmation callback.

Bangladesh runs on mobile financial services. A customer who has never held a card will still have a wallet balance topped up at an agent point, and that wallet is the default way they pay online.

How the flow works

1. Customer selects Nagad at checkout and the merchant creates a transaction with a unique reference.
2. The customer is taken to the Nagad authorisation step and confirms with their PIN or in-app approval.
3. A callback is delivered to the merchant's webhook endpoint with the terminal state and a rail reference.
4. The transaction is included in the day's settlement batch and appears on the reconciliation statement.

Timing and confirmation

Confirmation is normally within seconds, but callbacks can lag under network congestion. Treat anything without a terminal state as pending rather than failed and let the status endpoint resolve it.

Average ticket sizes are small and frequent, so approval rate and confirmation speed matter far more than the headline fee.

Limits and ticket sizes

Customer wallet balances and per-transaction limits cap ticket size, so higher-value purchases usually need a bank rail alternative on the same checkout.

This is why most Bangladeshi checkouts present a wallet option and a bank option side by side rather than choosing one. Coverage for the full Bangladesh method set is described on the Bangladesh Payment Gateway page.

Common integration mistakes

• Marking a transaction failed on timeout instead of leaving it pending.
• Not storing the Nagad rail reference, which makes refunds and disputes hard to match.
• Assuming bKash logic transfers unchanged — the state semantics differ.
• Hiding the bank transfer option, which loses the higher-value segment.

Merchant benefits

• Nagad acceptance through the same API as every other Bangladesh method
• Signed webhooks with idempotency and replay safety
• Line-level reconciliation data for finance teams
• Fallback routing when an upstream connection degrades

Related guides and solutions

• Bangladesh Payment Gateway
• High Risk Payment Solution Bangladesh
• bKash Payment Gateway
• Nagad Payment Gateway
• Solutions overview
• Cross-Border Payment Solutions
• Payment Infrastructure
• High-Risk Merchant Payment Processing
• Countries hub

Frequently asked questions

Can I reuse my bKash integration code?

The business logic and status model can be shared; the API calls and signing are provider-specific.

Should I integrate directly or through an aggregator?

Direct gives more control; an aggregator reduces integration work. Compare contracts and support.

Related: bKash vs Nagad for merchants and our Nagad payment gateway page.

Is Nagad suitable for large transactions?

Not usually. Wallet limits mean larger amounts are better routed to bank transfers, which is why merchants normally offer both.

Can Nagad payments be refunded?

Refund handling depends on the configured flow; storing the rail reference on every collection is what makes a refund or dispute traceable.

Sources

• Nagad: https://nagad.com.bd/
• Bangladesh Bank: https://www.bb.org.bd/