RTP (Real Time Payments)

Real Time Payments is an electronic payment network governed by The Clearing House that runs 24 hours a day, 7 days a week, 365 days per year. This allows participating financial institutions to send and receive payments immediately, at any time, including weekends and holidays. Because of this immediate availability, Real Time Payments are not reversible. This network works in a similar way to other payment methods like Same Day ACH in that it only allows credit push payments.

How is this different from peer-to-peer services such as Zelle and Venmo? Peer-to-Peer services rely on multiple payment rails to send funds. Depending on the sending and receiving banks and their agreements, the funds may be sent via ACH or other payment channels. The sender has no ability to choose the payment rail used, and the timeframes and monetary limits may vary by service and financial institution. Victor sends RTP payments through the network's rails without the need for an additional peer-to-peer service.

While RTP credit-only, it is a broad term that encompasses multiple facets to support the sending of payments:

RTP Send – an outbound push payment
Request for Payment (RfP) – a request to an account holder via the account holder’s Financial Institution for payment. This is only a request and not a transaction - if the request is approved, then an RTP credit payment may be created and sent on the account holder’s behalf
RTP Refund Request – a request to a Financial Institution to refund a previous RTP Send payment. As stated above, RTP is a credit-only payment type and is intended to be irrevocable. While the network does support the ability to request refunds, there is no guarantee that they will be honored and it requires manual remediation involving both Financial Institutions involved in the transaction.

RTP is not currently supported by all Financial Institutions in the US, though adoption is quickly growing. According to The Clearing House, the RTP network is currently accessible to financial institutions that hold close to 90% of US Demand Deposit Accounts (DDAs) and the network currently reaches 65% of US DDAs (as of MAR 2023). Click here for a list of participating Financial Institutions.

As the list of participating FIs grows and they add support for the for the different facets of RTP outlined above, Victor has provided an Eligibility Endpoint within the API to see if a given FI is on the network and which aspects of RTP they support. This Eligibility endpoint is available here: https://docs.victorfi.com/reference/rtpbankeligibility

RTP Statuses

RTPs created in Victor are transmitted to the bank for processing shortly after they are created. The status of an RTP be tracked through the following states. There are also stataes for received RTPs (Inbound RTP).

RTP Send Statuses

Created - RTP Sends enter a Created state when the object is initially created. Transactions typically immediately transit from this status toPending
Declined - Transaction Declined; RTP network rejection
Failed- General / default / unknown processing errors
Pending - Transaction posted successfully to RTP Network
Sent - Money transferred to the payee
Success - The transaction is completed successfully
Pending Approval - On Hold for analysis

RTP Refund Statuses

Pending - Refund request transaction posted successfully on the RTP network
Sent - Money transferred back to the payer
Success - The refund transaction is completed successfully
Declined - manual review decline; RTP network rejection
Failed- General / default / unknown processing errors

RTP Receive (Inbound RTP)

Sent - Money transferred to the payee
Success - The transaction is completed successfully
Declined - Transaction Declined; RTP network rejection
Failed - General / default / unknown processing errors

Memo Notes

Memo notes of RTP payments for both the sending party, and receiving party may be amended by utilizing the ultimate_creditor, and ultimate_debtor fields to avoid confusion within your organization, and that of the end beneficiary of the payment.

Example
Victor Client PaySystems Inc. is a payment processor helping hundreds of merchants to process payments for end consumers. An end consumer doesn’t have any knowledge of PaySystems Inc. as all of their interactions is with the merchant. Paysystems Inc. therefore want to include a reference in the payment to avoid confusion as to the purpose of the payment.

For an originating account (owned by Victor client), the memo notes for an RTP Send will appear as follows:

RTP Credit toULTIMATE_CREDITOR viaCREDITOR (for example, RTP Credit to "John Doe" via "Merchant Inc.")
Note CREDITOR will now be one of the following (in order of occurrence):

The name on the virtual account, if the payment is being sent from a virtual account or,
The name on the core account unless, if the payment is being sent from a core account.

A recipient would then see the following:
RTP Deposit fromULTIMATE_DEBTOR viaDEBTOR (for example, RTP Deposit from "Merchant Inc." via “PaySystems Inc.”) Note DEBTOR is the legal name on the sending account and cannot be changed.

Note: The receiving bank may still not display this information. This feature is only effective if the receiving bank’s core banking provider populates the memo details.