How to Build Products with Real-Time Payments

‍‍‍Note: Modern Treasury empowers teams to make payment operations simple, scalable, and secure. The “Guides” series walks through representative businesses or payment processes and explains step by step how best to go about building them from scratch. ‍

Introduction

For the first time in decades, the US is getting a new payment method called Real-Time Payments. For many, this comes as a welcome change since payment systems in the US have long lagged behind those elsewhere. The last new payment rail to be introduced in the US, ACH, was introduced in the 1970s.

In late 2017, banks started rolling out Real-Time Payments (RTP). You can learn more about the history and promise of RTP in our previous post about it. Rather than rehash that background or answer common questions, this post will offer a step by step guide to building an app using RTP and the customer delight moment that comes with.

RTP-enabled accounts

Since not all banks currently support RTP, the first point to confirm is whether your corporate account is enabled for sending RTP or not. If it is not, consider opening an account at an RTP-enabled bank to be able to send RTP payments.

Second, once you send an RTP payment from your account, the receiving bank account must be enabled for RTP-receive. According to the TCH sponsoring organization, over 50% of deposit accounts are now able to receive RTP payments. In the case that an account cannot receive an RTP payment, you can fail over to ACH. By 2020, TCH claims that RTP penetration will reach close to 100%. You can also run a check of RTP receive coverage within your user base by using routing numbers. [1]

Customer delight and pricing power

The reason to go to RTP is, ultimately, customer delight. (And better yet, this customer delight can be achieved for your company without any artificial float.) For example, if you are an innovative lender and want to provide customers with funds quickly, or over the weekend, you would do well to consider a 24/7, instant network.

An example you can check out is Venmo, which recently launched instant withdrawals with RTP. At the point of withdrawal, they ask you if you want the money instantly. I recently opted for the instant payout, and by the time I closed the Venmo app, opened the Wells Fargo app, and logged in, the funds were there, waiting for me:

In addition to customer delight, Venmo actually chose to charge me extra for the payment, so they realized 1% of the withdrawal where before, on ACH, it would have been free. So for certain applications, companies can charge a premium for instant payments (until it becomes the default in the US, at least).

Building RTP with Modern Treasury API calls

Building RTP into your flow of funds using Modern Treasury is quite simple.

Step 1: Collect bank account details

Just like ACH, you still need to collect a counterparty’s account information (more here on common methods of authenticating accounts, such as Plaid):

In addition to the account and routing number, you might want to hold additional information about the counterparty held in metadata. This information might include customer ID, session ID, and other information relevant to your app.

Step 2: Send RTP payment

A counterparty creation response will notify you that everything has been successfully set up. Now that a counterparty exists, you can initiate payments to them. In this case, Renata Realtime is going to receive a $500 advance from her payroll provider. Note that the amount is in cents, not dollars, so it shows up as 50000:

Seconds later, the payment goes through and the company account is $500 poorer, but the customer is happy to find cash in their account.

As with the counterparty details, you want to add metadata to the payment for future reference. In addition to metadata tags (eg. key value pairs such as Type: Advance or Employer: Target) you might also attach a document to the payment. This will be useful for finance and audit teams that might have to answer questions about this payment in the future.

Step 3: What if the customer cannot receive RTP?

In this case, Modern Treasury can switch to ACH, so you would initiate a payment just as in step 2 but with "type": "ach". That way, the payment will arrive but will not be real time.

What can go wrong?

Payment operations software, such as Modern Treasury, can manage not only the happy path as described above but also edge cases when things go wrong. One nice thing about RTP payments is that unlike ACH, there will fewer RTP returns (a common issue could be handling an ACH return associated with a specific return code.)

Reconciling returns adds complexity to the accounting process because both the outgoing debit and returning credit of funds must be booked separately (usually separated by a day or two). RTP payments fail immediately if the recipient details are invalid, meaning no transaction occurs at all which simplifies the accounting in the unhappy path. No success for RTP means no transaction in the first place.

Another might be a controller or a product manager wanting to stop payments for approval before they go out. Modern Treasury allows users with the right permissions to stop payments for approval that fit specific criteria, and release them manually. This allows tech teams to debug flows and finance teams to have greater trust and monitoring of the system.

More?

Modern Treasury is working with clients launching Real-Time Payments (RTP). For any questions, or to see how integrating Modern Treasury can help make you company’s payment ops simple, scalable, and secure, request a demo of Modern Treasury today.