All products
Disputes & Refunds

Post-sale, handled properly.

Every payment platform handles refunds. Few handle disputes well. MerasPay treats both as first-class resources tied into the same ledger as your charges, with rail-specific resolution flows, structured evidence submission, and customer-friendly status — across mobile-wallet complaints, bank disputes, and card chargebacks.

At a glance

Refund types
Full · Partial · Cross-rail
Dispute states
6
Response window
Configurable
Ledger impact
Auto-posted

Refunds: simple, idempotent, ledger-correct

A refund is just a reversed charge with reverse-direction ledger entries. We made it as fast to issue as the original charge was to take.

Full or partial

Refund the whole charge or a portion. Multiple partial refunds against the same charge are supported until the cumulative total reaches the original amount.

Same-rail reversal

Refunds default to the rail the original payment came in on. Waafi-collected → Waafi-refunded. Customer sees the credit on the same wallet, with the original reference.

Cross-rail fallback

If the original rail cannot accept a refund (e.g. expired authorisation, frozen account), choose an alternate destination wallet or bank — fully tracked back to the original charge.

Ledger-first

Refunds post matching reversing entries in the same ledger as the original payment. Your settlement file shows the gross and net per period without manual reconciliation.

Disputes follow a single state machine

Six states, deterministic transitions, every transition observable through webhooks.

  1. 1

    needs_response

    A chargeback or dispute is opened. The merchant has a configurable window (default 14 days) to respond with evidence.

  2. 2

    under_review

    Evidence has been submitted. The platform forwards to the issuing rail or scheme; the response window is typically 7–45 days depending on the rail and reason code.

  3. 3

    won

    The dispute is resolved in the merchant's favour. Funds are returned to the merchant balance; an updated ledger entry posts.

  4. 4

    lost

    The dispute is resolved in the customer's favour. The charge is reversed; the merchant balance is debited; a dispute_fee may apply per the rail's schedule.

  5. 5

    won_admin / lost_admin

    Admin overrides exist for exceptional cases (e.g. fraud rings, regulatory order). Every override is recorded in admin_audit_logs with rationale.

The operational surface

Everything around the disputes resource that makes life easier when a customer is unhappy.

Structured evidence submission

Receipts, shipping logs, customer correspondence, IP / device fingerprints — all uploaded as typed JSON + attachments. The platform forwards the right subset to the rail.

Automated representment hints

Per reason code, the dashboard suggests the evidence types most likely to win. Reduces the time-to-respond and the loss rate.

Customer-friendly status

Customers see a non-scary status page for their dispute with their order number and an expected resolution date — reduces "where's my money" inbound to your support team.

Bulk export for legal

Disputes export to a signed CSV with evidence linked by S3 / GCS object key — drop-in for your legal or compliance team's case file.

In code

A partial refund, then an evidence submission against an open dispute. Both produce webhook events your back-office can hook into.

bash
# Issue a partial refund — customer returned half their order.
$ curl -X POST https://api.meraspay.io/v1/refunds \
  -u sk_live_xxx: \
  -H "Idempotency-Key: refund-ord-1024-partial-1" \
  -d charge=ch_01HZF... \
  -d amount=7500 \
  -d "reason=requested_by_customer" \
  -d "metadata[order_id]=1024"

{
  "id": "re_01HZF...",
  "object": "refund",
  "charge": "ch_01HZF...",
  "amount": 7500,
  "status": "succeeded",
  "destination": { "provider": "waafi", "msisdn": "+25377101010" }
}

# Respond to a dispute with evidence.
$ curl -X POST https://api.meraspay.io/v1/disputes/dp_01HZF.../evidence \
  -u sk_live_xxx: \
  -d "evidence[customer_communication]=https://cdn.example.io/case/1024/email.eml" \
  -d "evidence[receipt]=https://cdn.example.io/case/1024/receipt.pdf" \
  -d "evidence[shipping_tracking]=DJ123456789" \
  -d "evidence[explanation]=Customer confirmed delivery on 2026-05-18."

{ "id": "dp_01HZF...", "status": "under_review", "evidence_submitted_at": "2026-05-24T..." }

Frequently asked

How fast does a refund reach the customer?

Mobile-wallet refunds typically credit the customer in under a minute. Bank-rail refunds follow the destination bank's clearing window — usually same business day.

Can I refund after a dispute is opened?

Yes, and it is often the cheapest resolution. Refunding closes the dispute automatically and avoids the dispute_fee on most rails. The platform suggests this on the dispute dashboard when the math favours it.

What about chargebacks for non-card rails?

Mobile-wallet rails support a customer-complaint workflow that runs through the same dispute resource. Bank rails follow the BCD complaint process, which we surface in the same UI. You see one queue for all post-sale issues regardless of rail.

Is there a dispute fee?

Per rail. Card-not-present disputes carry the scheme's standard chargeback fee. Mobile-wallet customer complaints typically do not have a per-incident fee but cumulative volume above thresholds may trigger one — surfaced on your pricing schedule.

How are refunds reported for accounting?

Each refund posts a credit_note linked to the original charge and invoice. End-of-day settlement files show gross sales, refunds, disputes, fees, and net payout per merchant currency.

Ready to integrate?

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