Member transfers and the deposit

If your organisation’s people are Moria members you provisioned, you can move part of your gateway balance straight into their wallets. The money is usable the moment it lands.

Which wallet

Each transfer names one with wallet:

wallet	Lands in	Usable for
open_loop (default)	The member’s payment wallet	QRIS payments and bank transfers from the Moria app
closed_loop	The member’s main balance in your organisation	Your organisation’s own products and transfers; not outside it

Leave wallet out and the transfer goes to open_loop, so an integration written before the field existed is unchanged.

The catch is timing. A customer’s payment is yours as soon as it succeeds, but the payment provider releases it one or two business days later, and a transfer can only draw on money that has been released. The deposit is how you close that gap with your own money.

Before you start

Member transfers are off for every partner until Moria switches them on for your account, under your agreement.

Permission	transfer-to-member — issued by Moria, not creatable in the console
Who can receive	Only members you provisioned, through an active group link, with an active membership
Fee	None
Member PIN	Not needed. Money goes into the member’s wallet, never out of it
Direction	One way. There is no transfer from a member’s wallet back to you

The deposit

A deposit is part of your released balance that you set aside. No money moves when you set it: it is already in your account. What changes is what it may be used for.

• It can no longer be paid out to a bank.
• It covers member transfers against payments that have succeeded but are not released yet.

Your owners set it in the console, on the Deposit page. Every change needs a fresh second-factor code and emails every owner on your account.

You want to	Allowed when
Lock more	You have that much released money not already set aside
Release some	None of the deposit is covering a transfer right now, and you release at most what is locked

Size it for your busiest stretch. A payment made on Saturday is typically released on Tuesday, and long holidays stretch that further. Your deposit should cover the transfers you expect over the longest wait.

How much you can transfer

GET /v1/partners/balance answers it as transferable_to_members. It is your released money, plus as much of your deposit as there are eligible unreleased payments to repay it:

transferable_to_members = free + min(eligible unreleased payments, deposit)

Released money is spent first, then the deposit. The part of a transfer the deposit covered is returned as deposit_used, and it comes back by itself as the payments it covered are released.

Not every unreleased payment can be covered. Only payments the provider itself has confirmed, on a payment method whose release day is known. A payment recovered after a delayed confirmation, or made through a bank or wallet code the release schedule does not list yet, counts in full once it is released, just not before.

Why the deposit is yours, not Moria's

Moria does not lend. If a payment you covered were never released, your deposit stays short by that amount: you chose to cover it, so the risk is yours. Moria pauses member transfers on your account when released money is overdue, so a problem cannot keep growing while it is being looked at.

Your balance with a deposit

Three fields are added to the balance response. If you never set a deposit, reserve and advance_used stay zero and nothing else changes.

Field	Meaning
reserve	Your deposit
advance_used	How much of it is covering transfers right now
transferable_to_members	What you can move to members now

available still means “can be paid out to a bank now”, and the deposit is never part of it. With a deposit:

balance = available + (reserve − advance_used) + pending

If your own system debits the member first

Give the member's balance back only on failed

A common integration debits the member in your own system, then calls Moria. If you then credit the member back on a timeout, a network error or a pending answer, the money may already be in their Moria wallet, and the member is paid twice.

Credit the member back only when the transfer is failed, from its status or the member.transfer.failed webhook. When unsure, send the same request again with the same idempotency key: you get the same transfer back and no money moves a second time.

A transfer that has succeeded cannot be reversed by you. The member has to agree to any money leaving their wallet, and you cannot agree on their behalf.

When transfers are refused

Code	Means	What to do
FUNDS_INSUFFICIENT_BALANCE	More than transferable_to_members	Lower the amount, or lock more deposit
FUNDS_SETTLEMENT_PENDING	The provider has not released enough money to your account yet	Retry later with the same key
FUNDS_TRANSFER_SUSPENDED	Member transfers are not switched on for you, or are paused while a settlement difference is reviewed	Contact Moria
STATE_MEMBER_WALLET_NOT_READY	The member’s wallet is not active yet (open_loop), or your organisation’s balance accounts are not ready for the member (closed_loop)	Retry later. A wallet is opened shortly after the member is provisioned, not in the same call; for closed_loop, contact Moria if it persists
STATE_CONFLICT	The member’s group link or membership is not active	Reactivate it first

Next

• Transfer to a member
• Webhooks — member.transfer.succeeded and member.transfer.failed