Configuration

Limits and groups #

Caps are per transaction, per day, per week, per month, and as a daily send count. You apply them as a provider default, then by group, then by participant override. The most specific layer wins: an override beats a group, a group beats your default. In more than one group, the highest ceiling among them applies. A platform maximum clamps every ceiling.

A new account, a seasoned household, and a private-banking relationship should not share a limit.

Read and update the default policy with GET and PATCH /providers/{providerID}/limits. Create groups, add members, and set per-participant overrides. Effective limits shows what a given user actually has after group and override, and names the source of each ceiling.

Dimensions in the API:

Amounts are Money objects with a decimal string, not floats. A dimension you leave out stays unchanged. Every write carries the versionID from your last read as expectedVersionID:

curl -X PATCH "https://api.moov.money/providers/$PROVIDER_ID/limits" \
  -u "$MOOV_API_KEY_ID:$MOOV_API_KEY_SECRET" \
  -H "X-Moov-Version: v2026.10.00" \
  -H "Content-Type: application/json" \
  --data '{
    "expectedVersionID": "ver_01HF5J9ZKQT4RXP8M2VYBN3D",
    "perTransactionAmount": { "value": "500.00", "currency": { "code": "USD", "decimalPlaces": 2 } },
    "dailySendCount": 10
  }'

Omit expectedVersionID only on the first write, while you have no policy yet (GET returns 404 until then). A stale or missing value returns a 409 problem with type https://api.moov.money/errors#version-conflict and the latest version in currentVersion. Re-read, then retry. Groups and overrides version the same way, except a group update without expectedVersionID returns 422. A write that changes nothing returns 400.

An example, not a default you are stuck with:

You define the groups, the amounts, and who lands in each. Move someone between groups as the relationship changes. New caps take effect on the next payment. An override can carry expiresOn, which must be in the future, for a temporary raise; without it, the override is permanent until you delete it. Sending null for a dimension is the same as leaving it out. To put one dimension back on its group or default, delete the override and PUT a new one with only the dimensions you still want.

Start a cohort low when you roll out. Raise limits when the losses you actually see support it. The fraud stack flags a payment; limits keep a flagged pattern from draining an account even if a check misses.

The limits API caps payments (money leaving the account). Caps on requests (how much a user can collect, and how often they can ask a stranger) are program settings you agree with Moov.

Branding #

Three surfaces carry your name:

The SDK is not a webview of a Moov app. It’s native UI, themed to the color you pass in. On iOS you supply a single brand color and the SDK draws the rest from system semantic colors, so it adapts to light and dark on its own. On Android you supply a light and a dark palette, and the SDK follows the device’s night mode.

Statement descriptor #

On capture, the other person’s card statement shows a dynamic descriptor. You set a shortName (2–12 ASCII letters or digits) and Moov composes it with the user’s name:

ACME*JANE S

Update it with PATCH /providers/{providerID}:

curl -X PATCH "https://api.moov.money/providers/$PROVIDER_ID" \
  -u "$MOOV_API_KEY_ID:$MOOV_API_KEY_SECRET" \
  -H "X-Moov-Version: v2026.10.00" \
  -H "Content-Type: application/json" \
  --data '{"shortName":"ACME"}'

Choose a descriptor your users would recognize on someone else’s statement. A cryptic prefix is how “I don’t know this charge” disputes start.

Features you can configure #

These are program-level. They’re not flags your app toggles per session, except where the SDK is told to collect a signal.

• Device intelligence. When it’s on for your institution, the SDK receives a fraud client configuration on the session and collects device signals. A rooted phone, an emulator, or taps that don’t look like a person feed the score you see on authorize. If the section is absent from the session, the SDK proceeds without it.
• Contact sync. Users can sync contacts so a mistyped digit is caught before the money leaves. Matching also drives the “in your contacts” / name-mismatch copy in the payment flow.
• Passkeys. Offered on the hosted page after a successful claim or payment, so the next visit is Face ID / device unlock instead of a new OTP.
• Apple Pay and Google Pay. On the claim page, as disbursement (the recipient receives onto a wallet). On a pay link, as the way the other person pays. Manual debit-card entry is always available as the fallback.

What is not configurable #

A few things are fixed as part of the product, not a setting:

• The other person must have an eligible US Visa or Mastercard debit (or prepaid that can receive). Credit cards can’t receive a payment.
• Unclaimed payments and unpaid requests both expire after 10 days.
• Moov messages the other person. You don’t send the claim or pay link yourself unless you choose to share it in-app as well.
• Card data is captured on Moov’s page, never in your app.

Funding sources #

The accounts a user can send from are yours to enumerate. Create them on the participant with POST /providers/{providerID}/participants/{participantID}/funding-sources: a fundingType (card or bank_account), your providerSourceID, and a display name. That ID is what you will see again on authorize as fundingSource; Moov treats it as opaque. The SDK reads the list off the session, so there is nothing to pass in. If they have checking and savings, you decide which appear and what they’re called.

Creation is idempotent on (participant, fundingType, providerSourceID). Update displayName or last4 with PATCH; remove a source with DELETE. fundingType and providerSourceID can’t change; to repoint a source, delete it and create a new one.