Skip to content

Fees & Pricing

Every money movement can carry a fee. Moria’s pricing is built so a fee is a transparent service charge, disclosed before the member confirms — not interest on money. This page explains how a fee is composed, how it is configured per partner, and how it is recorded. The charge mode depends on the surface: Moria’s own member/product paths use ON_TOP, while the Partner Gateway defaults to DEDUCTED.

Fees are service charges (ujrah) for a real service — running the payment rail and operating the platform. They are fixed and disclosed up front. On member/product paths they are added on top of the amount; on the Partner Gateway’s default DEDUCTED path they are taken from the payer’s amount. They never accrue on a balance over time. There is no riba: a member or payer pays a known fee for a service, not interest on a sum owed.

A charge has up to two parts:

  • Provider fee — the cost of the external payment rail (e.g. a bank or QRIS channel), passed through.
  • Platform margin — Moria’s (and, by arrangement, the partner’s) own service fee.

The amount and the recipient’s net depend on the charge mode:

ModeUsed by default forPayer paysRecipient receives
ON_TOPMoria member/product pathsBase amount + provider fee + platform marginBase amount
DEDUCTEDPartner GatewayBase amountBase amount − provider fee − platform margin

A partner- or organisation-scoped Partner Gateway rule can use ON_TOP when that is the negotiated commercial arrangement. The mode is pricing configuration, not a field the caller sends.

flowchart LR
    BASE["Base amount<br/>(what the member moves)"]
    PROV["+ Provider fee<br/>(rail cost)"]
    MARG["+ Platform margin<br/>(service fee)"]
    TOTAL(["= Total charged"])
    NET(["Net credited / moved<br/>= Base amount"])

    BASE --> PROV --> MARG --> TOTAL
    BASE -.-> NET

    classDef base fill:#E8E1FF,stroke:#3C2C96,stroke-width:1.5px,color:#1E1B4B;
    classDef fee fill:#FFF3D0,stroke:#F4BE27,stroke-width:1.5px,color:#8B5A00;
    classDef out fill:#FDF8E8,stroke:#3C2C96,stroke-width:2px,color:#1E1B4B;
    class BASE base;
    class PROV,MARG fee;
    class TOTAL,NET out;

Pricing rules resolve from most specific to most general, so a partner can have its own schedule without affecting anyone else:

flowchart TD
    A[Charge for a transaction] --> B{Organization-specific rule?}
    B -->|Yes| R1[Use organization rule]
    B -->|No| C{Partner-specific rule?}
    C -->|Yes| R2[Use partner rule]
    C -->|No| R3[Use base rule]

    classDef step fill:#E8E1FF,stroke:#3C2C96,stroke-width:1.5px,color:#1E1B4B;
    classDef gate fill:#FFF3D0,stroke:#F4BE27,stroke-width:1.5px,color:#8B5A00;
    class A,R1,R2,R3 step;
    class B,C gate;
  • Per payment method — a different fee for each rail (bank, QRIS, and so on), or one catch-all.
  • Per direction — money-in and money-out are priced independently.
  • Preview before charge — a price can be previewed for any context so the exact total and partner-facing fee are known before anything is saved or charged.

The provider fee and the platform margin are booked as separate ledger entries, not merged. That keeps every rupiah attributable for Moria’s accounting and reconciliation. Partner Gateway responses expose one combined fee; the internal split is not a partner-facing cost report.

  • Your fee schedule — the margin per payment method and direction, scoped to your organization.
  • Revenue arrangement — how the platform margin is split with you, by agreement.
  • Disclosure — the applicable fee shown to the payer or member before they confirm. Partner Gateway clients receive one combined fee.
  • Member/product paths use ON_TOP; the member’s product amount is the net figure.
  • Partner Gateway defaults to DEDUCTED; the payer’s amount is the gross and fees reduce the partner’s net.
  • A fee is a fixed service charge — it never compounds and never accrues over time.
  • Provider fees reflect the real rail cost and are passed through.