> ## Documentation Index
> Fetch the complete documentation index at: https://docs.leapfinancial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Request money lifecycle

> How Request API creates a fund-request link, the sender pays, and an operation is created

## Overview

**Request money** is a two-sided journey:

1. A **requester** asks for funds (Request API, or the `request` widget flow).
2. RaaS Widgets mints a **fund-request** magic link for the **sender** (payer).
3. The sender opens that link, funds the transfer, and RaaS Widgets creates an **operation**.
4. 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](/raas-widgets/ops/operation-lifecycle).

## End-to-end flow

```mermaid theme={null}
sequenceDiagram
    participant Partner
    participant RaaS as RaaS Widgets
    participant Requester
    participant Sender
    participant Server as Your webhook

    Note over Partner,RaaS: Create the ask
    Partner->>RaaS: POST /v1/request-money<br/>or request flow mints ask
    RaaS->>Server: request_money.created<br/>and/or link.created
    RaaS-->>Partner: fund-request URL + requestId

    Note over Sender,RaaS: Sender fulfills
    Sender->>RaaS: Opens fund-request link
    RaaS->>Server: link.opened
    opt CIP data incomplete
      RaaS->>Server: user.data_request
    end
    Sender->>RaaS: Quotes and creates transfer
    RaaS->>Server: operation.created<br/>(includes requestId)

    Note over RaaS,Server: Settlement
    RaaS->>Server: operation.completed<br/>or failed / cancelled
```

## Two ways to create the ask

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

On success RaaS Widgets:

1. Creates an internal money request (`requestId`, e.g. `req_…`)
2. Mints a **fund-request** magic link for the sender
3. 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](/raas-widgets/request-api/endpoints) · [Request API webhooks](/raas-widgets/request-api/webhooks).

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

### B. Widget `request` flow

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](/raas-widgets/flows/request) and [Fund request](/raas-widgets/flows/fund-request).

## What the sender does

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

1. Opens the link → `link.opened`
2. Completes CIP if needed (possible `user.data_request`)
3. 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](/raas-widgets/ops/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:

```json theme={null}
{
  "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.*` |

```mermaid theme={null}
flowchart LR
    A[Money request] --> B[Fund-request link]
    B --> C[Sender pays]
    C --> D[Operation]
    D --> E{Terminal status}
    E -->|completed| F[Funded]
    E -->|failed| G[Failed]
    E -->|cancelled| H[Cancelled]
```

## Integration checklist

<Steps>
  <Step title="Create the ask">
    Call `POST /v1/request-money` or mint a `request` link. Persist `requestId` and the fund-request URL.
  </Step>

  <Step title="Handle create webhooks">
    Acknowledge `request_money.created` and/or `link.created`. Deliver the URL to the sender.
  </Step>

  <Step title="Wait for the sender">
    Expect `link.opened`, optional `user.data_request`, then `operation.created` with the same `requestId`.
  </Step>

  <Step title="Reconcile terminals">
    On `operation.completed`, mark the ask funded. On `failed` / `cancelled`, release holds and update your UX.
  </Step>
</Steps>

## Related

<CardGroup cols={2}>
  <Card title="Request API" icon="hand-holding-dollar" href="/raas-widgets/request-api">
    Overview and environments.
  </Card>

  <Card title="Request API webhooks" icon="bell" href="/raas-widgets/request-api/webhooks">
    Event names and payloads.
  </Card>

  <Card title="Request flow" icon="envelope-open-dollar" href="/raas-widgets/flows/request">
    Widget path to originate an ask.
  </Card>

  <Card title="Operation lifecycle" icon="diagram-project" href="/raas-widgets/ops/operation-lifecycle">
    Statuses after the operation exists.
  </Card>
</CardGroup>