Partner-Managed Limits

How Rain allows partners to set up limits for onramp and offramp volume through payment routes and transfers, what you see when a deposit exceeds a limit, and how to read a user’s remaining limit.

Use this page to understand the limits you can set on your users’ onramp and offramp activity, and to build your integration so users are never surprised by a returned deposit. Limits can apply to every onramp and offramp, whether the funds move through a payment route or through the quote and transfer flow.

Limits are configured per program at your request. The limits endpoint (GET /v1/limits) is enabled per tenant. Contact your Rain account manager to enable the endpoint and to set or change limits.

How you set limits

You set limits for your program by asking Rain. Message your Rain account manager with the limits you need.

Each limit combines the following dimensions:

Dimension	Options
Direction	Onramp or offramp. Reported as limitType onramp_usage or offramp_usage.
Interval	Daily or per transaction. A daily limit accumulates deposits against the ceiling, and the window resets at midnight in a fixed UTC-5 zone with no daylight-saving adjustment, so every day at 05:00 UTC. A per-transaction limit caps each deposit on its own and keeps no running usage.

Each limit applies to one account. For consumer accounts that is the individual user. For corporate accounts it is the company, so all of its users share one limit. You can set a default for every account and override it for individual accounts.

Limits are always denominated in USD. Other currencies are counted after conversion to USD using the exchange rate applied to the transfer: the rate on the quote for quote-based transfers, or the rate on the transfer for payment-route deposits. The converted amount is rounded up to the cent.

Where a limit shows up in the API

Payment-route deposits are checked when the funds arrive, because the amount is unknown until then. Transfers are checked when you create them, because the quote fixes the amount.

Endpoint	Checked against limits?	What you see
POST /v1/payment-routes	No	Route is created as normal. Every deposit into it is checked when it arrives, as described below.
POST /v1/quotes	No	Quote is created as normal.
POST /v1/transfers	Yes	A transfer over the limit is rejected with 400 Bad Request. The message states the remaining allowance.
GET /v1/limits	Read only	The user’s limits with current usage, so you can warn before the deposit is sent.

A transfer that exceeds a limit

1. POST /v1/quotes succeeds. Quotes are not checked against limits.
2. POST /v1/transfers is rejected with 400 Bad Request. The message states the remaining allowance. No transfer is created and nothing is counted against usage.

A transfer that is created has passed the check and is not checked again when the deposit arrives, so a transfer in pending or awaiting_transfer will not be refunded for a limit.

A payment-route deposit that exceeds a limit

A payment-route deposit is checked after its transfer transaction is created, so a transfer in pending or processing can still be refunded for a limit.

1. The transfer transaction is created (transactionTransfer.created).
2. Rain returns the funds. While the return is in progress the transfer shows pending_review or processing. Fiat onramp deposits go back to the originating bank account, and stablecoin deposits go to the payment route’s refundAddress.
3. The transfer moves to refunded. You receive a transactionTransfer.updated webhook, and GET /v1/issuing/transactions returns the same status.

A transfer can also show pending_review while Rain holds it for a compliance review. Treat pending_review as in progress, not as a failure: the transfer returns to processing when released, or moves to refunded if Rain returns the funds.

Read a user’s remaining limit

Call GET /v1/limits?userId= to show a user how much they can still move today. Each returned limit carries the ceiling (amount) and its interval. A daily limit also carries what has been used in the current window (used) and when the window resets (windowResetAt). A per-transaction limit omits those fields because it keeps no running usage. Amounts are decimal strings in the currency’s major units. Windows reset at midnight in a fixed UTC-5 zone with no daylight-saving adjustment, so windowResetAt is always 05:00 UTC.

Response

{
  "limits": [
    {
      "limitType": "onramp_usage",
      "currency": "usd",
      "amount": "10000.00",
      "used": "7500.00",
      "interval": "daily",
      "windowStart": "2026-07-04T05:00:00Z",
      "windowResetAt": "2026-07-05T05:00:00Z"
    },
    {
      "limitType": "onramp_usage",
      "currency": "usd",
      "amount": "2500.00",
      "interval": "per_transaction"
    }
  ]
}

An empty limits array means no daily or per-transaction limit is configured for the user. Rain’s compliance and risk controls still apply to every deposit.

Best practices

1. Warn before the deposit is sent. Call GET /v1/limits when you display deposit instructions and check every limit whose limitType matches the direction: compare the deposit’s approximate USD value with amount minus used for a daily limit, or with amount for a per-transaction limit. Show the user windowResetAt if they need to wait.
2. Explain refunds. When a transfer reaches refunded, tell the user the funds are on their way back and when they can try again.
3. Make sure the refundAddress on every offramp payment route is a wallet your user can access, so a returned stablecoin deposit lands somewhere they can reach.

What’s next

Transfer webhooks

Payload fields and status values for transactionTransfer events.

Onramps

Create payment routes for fiat deposits.