Skip to main content

​
Overview

When a user completes a transfer in a widget, RaaS Widgets creates an operation. From that moment you track progress with the Partner API field status and the matching operation.* webhooks. You do not need to model corridor-level processing steps. Subscribe to create and terminal events, and poll Operations if you need the current status between deliveries.

​
Status values

There is no operation.expired webhook. Funding expiry and similar outcomes map to cancelled.

​
Status graph

​
Typical happy path

  1. Widget creates the operation → status: created → webhook operation.created
  2. Corridor accepts the transfer → status: processing (no dedicated webhook; poll if needed)
  3. Corridor settles → status: completed → webhook operation.completed

​
Failure and cancel paths

From created or processing, the operation can end in:
  • failed → operation.failed
  • cancelled → operation.cancelled
If you reserve balances or locks on operation.created, reverse them on operation.failed or operation.cancelled. Treat only operation.completed as final success for fulfillment.

​
Webhooks vs API

Payload shapes: Webhook events.
Handlers should be idempotent. Retries can redeliver the same terminal event. Key on operationId + event type.

​
Correlation fields

Use requestId to tie settlement webhooks back to the original money request — see Request money lifecycle.

​
Next steps

Webhook events

Full payload reference for operation.*.

Operations API

List and fetch operations for reconciliation.

Request money lifecycle

How Request API and fund-request links become operations.

Webhooks overview

Delivery, retries, and configuration.