What your users see
Your users send and request from your app. The other person opens a branded link. They never install anything.
The hosted page shows your name. Moov appears the way a card network does on a statement: as the payments provider, not the product.
The screens above are the Moov Money reference experience. The flow, and the fraud checks behind it, stay the same in production. Branding, colors, and copy are what you customize.
In your app #
The iOS and Android SDKs present the experience from a single call site: pick a person, enter an amount, review, confirm. You pass in the signed-in user’s access token and the accounts they can use. The SDK handles recipient entry, contact matching, warnings, and confirmation. Payments and requests share that call site.
What they see before they confirm:
- Who they’re paying or asking. If the number is in their contacts, the SDK says so. If the name on the account doesn’t match, it says that too, before they hit send.
- Warnings as they go. On a call while sending, a new number, a name mismatch. Each check states plainly what looks wrong and why. See trust & safety.
- Your limits. If the amount is over what their group is allowed, they find out in the flow, not after. See configuration.
Send: the other person claims #
After your user confirms, Moov messages the recipient over RCS and email. The message is branded as you. Verified branded messages are much harder to imitate than an anonymous text, and you don’t have to stand up messaging infrastructure to send them.
The recipient opens a link like https://moov.money/c/… (or your
custom claim host, if you’ve set one). The page shows who sent the
money, how much, and any note.
Open the link #
They see your name and colors, the sender’s name, the amount, and the note. The link is unique to that payment and valid for 10 days.
Accept, then prove it’s their number #
They accept, then verify the phone number with a one-time code, or unlock with a passkey if they’ve set one up before. A payment addressed to a number can only be claimed by someone who has proven they have that number.
Choose where the money lands #
Apple Pay, Google Pay, or a US-issued Visa or Mastercard debit card typed in. Credit cards and non-US cards can’t receive. Card details are entered on Moov’s page, not in your app.
The money arrives #
Usually within minutes. Availability on their side depends on their issuer. They can save a passkey so the next claim is faster.
They never need an account with you. They never keep a Moov balance. The money goes to the card or wallet they chose.
Request: the other person pays #
A request uses a pay link, not a claim link: the other person pays, they don’t receive.
If they already use Moov Money, they see the request in-app and pay
with a payment. If they don’t, they open a pay link like
https://moov.money/r/… and choose how to pay:
- Apple Pay or Google Pay
- A US-issued Visa or Mastercard debit card, typed in
They verify the phone the same way as a claim. When they confirm, their card is pulled into your wallet, then credited to your user.
After the payment #
- Your user sees the payment or request complete in your app. They can cancel a payment until the other person finishes claiming, and a request until it is paid. Unclaimed payments expire after 10 days and the hold is released (or the AFT refunded). Unpaid requests expire on a longer window (default 30 days).
- The other person sees a confirmation on the hosted page, with a recipient-safe description of the card or wallet used.
- Card statements show a dynamic descriptor you control the prefix
of (for example
ACME*JANE S) so the payment reads as coming from your institution and your user, not from a network they don’t bank with. See configuration.
What you do not build #
You do not build the claim page, the pay page, card capture, Apple Pay or Google Pay, OTP, passkeys, or the messages to the other person. You theme the SDK, mint a session for the signed-in user, and on core-ledger honor authorize / capture / release and credit. Moov handles the rest.