Framique
ফ্রি ট্রায়াল
চারটি রেল · একটি লেজার

বিকাশ, নগদ, কার্ড, সিওডি — মিলিয়ে দেখা যায়।

প্রতিটি টাকা একটি অর্ডারের সাথে মিলে যায়। রিফান্ড, কুরিয়ার কালেকশন আর পেআউট একই লেজারে লেখা হয়।

রেলগুলো দেখুনসেটেলমেন্ট ডকুমেন্ট দেখুন

বিকাশনগদরকেটউপায়কার্ডক্যাশ অন ডেলিভারি

চারটি রেল

চারটি ভিন্ন পেমেন্ট আচরণ, একটি লেজার।

প্রতিটি রেলের নিজস্ব অথরাইজেশন ফ্লো, ব্যর্থতার ধরন ও রিফান্ড পথ আছে — কিন্তু সবাই একই অর্ডার ও লেজার স্কিমায় লেখে।

বিকাশ, নগদ, রকেট, উপায়

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

কার্ড

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

ব্যাংক ট্রান্সফার

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

ক্যাশ অন ডেলিভারি

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

কোন রেল দিয়ে শুরু করব?

রেল তুলনা — অর্থ বিভাগের আলোচনায় আনার টেবিল।

পেমেন্ট রেল তুলনা
পেমেন্ট রেল তুলনাসেটেলমেন্ট সময়সাধারণ ব্যর্থতারিফান্ড পথমিলকরণের কঠিনতাউপযুক্ত বাস্কেট সাইজ
বিকাশ / নগদ / রকেট / উপায়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 networksRefund-to-wallet via the same rail, usually 1–3 business daysLow — webhook gives a hard match to transaction IDLow to mid ticket, high frequency
কার্ডAuthorised instantly; settlement per your acquirer's cycle (commonly T+1 to T+5)3-D Secure abandonment, issuer decline, expired card, OTP timeoutRefund to card, 5–14 business days depending on issuerMedium — needs processor reference reconciled against gateway callbackMid to high ticket
ব্যাংক ট্রান্সফারBank-cleared, typically same-day to T+2 depending on bank cutoffWrong reference number, delayed batch clearing, redirect drop-offManual bank transfer back, days not minutesHigh — often needs a human to match a bank statement line to an orderHigh ticket, B2B, wholesale
ক্যাশ অন ডেলিভারিCash collected on delivery; remitted by courier per their cycle (commonly weekly or twice-weekly)Customer refusal at door, unreachable address, wrong address, partial acceptanceNon-event on accepted orders; on refusal, order reverts to unpaid/returnedHigh — depends entirely on courier remittance reports matching your order setLow 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.

রিকনসিলিয়েশন ইঞ্জিন — প্রতিটি টাকা একটি অর্ডারের সাথে মিলে যায়

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.
রেল অনুযায়ী রিফান্ড সময়
রেল অনুযায়ী রিফান্ড সময়রিফান্ডের সময়
বিকাশ / নগদ / রকেট / উপায়1–3 business days
কার্ড5–14 business days (issuer-dependent)
ব্যাংক ট্রান্সফারManual, days
ক্যাশ অন ডেলিভারি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

সিওডি ঝুঁকি ব্যবস্থাপনা — পাঁচটি ধাপ

1

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.
2

Address quality checks

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

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.
4

Prepayment nudges

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

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প্লেবুকের আগেপ্লেবুকের পরে (৮% এ নেমে আসা)
Weekly COD order valueBDT 50,000BDT 50,000
Refusal rate20%8%
Value lost to refusalsBDT 10,000BDT 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.

চেকআউট — সবচেয়ে কম ফিল্ড, ফোন-প্রথম পরিচয়

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.
চেকআউট ফিল্ড চেকলিস্ট
চেকআউট ফিল্ড চেকলিস্টআবশ্যক?কেন
Full nameYesDelivery label, order record
Phone numberYesPayment identity, OTP, courier contact
Division / District / ThanaYes (structured)Delivery accuracy, fraud signal
Detailed address lineYesDelivery accuracy
EmailNoOptional receipt delivery only
Payment methodYesRail selection
Order noteNoOptional, 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.

কী স্কোপ

  • 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

সচরাচর জিজ্ঞাসা

আপনারা কি আমার টাকা নিজেদের কাছে রাখেন?
না। রেলগুলো সরাসরি আপনার নিজের বিকাশ/নগদ/ব্যাংক/অ্যাকোয়ারার অ্যাকাউন্টে সেটেল হয়; ফ্রেমিক শুধু সেই সেটেলমেন্ট আপনার অর্ডারের সাথে মিলিয়ে রেকর্ড রাখে।
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.

আজই বিকাশ যুক্ত করুন, আজ রাতেই প্রথম অর্ডার নিন।

কার্ড আর সিওডি একই সেটআপে যোগ করা যায়। প্রথম অর্ডার থেকেই রিকনসিলিয়েশন শুরু হয়ে যায়।

Start free — no cardTalk to sales