Flow of funds

This guide explains who holds funds in a Moov Money program, how payments and requests settle, and what posts to your ledger.

Your institution is the merchant of record. Moov enrolls you with Visa and Mastercard and originates every card transaction between your user and the other person.

Users do not keep a balance with Moov that they can cash out. You keep a program wallet that funds every push to a recipient. Moov tops that wallet up with a daily sweep from your general ledger.

Who holds what #

Role	What they hold
Your institution	Deposits on your core. A prefunded Moov wallet that funds original credits (OCTs). Merchant of record on the card networks.
Moov	The network, hosted page, fraud, messaging, and orchestration. Moov does not hold a wallet for each user. Your program wallet lives on Moov’s rails so a claim can push in minutes.
The other person	Their own debit card or wallet. They receive a push (claim) or pay a pull (request). They never open an account with Moov to do it.

How a payment is funded #

Before Moov gives your user a claim link, the funds behind the eventual push have to be secured. Nearly every program does this against deposits on its own core. A card-funded alternative exists and is described alongside it for completeness:

Core ledger

When the user sends, Moov calls your authorize endpoint. You place a hold on the deposit.

When the recipient claims, Moov pushes an original credit (OCT) from your prefunded wallet to the recipient, and calls capture so you debit the hold. If the payment is canceled or expires, Moov releases the hold.

This is the standard model. It takes more integration up front and avoids the per-transaction cost of pulling from a card.

Card-funded

When the user sends, Moov pulls from their FI-issued card into your wallet, using BIN ranges you provide. That pull is an account funding transaction (AFT).

There are two card movements: the pull in at send, and the OCT out at claim. You do not host authorize, capture, or release callbacks. If the send is canceled or expires, Moov refunds the funding card.

Skipping the callbacks makes this quicker to stand up, at the cost of an interchange fee on every payment. Few programs choose it. Talk to your Moov contact before planning around it.

Send from your user’s account #

Secure the funds #

You place a hold on your core. (On the card-funded model, Moov pulls from the user’s FI-issued card into your wallet instead.) The claim link is not issued until this step succeeds.

Authorize is fail-closed: if you do not respond, the payment is denied and no money moves.

Claim #

The recipient opens the link and chooses a debit card, Apple Pay, or Google Pay. The push has not run yet.

Push from your wallet #

Moov originates an OCT (Visa Direct / Mastercard Send) from your prefunded wallet to the card or wallet they chose. Capture debits the hold at the same time.

Cancel or expire #

If the payment is canceled or unused after 10 days, Moov releases the hold. (Card-funded programs get the funding card refunded instead.)

The recipient always receives onto a US-issued debit card. Credit cards and non-US cards are not eligible.

Your wallet is kept at a watermark. Moov initiates a daily ACH sweep from your general ledger to top it up.

Request for payment #

A request uses the same rails as a payment, in the opposite direction. Your user is collecting. There is no hold on their account.

What is different is that you are credited after the payer has already paid.

Ask #

Your user confirms a request. Nothing has posted to your core yet.

Pay #

Moov pulls an AFT from the payer’s debit card, Apple Pay, or Google Pay into your Moov wallet.

Received, then credited #

Funds are in your wallet (received). Moov calls credit account so you book the deposit (approved plus a creditReference when the destination can receive it; retries on transport failure). Card-funded programs get an OCT to the requester’s FI-issued card instead, with no callback.

If a request is canceled or expires unpaid, nothing posted. The default TTL is 30 days, longer than a payment’s 10-day claim window.

A payer chargeback after you have credited is a card-side dispute, not a second authorize. Keep the requestID and the creditReference you returned. Who absorbs an uncollectable shortfall is part of your operating model with Moov. It is not booked as a negative balance on the participant.

Settlement and timing #

Payments. Funding is immediate at send. The OCT typically lands in minutes once claimed. The recipient’s issuer controls when the funds are available.
Your wallet. A daily sweep brings the wallet up to the watermark. This is not a consumer cash-out. Every movement through the wallet (OCTs out, AFTs in, the sweep) is visible as wallet transactions in your Moov Dashboard.
Requests. The payer’s funding is immediate. Your core sees the credit only after received, via the credit callback.

What shows up where #

On your ledger (core-ledger payments)

Authorized: a hold, keyed by the holdReference you returned.
Completed: a debit, keyed by the captureReference you returned.
Canceled or expired: a release, keyed by your releaseReference.

On your ledger (requests)

Paid: a credit keyed by the creditReference you return on credit account.

On the other person’s card statement

A dynamic descriptor you configure the prefix of, composed with the user’s name, for example ACME*JANE S. See statement descriptor.

In your app

The SDK looks up a payment by payout ID. The statuses:

Status	Meaning
`initiated`	Created; funding not yet secured.
`authorized`	Your hold is placed; the claim link is live.
`accepted`	The recipient accepted and is verifying their identity.
`claiming`	The push to their card or wallet is in flight.
`completed`	The push settled. Capture fires on your ledger. Terminal.
`payout_failed`	A claim attempt failed (issuer decline, timeout). The recipient can retry; the hold stays.
`cancelled`	The sender cancelled before the claim finished. Release fires. Terminal.
`expired`	The 10-day window lapsed unclaimed. Release fires. Terminal.
`denied`	Refused before authorization: the fraud check, or your ledger declining the hold. Terminal.
`failed`	The payment could not complete. Terminal.

Whatever the path, a hold ends in exactly one of capture or release.

Fees #

There are no fees to the consumer to send, claim, request, or pay. Your commercial terms with Moov are separate. Issuers set their own availability rules on the card that receives a push payment.

Reconciling #

Keep Moov’s payout ID, your hold/capture/release references, the request ID and creditReference on a paid request, and, once a card movement has run, the network authorization code. Capture and release are idempotent on the hold. See idempotency.

The chain to retain: payout → funding attempt → money-movement reference → your hold reference.