Overview
Moov Money lets your users send and request money inside your app, under your brand. Both use the same rails, in opposite directions.
The other person does not need your app, an account with you, or a Moov Money account. They need a US Visa or Mastercard debit card, typed in or already in Apple Pay or Google Pay.
Users do not keep a balance with Moov. A payment comes out of the deposit they already hold with you. A request lands in that same deposit. You remain their institution. Moov runs the network, the page the other person opens, and the card rails.
Two directions, same rails #
Send
Your user pays someone. You hold and then debit their account. The recipient opens a link and takes the money onto a debit card, Apple Pay, or Google Pay.
Request
Your user asks to be paid. The other person pays from your app if they bank with a Moov Money FI, or opens a link and pays with a debit card, Apple Pay, or Google Pay. The proceeds credit the account they hold with you.
The actors #
- Your user is an account holder at your institution. They start a payment or a request from your app.
- Your institution is the ledger of record and, to the card networks, the merchant. You authorize payments against deposits you already hold. You keep a prefunded Moov wallet that funds the push to the recipient. You receive request proceeds into that wallet and credit the account they hold with you.
- Moov Money screens the payment, hosts the page the other person opens, messages them, and settles over Visa and Mastercard.
- The other person is anyone with a phone number and an eligible US debit card. They do not need your app or an account with you. They open a link.
Lifecycle of a payment #
Your user pays someone. You secure the funds at send with a hold on your core, then the recipient claims onto a card or wallet.
Your user initiates a payment #
The payment starts in your app. The Moov Money SDK (or your own UI on the API) collects who they’re paying, the amount, and which of their accounts to draw from.
Moov screens, then funds the payment #
Moov runs fraud checks, then calls the authorize endpoint you host. The call carries the amount, your user’s identity, and a fraud score. If you approve, you place a hold and return a hold reference. If you decline (insufficient funds, your own risk rules, a required step-up), the payment stops there.
On the card-funded model, Moov pulls from your user’s FI-issued card into your prefunded wallet instead and there is no ledger callback at send. See flow of funds.
The recipient gets a claim link #
Moov notifies the recipient (RCS and email, branded as you) and hosts the claim page. They verify the phone number on the payment, or use a passkey if they have one, and choose where the money lands: a debit card they type in, or a card already in Apple Pay or Google Pay.
The recipient claims; you push from your wallet #
Once the recipient finishes, Moov pushes an original credit (Visa Direct / Mastercard Send) from your prefunded Moov wallet to the card or wallet they chose. On core-ledger, Moov also calls your capture endpoint with the original hold reference so you debit the sender. Funds typically arrive in minutes.
If the sender cancels, or the recipient doesn’t claim within 10 days, the payment ends in release and the hold comes off. A hold always ends in exactly one of capture or release.
A payment can also be held for manual review before the recipient can claim, or denied by risk before it is authorized at all.
Lifecycle of a request #
Your user asks to be paid. If the other person is already on Moov Money, they pay from their app (a normal send, pre-addressed). If they aren’t, they open a pay link and pay with a debit card, Apple Pay, or Google Pay. Either way, funds land in your wallet, then credit the requester.
Your user initiates a request #
The request starts in your app: who they’re asking, the amount, and where the money should land. Unpaid requests last longer than an unclaimed send (default 30 days).
The other person pays #
If they already use Moov Money, they confirm a payment in their FI’s app. If they don’t, they open a pay link, verify the phone (or use a passkey), and pay with a debit card, Apple Pay, or Google Pay. That pull is an AFT into your wallet.
You are credited #
Money is already in your wallet. Moov
calls credit account
(same JWE envelope as authorize) so you book the deposit. Return
approved with a creditReference when the destination can receive
it. destination_unavailable is retryable; refused is terminal and
starts reversal. If you’re unreachable, Moov holds the funds and
retries.
Authorize and credit behave differently because the money is in a
different place when each is called. Authorize is fail-closed: nothing
has moved yet, so if you don’t respond, the payment is denied. Credit
retries on transport failure because the payer’s funds are already in
your wallet; refused is the terminal way to reject the deposit. See
flow of funds.
What you build #
- Funding: host authorize, capture, and release for payments, and a credit callback for requests. See flow of funds and funding.
- In-app: the iOS or Android SDK, or your own UI on the API.
- Tokens: your backend mints a short-lived token for the signed-in user. See sender authentication.
What Moov Money handles #
- Claim and pay links, the hosted page, and onboarding for the other person
- Card capture (manual entry and Apple Pay / Google Pay), PCI, and settlement over Visa and Mastercard
- A prefunded wallet for your program, topped up by a daily sweep
- Fraud screening, device intelligence, and the review queue you work
- Notifications to both sides (RCS and email), branded as you
- Retries, idempotency, and reconciliation across the network
These pages are for the people who run the program, not only the engineers who integrate it.