Skip to main content
Realtime rails are designed for immediate processing, but approval, review, scheduling, queuing, and failure states can still delay or prevent settlement. They have no return state.

​
Before submission

Approval, scheduling, and queuing each add a status before submission, always in this order. A transfer skips any that don’t apply:
  • pending_approval while a required approver has not acted
  • scheduled while waiting for the scheduled time. Transfers created through the API are never scheduled; this status appears for transfers scheduled in the dashboard.
  • pending then pending_destination for a queued payment: pending while Slash places a hold on the source account, then pending_destination once the funds are held and until the recipient answers the information request and claims the payment
A queued payment is pending twice. First, Slash is placing a hold on the source account and nothing has been sent to the network. After the recipient claims the payment, it is pending again, now queued for network submission. If the hold can’t be placed, the transfer becomes failed.
Realtime transfer before submissionRealtime transfer before submission

​
Combinations

Each row is one combination and the statuses a realtime transfer passes through before it is queued for network submission.

​
Submission and settlement

This chart picks up where the one above ends: at pending, queued for network submission. It can pause in in_review and then becomes settled, failed, or canceled. There is no returned lifecycle state.
Realtime transfer submission and settlementRealtime transfer submission and settlement

​
Canceling

Cancel with POST /v2/transfers/realtime/{transferId}/cancel while the transfer is still pre-submission, including destination, approval, review, and scheduling holds. Once the transfer has been sent to the network, cancellation returns 409. Cancellation is idempotent after it succeeds. A rejected approval also ends the transfer as canceled, and Slash can cancel a transfer before submission.

​
Tracking status

Treat the create response as acceptance, not settlement. Retrieve GET /v2/transfers/realtime/{transferId} until it reaches a final status, or use the webhook’s entityId to retrieve a Transaction, then follow its transferId.