Request money lifecycle

Overview

Request money is a two-sided journey:

A requester asks for funds (Request API, or the request widget flow).
RaaS Widgets mints a fund-request magic link for the sender (payer).
The sender opens that link, funds the transfer, and RaaS Widgets creates an operation.
You learn about progress through webhooks — mainly operation.* events keyed by requestId.

You do not need corridor-level processing details. Track the money request until an operation exists, then follow Operation lifecycle.

End-to-end flow

Two ways to create the ask

A. Request API (`POST /v1/request-money`)

On success RaaS Widgets:

Creates an internal money request (requestId, e.g. req_…)
Mints a fund-request magic link for the sender
Emits request_money.created with fundRequestLink, requestId, amount, and status pending

Share fundRequestLink (or your landingLink / waLink wrappers) with the sender. On API errors you may receive request_money.failed (for example identity / OFAC rejection at create time). Details: Create and lookup · Request API webhooks.

request_money.updated is not emitted. After create, fulfillment and settlement arrive as operation.created / operation.completed / operation.failed / operation.cancelled.

Mint a link with flow: "request". The requester builds the ask in the widget; the platform then mints the payer fund-request link. You typically see link.created for those links rather than request_money.created. See Request flow and Fund request.

What the sender does

The fund-request link carries the pinned amount, corridor, and requester payout profile. The sender:

Opens the link → link.opened
Completes CIP if needed (possible user.data_request)
Confirms quote and funding → RaaS Widgets creates the operation

At that point the money request moves from waiting on a payer to accepted / in fulfillment. Your integration should key off the operation webhooks, not a separate “request fulfilled” event.

Public status vs operation status

`GET /v1/request-money` status	Typical meaning
`pending`	Ask live; sender has not completed payment
`processing`	Fulfilling operation in progress
`completed`	Settled / funded
`rejected`	Fulfilling operation failed
`cancelled`	Cancelled or expired

Once the operation exists, Partner API operation.status uses created → processing → completed | failed | cancelled. See Operation lifecycle.

Operation webhooks (fulfillment)

Event	Meaning for request money
`operation.created`	Sender created the fulfilling transfer. Payload includes `requestId`. Status `created`.
`operation.completed`	Transfer settled. Treat the ask as funded.
`operation.failed`	Transfer failed.
`operation.cancelled`	Transfer cancelled (user, funding expiry/rejection, or corridor cancel).

Correlate every operation.* event with the original ask using requestId from request_money.created (or from your stored money-request id). Example terminal success:

{
  "event": "operation.completed",
  "timestamp": "2026-07-28T12:00:00.000Z",
  "data": {
    "operationId": "op_a1b2c3d4e5f6",
    "linkId": "link_acme_fund_req_01",
    "userId": "usr_x9y8z7w6v5u4",
    "requestId": "req_abc123",
    "status": "completed",
    "funding": { "method": "card" },
    "payout": { "method": "bank_account" },
    "amount": {
      "send": 100,
      "receive": 1850.5
    },
    "completedAt": "2026-07-28T12:00:00.000Z"
  }
}

Mental model

Concept	What it is	Partner signal
Money request	The ask (`requestId`)	`request_money.created` / your stored id
Fund-request link	Sender magic link	`link.created` / `fundRequestLink`
Operation	Actual transfer once the sender pays	`operation.created` → terminal `operation.*`

Integration checklist

Create the ask

Call POST /v1/request-money or mint a request link. Persist requestId and the fund-request URL.

Handle create webhooks

Acknowledge request_money.created and/or link.created. Deliver the URL to the sender.

Wait for the sender

Expect link.opened, optional user.data_request, then operation.created with the same requestId.

Reconcile terminals

On operation.completed, mark the ask funded. On failed / cancelled, release holds and update your UX.

Request API

Overview and environments.

Request API webhooks

Event names and payloads.

Request flow

Widget path to originate an ask.

Operation lifecycle

Statuses after the operation exists.

Getting Started

Request API

Concepts

Integration

Flows

Webhooks

Operations

Overview

End-to-end flow

Two ways to create the ask

A. Request API (`POST /v1/request-money`)

B. Widget `request` flow

What the sender does

Public status vs operation status

Operation webhooks (fulfillment)

Mental model

Integration checklist

Request API

Request API webhooks

Request flow

Operation lifecycle

​Overview

​End-to-end flow

​Two ways to create the ask

​A. Request API (POST /v1/request-money)

​B. Widget request flow

​What the sender does

​Public status vs operation status

​Operation webhooks (fulfillment)

​Mental model

​Integration checklist

​Related

Request API

Request API webhooks

Request flow

Operation lifecycle

Overview

End-to-end flow

Two ways to create the ask

A. Request API (`POST /v1/request-money`)

B. Widget `request` flow

What the sender does

Public status vs operation status

Operation webhooks (fulfillment)

Mental model

Integration checklist

Related