All products
Disbursements

Send money to anyone, on any Djiboutian rail, at any volume.

From a single freelancer payment to a 50,000-row payroll, Disbursements turns your MerasPay balance into recipient credit on the right rail — mobile wallets, bank accounts, or agent cash. Idempotent, screened, approved, and reconciled.

At a glance

Destinations
Wallet · Bank · Agent
Batch size
Unlimited
Same-day clearance
Mobile wallets
AML on every row
Yes

What teams build with Disbursements

Whenever the value flows out of your platform — to a seller, a worker, a claimant, or a beneficiary — Disbursements is the surface that does the moving.

Marketplace seller payouts

Pay vendors their daily, weekly, or on-demand earnings. Application-fee splits ensure platform commission is retained atomically inside each transfer.

Gig / driver payments

Trigger end-of-shift or end-of-trip payouts to drivers and gig workers via their preferred wallet. Recipients see funds in minutes.

Payroll

Upload a CSV of employees with amounts and rails; we run AML, dispatch each payout, and produce a single signed PDF settlement file for accounting.

Insurance and claim payouts

On claim approval, fire a single API call that pays the claimant on their chosen rail with the claim id baked into the transaction metadata.

Refunds beyond the original rail

When the original card is no longer valid, refund to a mobile wallet via Disbursement instead. Same ledger, separately reportable.

Charity and aid distribution

NGO programs distribute cash assistance via wallet or agent cash with full auditability per beneficiary and per cohort.

Built for the boring parts of paying people

Outbound payments is where ops gets ugly. We baked the controls into the platform so your finance and risk teams do not have to bolt them on.

Single or bulk

POST /v1/payouts for one. POST /v1/payouts/batches with a CSV or JSON array for thousands. Both routes share the same orchestrator.

Idempotent retries

Idempotency-Key per payout means failed batches can be safely re-uploaded. Already-processed rows return their original status; only the gaps re-run.

Mandatory 4-eyes for high-value

Above a configurable threshold, payouts move to pending_approval. A second admin reviews and approves before funds dispatch — recorded in admin_audit_logs.

AML on every payout

OFAC, EU, and UN consolidated screening on every recipient. Hits halt the payout and create an alert in the admin portal.

Multi-rail routing

Pick the rail per payout, or supply a recipient identifier and let MerasPay route to whichever rail the recipient is on. Costs differ by rail.

Reporting and reconciliation

Daily settlement files in CSV and JSON include rail used, fee retained, net amount, FX (if cross-currency), and the upstream payment_intent id.

The full flow

  1. 1

    Fund your MerasPay balance

    Move money in from collections, a wire transfer, or a card-not-present top-up. Balance is held in a designated bank account at our partner bank.

  2. 2

    Create a payout

    POST /v1/payouts with amount, currency, destination rail, recipient identifier, and metadata. Receive a pending payout id.

  3. 3

    AML + approval

    Auto-screen against sanctions lists and apply your 4-eyes policy. The payout moves to approved when both clear.

  4. 4

    Dispatch and settle

    The adapter for the chosen rail executes. Most mobile-wallet payouts settle in under a minute; bank rails clear by end of business day.

In code

A single payroll payout, then a 5,000-row bulk upload. Both go through the same orchestrator and produce the same shape of settlement file.

bash
# Single payout to a Waafipay wallet.
$ curl -X POST https://api.meraspay.io/v1/payouts \
  -u sk_live_xxx: \
  -H "Idempotency-Key: payroll-2026-05-24-001" \
  -d amount=85000 -d currency=DJF \
  -d "destination[provider]=waafi" \
  -d "destination[msisdn]=+25377101010" \
  -d "metadata[payroll_id]=2026-05" \
  -d "metadata[employee_id]=emp_0142"

{
  "id": "po_01HZF...",
  "object": "payout",
  "status": "pending_approval",       # 4-eyes triggered above threshold
  "amount": 85000,
  "currency": "DJF",
  "destination": { "provider": "waafi", "msisdn": "+25377101010" },
  "metadata": { "payroll_id": "2026-05", "employee_id": "emp_0142" }
}

# Bulk: upload a 5,000-row payroll file.
$ curl -X POST https://api.meraspay.io/v1/payouts/batches \
  -u sk_live_xxx: \
  -H "Idempotency-Key: payroll-2026-05-batch" \
  -F file=@payroll-2026-05.csv \
  -F "metadata[payroll_id]=2026-05"

{
  "id": "pob_01HZF...",
  "status": "processing",
  "summary": { "rows_total": 5000, "rows_accepted": 4987, "rows_rejected": 13 },
  "rejected_rows_url": "https://cdn.meraspay.io/batches/pob_01HZF.../rejected.csv"
}

Frequently asked

What rails can I pay out to?

Mobile wallets (Waafipay, D-Money, SabaPay), bank accounts (CAC, EAB), or agent cash for unbanked recipients in Djibouti, plus SantimPay-driven mobile wallets and banks in Ethiopia.

How fast are payouts?

Mobile-wallet payouts typically clear within a minute. Bank rails clear by the next available settlement window — usually same business day. Agent cash availability depends on the recipient redeeming with an agent.

What if a payout fails?

Failures (wrong number, frozen account, daily limit hit) flip the payout to failed and emit payout.failed. The funds return to your MerasPay balance net of irrecoverable provider fees. You retry by creating a new payout with a new idempotency key.

Can I split a single charge across multiple payouts?

Yes — marketplace flows use application_fee + transfer_data on the original PaymentIntent so the platform fee and the seller payout settle atomically. For more complex splits (multi-party), use the Transfers API alongside Disbursements.

How do approvals work?

You configure a payout_approval_threshold per merchant. Payouts above it move to pending_approval and require a second admin to sign off. The 4-eyes flow is the same one that gates merchant go-live and limit changes — audited end-to-end.

What about cross-currency payouts?

Source currency is your balance currency. For cross-currency (most often DJF→ETB), use the Remittance Origination flow; it locks an FX rate at creation and is built for this exact use case.

Ready to integrate?

Get a sandbox account in minutes. Production goes live after a brief KYB review.