Before submission
Approval, scheduling, and queuing each add a status before submission, always in this order. A wire skips any that don’t apply:pending_approvalwhile a required approver has not actedscheduledwhile waiting for the scheduled time. Wires created through the API are never scheduled; this status appears for wires scheduled in the dashboard.pendingthenpending_destinationfor a queued payment:pendingwhile Slash places a hold on the source account, thenpending_destinationonce the funds are held and until the recipient answers the information request and claims the payment
pending twice. First, Slash is placing a hold on the
source account and nothing has been sent to the bank. After the recipient
claims the payment, it is pending again, now queued for bank submission. If
the hold can’t be placed, the wire becomes failed.
Combinations
Each row is one combination and the statuses a wire passes through before it is queued for bank submission.Submission and settlement
This chart picks up where the one above ends: atpending, queued for
bank submission. A wire can pause in in_review. It then becomes:
settledafter successful completionfailedif it does not completecanceledif it is canceled before submission (see Canceling)returnedif the beneficiary bank later sends the funds back
Canceling
Cancel withPOST /v2/transfers/wire/{transferId}/cancel while the wire is still
pre-submission, including destination, approval, review, and scheduling holds.
Once the wire has been sent to the bank, cancellation returns 409.
Cancellation is idempotent after it succeeds. A rejected approval also ends the
wire as canceled, and Slash can cancel a wire before submission.
Tracking status
Network identifiers appear as they become available:wire.imad and
wire.omad. Poll GET /v2/transfers/wire/{transferId} or use the webhook’s
entityId to retrieve a Transaction, then follow its transferId.