Skip to main content
There are two requirements for sending instant payments. We recommend implementing both of these functions because instant payments, once sent, cannot be reversed.
  1. Sending Payments: Send outgoing instant payments. 
  2. Sending Return Requests: Send outgoing return requests to recover funds sent erroneously in previous outgoing instant payments.
If your customers are victims of fraud or send payments erroneously, return requests are the only recourse to recover their funds. 

Sending Payments

Sending an instant payment creates a new instant_payment object with an outgoing direction.

Endpoints

You can check if the recipient’s financial institution is available on the instant payment network and, if available, send instant payments to them. Once sent, outgoing instant payments can also be canceled. However, the cancellation window is very short and only possible if Lead has not yet submitted the payment to the network. This limited opportunity may occur during normal system processing or periods of manual review.

Statuses

Outgoing instant payments can transition through five potential statuses. Unlike returns, outgoing instant payments can terminate in the canceled status. The counterparty_status lifecycle only begins after the instant_payment object has reached a posted status. The purpose of this lifecycle is to precisely describe if/when the outgoing payment reaches the creditor.

Events

You can follow the status of an outgoing payment event throughout its entire lifecycle - from initiation at Lead to subsequent events at the counterparty financial institution.

Sending Return Requests

Sending a return request creates a new return_request sub-object within the existing outgoing instant_payment.

Endpoints

You can create a return request if you previously sent an instant payment and need to recover it.

Statuses

Outgoing return requests transition through three possible statuses from when the counterparty receives them through when they are ultimately resolved.

Events

Tracking an outgoing return request involves listening to a single event that is triggered upon each status change.