Skip to main content
Queued payments support ACH, realtime (RTP and FedNow) and domestic wire transfers. International wires require a saved destinationId when the transfer is created. Queued payments can’t be scheduled yet. Use a queued payment when you know whom to pay but the recipient has not yet supplied a bank account:
  1. Create a recipient with their email.
  2. Create an information request asking for a bank_account destination.
  3. Create the transfer with POST /v2/transfers/ach, POST /v2/transfers/realtime or POST /v2/transfers/wire, using informationRequestId instead of destinationId.
informationRequestId and destinationId are mutually exclusive.
The Transfer returns with status: "pending", or "pending_approval" while a required approver has not acted, and keeps the same transfer_intent_ id throughout the flow. This first pending means Slash is placing a hold on the source account; nothing has been sent to the payment network. Once its funds are held, it moves to pending_destination until the recipient answers the information request and claims the payment. pending_destination does not mean the payment has settled or that the recipient will complete the request. If the hold can’t be placed, the transfer becomes failed.
ACH transfer before submissionACH transfer before submission
Realtime and wire transfers follow the same steps; see the realtime and wire lifecycles. Once the recipient claims the payment, Slash attaches their destination to the Transfer and it returns to pending, now queued for submission on the rail it was created on, and continues normal processing. Retrieve the Transfer to observe the new destinationId and status. For a realtime or wire transfer, the recipient’s bank account must be able to receive that rail. Cancel the queued payment with POST /v2/transfers/ach/{transferId}/cancel, POST /v2/transfers/realtime/{transferId}/cancel or POST /v2/transfers/wire/{transferId}/cancel. Canceling the Information Request does not cancel a Transfer that already references it.