Four rails · one ledger

bKash, Nagad, card, COD — reconciled.

Every taka settles against an order. Refunds, courier collections and payouts write to the same ledger, so nothing depends on a spreadsheet at month end.

See the rails Read the settlement docs

bKashNagadRocketUpayCard (Visa / Mastercard / Amex)Cash on delivery

The four rails

Four structurally different payment behaviours, one ledger.

Each rail is a first-class object with its own authorisation flow, failure surface and refund path — but every rail writes to the same order and ledger schema.

bKash, Nagad, Rocket, Upay

The default for most baskets.Hosted or in-app checkout, webhook-confirmed, refund-to-wallet supported.

Card (Visa / Mastercard / Amex)

Runs on your existing merchant account.3-D Secure, chargeback events post to the order timeline.

Bank transfer (BEFTN / RTGS)

The rail procurement teams ask for.Redirect or manual reference match; settlement is bank-cleared, not instant.

Cash on delivery

Treated as a real method, not an exception.Fraud scored pre-booking, courier-collected, remittance reconciled.

Which rail should I lead with?

Rail comparison — the table to bring into a finance conversation.

Payment rail comparison: settlement, failure modes, refunds, reconciliation
Payment rail comparison: settlement, failure modes, refunds, reconciliation	Settlement timing	Common failure modes	Refund path	Reconciliation difficulty	Best-fit basket size
bKash / Nagad / Rocket / Upay	Near-real-time confirmation; payout per your MFS cycle (commonly T+1 to T+3 — confirm with your provider)	PIN timeout, app-switch drop, insufficient balance, duplicate submission on slow networks	Refund-to-wallet via the same rail, usually 1–3 business days	Low — webhook gives a hard match to transaction ID	Low to mid ticket, high frequency
Card (Visa / Mastercard / Amex)	Authorised instantly; settlement per your acquirer's cycle (commonly T+1 to T+5)	3-D Secure abandonment, issuer decline, expired card, OTP timeout	Refund to card, 5–14 business days depending on issuer	Medium — needs processor reference reconciled against gateway callback	Mid to high ticket
Bank transfer (BEFTN / RTGS)	Bank-cleared, typically same-day to T+2 depending on bank cutoff	Wrong reference number, delayed batch clearing, redirect drop-off	Manual bank transfer back, days not minutes	High — often needs a human to match a bank statement line to an order	High ticket, B2B, wholesale
Cash on delivery	Cash collected on delivery; remitted by courier per their cycle (commonly weekly or twice-weekly)	Customer refusal at door, unreachable address, wrong address, partial acceptance	Non-event on accepted orders; on refusal, order reverts to unpaid/returned	High — depends entirely on courier remittance reports matching your order set	Low to mid ticket, price-sensitive segments

Numbers are typical ranges reported by merchants and PSPs operating in Bangladesh — confirm exact settlement cycles and MDR with your bKash/Nagad merchant agreement and your card acquirer, since terms vary by account tier.

If your average order value is under roughly BDT 1,000 and your audience is mobile-first, lead with MFS and keep COD as the fallback. Above roughly BDT 10,000 or with institutional buyers, expect bank transfer to carry a disproportionate share of revenue — build reconciliation around its slower, human-matched settlement rather than assuming it behaves like MFS. If COD exceeds roughly 40–50% of order volume, the risk playbook below is not optional.

The reconciliation engine

Reconciliation is the actual product here.

Not the checkout button. Every payment event writes an immutable row keyed to a rail transaction reference and an order ID — nothing is inferred from a total.

Idempotency keys prevent double-counting — a retried webhook is recognised and discarded, never credited twice.
Webhook retries are handled on both sides: the rail retries per its own backoff, and Framique's queue also polls the gateway's status API as a fallback.
Unmatched-taka queue: any settlement that cannot be matched automatically lands in a visible, owned, aged queue with the raw evidence attached.

Exception queue with an owner and an age.

1Rail webhook

2Idempotency check

3Order match

4Ledger row

5Exception queue (if unmatched)

A merchant processes 800 orders in a week — 500 bKash, 150 card, 50 bank transfer, 100 COD. In a spreadsheet process, the 50 bank transfers eat the most finance time (about 2.5 hours a week at 3 minutes per match) for 6% of order volume. Framique auto-matches the clean references and routes only the genuinely ambiguous ones to the unmatched-taka queue — cutting the manual load to roughly 15 minutes a week.

One refund, four consistent records.

A refund updates the order status, the payment record, the ledger and the customer's order timeline in one transaction — a refund that updates the ledger but not the order is exactly how merchants end up with support tickets that contradict their own accounting.

Full refunds reverse the original payment via the same rail where it supports reversal; where it doesn't, Framique tracks it as a manual-payout obligation until settled.
Partial refunds apply against the specific order line, so product-level margin and return-rate reporting stays accurate down to the SKU.
A partial refund on a BDT 3,500 order for one BDT 800 line item reduces recognised revenue to BDT 2,700 and flags only that SKU in returns analytics.

One transaction, four consistent records.

Typical refund time by rail
Typical refund time by rail	Typical refund time
bKash / Nagad / Rocket / Upay	1–3 business days
Card (Visa / Mastercard / Amex)	5–14 business days (issuer-dependent)
Bank transfer (BEFTN / RTGS)	Manual, days
Cash on delivery	N/A — unpaid orders simply revert

Scored before the courier is booked.

The costliest fraud event in Bangladeshi e-commerce isn't a stolen card — it's a COD order that ties up a courier slot, packaging and staff time, then gets refused. Framique scores every order for risk before booking, so a bad order costs a review-queue click, not a wasted delivery attempt.

Start at the default threshold and let two to four weeks of real order volume pass through untouched.
If false positives exceed roughly 20% of flagged orders, loosen the weakest-signal contributors first — usually basket anomaly.
If fraud is still reaching courier booking, tighten velocity and address-quality weights before adding new signals.
Re-check quarterly — fraud patterns shift with seasonal demand (Eid, Pohela Boishakh peaks).

Review queue instead of a lost parcel.

Velocity — orders from one phone, device or address in a rolling window
Blacklist match — your own repeat-refuser list or an opted-in shared list
Address quality — deliverable and specific, not vague or incomplete
Basket anomaly — value or item mix well outside the usual pattern
Device / network signal — known VPN, datacenter IP, device reuse
Honeypot fields — hidden fields a bot fills and a human never does
Channel signal — unusually rapid, scripted-looking checkout completion

COD risk management — five levers

OTP confirmation before dispatch

An SMS code confirmed by the customer before the order ships cuts fake and impulsive orders — a customer who won't confirm rarely intended to accept the parcel.

Address quality checks

Structured fields (division, district, thana, landmark), cross-checked against your courier's serviceable-area list before confirmation.

Repeat-refuser lists

Every refused delivery is logged against phone and address. Crossing a threshold routes that identity to prepayment-required, not an outright block.

Prepayment nudges

A small discount or free-shipping incentive at checkout to switch COD selections to MFS, lowering refusal-exposed order share.

Partial advance

For higher-ticket COD orders, a small non-refundable advance via MFS before dispatch filters out low-intent orders.

Worked example — return-rate impact on margin

Worked example — return-rate impact on margin
Worked example — return-rate impact on margin	Before playbook	After playbook (refusal cut to 8%)
Weekly COD order value	BDT 50,000	BDT 50,000
Refusal rate	20%	8%
Value lost to refusals	BDT 10,000	BDT 4,000
Direct wasted delivery cost (≈ BDT 120/attempt)	≈ BDT 4,800 (~40 refused orders)	≈ BDT 1,920 (~16 refused orders)
Weekly saving from the playbook	—	≈ BDT 2,880

Assumptions (average ticket, per-attempt cost, starting refusal rate) vary by category and courier contract — rerun this table with your own numbers. The reusable part is the calculation structure: refusal rate × order volume × per-attempt cost.

Chargebacks and disputes

Card chargebacks and MFS dispute cases are rarer in Bangladesh than in mature card markets, but they follow the card network's or provider's own process — Framique does not adjudicate disputes, since that authority sits with your acquirer or the rail provider.

Posts every chargeback or dispute notification your processor sends as a timeline event on the affected order.
Surfaces the evidence you already have — delivery confirmation, OTP timestamp, proof-of-delivery — in one place to respond to your processor.
Flags the customer identity for review on future orders if a dispute is upheld against you, feeding the same repeat-refuser mechanism used for COD risk.

Checkout — fewest fields, phone-first identity

Fewest fields, phone-first identity.

Name, phone, structured address, payment method. Email is optional — a large share of COD and MFS customers don't treat email as their primary contact channel, and making it mandatory adds a drop-off point for no reconciliation benefit.

Phone-first identity: it's how the customer pays, how the OTP reaches them, how the courier reaches them, and how repeat-customer recognition works.
Bangla numerals (০–৯) as a per-store locale setting, not inferred from browser locale alone.
Structured address fields (division → district → thana → detail line) improve delivery accuracy and feed the address-quality fraud signal automatically.

Checkout field checklist
Checkout field checklist	Required?	Why
Full name	Yes	Delivery label, order record
Phone number	Yes	Payment identity, OTP, courier contact
Division / District / Thana	Yes (structured)	Delivery accuracy, fraud signal
Detailed address line	Yes	Delivery accuracy
Email	No	Optional receipt delivery only
Payment method	Yes	Rail selection
Order note	No	Optional, e.g. landmark or instruction

PCI, keys, tokens — named, not hyped

Framique does not store raw card numbers on its own servers. Card entry is tokenised by your PCI-DSS-compliant gateway at the point of entry, and Framique stores and operates on the resulting token — the standard pattern for keeping a merchant's own PCI scope minimal (typically SAQ-A or SAQ-A-EP-equivalent; confirm with your acquirer or QSA).

Scoped API keys (read-only, write, webhook-signing) rather than one master key — a leaked read-only key cannot issue refunds or move payouts.
Webhook payloads are signed and verified on every inbound rail webhook before the contents are trusted.
Payment credentials in transit are TLS-encrypted; tokens and reference IDs at rest are encrypted; payments-module access is permissioned separately from general store admin access.

Key scopes

readView orders, payments and ledger rows
writeCreate orders, issue refunds
webhook-signingVerify inbound rail webhooks only

Built for your accountant, not just your dashboard.

Every rail's incoming payments and every payout to your bank account are logged as ledger events, exportable in the format your accountant actually needs.

CSV export per period (day/week/month/custom range) and per rail — order ID, rail transaction reference, gross, fee, net, settlement date.
API export for accounting systems that pull data programmatically rather than via manual upload.
Payout summary view: for each bank deposit, the exact set of orders that sum to that amount.
Framique surfaces the transaction-level data your accountant needs for VAT/mushak filings, but does not determine VAT treatment or generate mushak challans itself — confirm with your accountant or current NBR guidance.

Every bank deposit ties back to named orders.

Built for developers

Integrating Framique payments into a custom storefront, a headless frontend, or an existing ERP — the payments module is fully addressable via the REST API.

GET /orders/{id}/payments
Full payment event history for an order — rail, status, amounts, timestamps.
POST /payments/{id}/refund
Trigger a full or partial refund; accepts a line-item breakdown.
payment.confirmed · payment.failed · refund.completed · reconciliation.exception_created
Webhook subscriptions — the last lets you build your own alerting on the unmatched-taka queue.
Idempotency-Key header
Supported on all mutating endpoints — your integration can safely retry without double-processing.
Sandbox mode
Simulated MFS/card/COD flows for integration testing before going live.

/docs/payments — full API reference /docs/webhooks — signature verification and retry semantics /docs/reconciliation — ledger schema and the unmatched-taka queue

Frequently asked

Do you hold my money?

No. Rails settle to your own bKash/Nagad/bank/acquirer accounts directly; Framique records and reconciles those settlements against your orders — it does not sit in the custody chain.

Which processors do you support for cards?

Any processor or acquiring bank you already hold a merchant account with, connected through Framique's gateway integration layer. Framique does not require you to switch acquirers.

How are COD returns and refusals handled?

A refusal or return posts against the original order and the courier trip that carried it, so your return rate is a measured figure from real events, not an estimate from a spreadsheet.

Can I export the ledger for my accountant?

Yes — CSV or API, filterable by period and by rail, with a payout-to-order tie-out view.

What happens if a webhook from bKash or my card gateway is delayed or lost?

Framique relies on the rail's own retry mechanism plus a status-polling fallback, so a single missed webhook does not leave an order stuck.

Do you support partial refunds on multi-item orders?

Yes, at the line-item level — a partial refund updates only the affected SKU's revenue and returns figures, not the whole order.

How is COD fraud actually reduced, not just detected?

Through the combination of OTP confirmation, structured address validation, a repeat-refuser list, prepayment nudges toward MFS, and optional partial advance on higher-ticket orders — used together, not any single measure alone.

Do you store card numbers?

No. Card entry is tokenised by your PCI-DSS-compliant gateway; Framique stores and operates on the token, not the raw card number.

How do chargebacks get handled?

The dispute process itself runs through your acquirer or the rail's own scheme rules; Framique surfaces every dispute event on the order timeline and centralises the evidence you need to respond.

Can I adjust fraud-scoring thresholds myself?

Yes — thresholds are merchant-configurable, not fixed platform-wide, because risk tolerance differs meaningfully by category and average order value.

Connect bKash today, take an order tonight.

Card and COD can follow in the same setup flow. Reconciliation starts on your first order, not your hundredth.

Start free — no card Talk to sales