RTP Queueing Functional Documentation

Background

In the RTP network, each participating bank must establish a connection with the RTP system to send and receive RTP payments. From time to time, each participating bank will be unavailable to transact, either due to routine maintenance or to unknown technical issues that are resolvable with time. If an RTP payment is sent to a participating bank that is not available, the payment will be rejected.

Purpose

Cross River has created a user experience for partners to submit RTP payments to participating banks when they are unavailable, and instead of the payment being rejected, CRB will queue the payment until the receiving institution is online and then originate the payment.

How it works

1. Payment is submitted to CRB via API

• Can optionally include a queue expiration date in the event the payment is queued due to RDFI offline.
• Expiration date will determine how long a payment will wait in queue for the RDFI to go back online before turning to a canceled status.
• Expiration date will not support a time component and will only be used in the unlikely event an RDFI is offline for an extended period.

2. If the receiving institution is offline:

• Payment status changes to “Queued”.
  • You will receive a ‘Rtp.Payment.Queued” webhook
  • Once the receiving institution is back online:
  • Payment status changes to “Processing” and sent to RDFI.
  • Processing status indicates the payment has been sent to the RDFI and we are awaiting a response. Payment can no longer be canceled and must wait for a response from RTP network.
• If payment expiration date is reached while the receiving institution is still offline:
  • COS will cancel payment.
  • Payment status changes to “Canceled”
  • Webhook “Rtp.Payment.Canceled” created.

3. If receiving institution is online

• Payment will flow through as normal

Q&A

How Long Can a Payment Remain Queued?
All payments will have a default queue expiration of 3 days. In the event a payment’s queue expiration is reached, CRB will cancel the payment and you will receive webhook Rtp.Payment.Canceled.

Can I set my own queue expiration date for a payment?
Yes. When submitting your payment request, include queuedPaymentExpiresAt. Below is a sample request. The additional field is at the bottom. Note that queuedPaymentExpiresAt is a DateTime type attribute and should be entered as such. The time should be US Eastern Standard Time.

POST /v1/payments
{
"accountNumber": "2553179843",
"amount": 15000,
"creditor": {
"routingNumber": "011000138",
"accountNumber": "456789000",
"name": "Cleveland Brown",
"addressStreetName": "Spooner St",
"addressBuildingNumber": "34",
"addressCity": "Quahog",
"addressState": "RI",
"addressPostalCode": "00093",
"addressCountry": "US"
"addressCountry": "US"
},
"queuedPaymentExpiresAt": "2023-02-19T08:22:17.512Z"
}

• Field is optional to populate
• If not populated, default is 3 days from now
• Must be a future date/time

What if I don’t want to wait for queue expiration to be reached?
You can cancel a queued payment via the API: /v1/payments/{paymentId}/cancel

How to test in Sandbox

To simulate participants going offline, we have configured three participants to alternate between online and offline status. They will alternate status at a minimum of every 60 minutes.
To test queueing:
Register for webhook ‘Rtp.Payment.Queued’.

1. Submit payment using any of the following creditor routing numbers:

• 000000010
• 000000017
• 244084264

2. If participant is offline, ‘Rtp.Payment.Queued’ webhook will be delivered and payment status will be queued.

• Once participant goes online, payment will resume normal workflow.

3. If payment was not queued, continue to periodically submit payments until participants cycle offline.