RTP® - Connecting with the Real-Time Payment Rails

Availability of “good funds” within seconds.The power of Real-Time Payments (RTP®) is finally part of the Dwolla platform! Over the past several months we’ve been hyper focused on delivering enhancements that are centered around speed and simplicity. Push-to-Debit, Drop-in Components and now RTP® are all product features that modernize the Dwolla platform and provide flexibility for businesses that leverage the Dwolla API to enable faster payment capabilities into their applications.

We are proud to partner with Cross River Bank (CRB) to perform the funds transfers through the RTP® Network. CRB is one of many participating financial institutions in the RTP® Network, which is operated by The Clearing House. Learn more about our approach to a simplified RTP® experience in this blog.

Eligibility and Considerations

You may be wondering, “Do I qualify as a business to utilize RTP®? What are the considerations?”

Currently, Dwolla and CRB offer RTP® transactions only to businesses sending funds from a Dwolla Balance. Any business model sending disbursements or refunds is a perfect use case for real-time payments, which would allow a consumer to receive a payment in seconds to an attached bank account.

A few key conditions of RTP® Network include:

  • Transactions cannot exceed $100,000 per push. Dwolla may establish additional limitations on RTP® transactions.
  • The receiving bank account must be within the U.S. at an RTP® Network participating financial institution.
  • RTP® transactions are final and irrevocable.

Changes in the Dwolla API

Identifying an RTP®-enabled Funding Source

On the Dwolla Platform, Funding Sources represent a resource that reflects a payment account that can be added for sending and/or receiving funds transfers. Bank accounts are a type of Funding Source that can be added and retrieved. Available on both the Dwolla Master Account and Customer (End User) resources, Funding Sources have represented accounts used for ACH, Wire, and/or Push-to-Debit activities. Dwolla will be able to identify a bank account as RTP®-enabled, so no additional information is needed from your end users or application. The following section explores the changes to support RTP®-enabled funding sources.

Retrieve a Funding Source

The “channels” attribute on the Funding Source resource represents the different capabilities available for transfer processing. For a bank account, historically the only values available have been “ach” and “wire”. Outlined below represents how “real-time-payments” will be added to the “channels” array to identify an RTP® eligible account.

Channels including ACH, RTP, & Wire
"channels": [

Initiating an RTP® Credit Transfer

A transfer represents money being transferred from a source to a destination. Transfers are available for the Dwolla Master Account and Customer (End User) resources. The following section explores updates to transfer related endpoints to support real-time payments.

Initiate a Transfer

When initiating a transfer, RTP® will be available on the destination bank account only. Below summarizes the addition of a “processingChannel” object to support a destination of a RTP®-enabled bank account.

processingChannel JSON Object
"processingChannel": {
    "destination": "real-time-payments"
Example Transfer HTTP request with RTP® processing
    POST https://api.dwolla.com/transfers
    Accept: application/vnd.dwolla.v1.hal+json
    Content-Type: application/vnd.dwolla.v1.hal+json
    Authorization: Bearer {accessToken}

    "_links": {
        "source": {
            "href": "https://api-sandbox.dwolla.com/funding-sources/{sourceFundingSource}"
        "destination": {
            "href": "https://api-sandbox.dwolla.com/funding-sources/{destinationFundingSource}"
    "amount": {
        "currency": "USD",
        "value": "10.00"
    "processingChannel": {
        "destination": "real-time-payments"
Retrieving a Transfer

In addition to passing in the appropriate processingChannel when initiating a transfer, the “processingChannel” object will also be returned when retrieving a Transfer sent as RTP®.

"processingChannel": {
    "destination": "real-time-payments"

Webhook Notifications

Webhooks notification events will be processed in the same sequence as an ACH transfer. The primary difference is the transfer will be created and the success/failure moments later (rather than days). The specific events include:

Event Description
customer_bank_transfer_created Sent when the RTP transfer is created
customer_bank_transfer_failed Sent if the RTP transfer fails*
customer_bank_transfer_completed Sent if the RTP transfer is completed successfully
customer_funding_source_channels_updated Sent when a funding source is identified as RTP eligible

What’s Next?

With Dwolla’s new RTP® functionality, you now have a seamless way to add real-time bank transfers as a part of your integrated payment solution with Dwolla’s technology. Want to learn more? Check out our updated Developer Docs to get more of the details on implementing this exciting new feature.

Do you have feedback or are interested in testing RTP® transfers in the Sandbox environment? Tell us in the thread below :point_down:

1 Like

This is epic! One question - the docs say it’s a “premium feature,” does that mean it’s only for customers with a sales contract or can it be enabled for Pay-As-You-Go plan customers?

I’m currently trying to test RTP in a sandbox environment, but have a couple questions.

If I attempt an RTP transfer to a funding source that does not support RTP, will it fallback to ACH? Or will the transfer fail entirely?

Also is there a sandbox funding source that has RTP disabled so I could test this myself?

1 Like

Hi @abe , It’s currently not available for Pay-as-you-go customers at this time. However, I’ll pass along this feedback to see if this feature can be supported in that pricing tier in the future.

Hi @Cristian_Saucedo , That’s a great question. It should fail entirely and not fallback to ACH automatically. We made this decision assuming that clients may want to choose a different payment modality if the real-time-payment request failed.

Right now we are working through various updates relating to testing RTP success and failure cases in the Sandbox. I believe all existing funding sources will have RTP disabled by default. All new funding sources(Bank Accounts) added using a routing number of an RTP supported bank will have the real-time-payments value show up in the list of channels.

Please feel free to reach out to @spencer @kmoreira or @shreya via Direct message with your Sandbox email or account ID and we can get this feature enabled. It’s behind a permissioned flag that needs to be enabled prior to testing.

1 Like

Thanks for the write up @spencer ! One point I’m not clear on, can you provide any detail?

I’m noticing that the real time payments channel will now cause a failure in one of our sandbox environments if it’s being included on a transfer going from bank account => bank account (not a balance). The err message indicates it must be sent from a balance. Interestingly this wasn’t happening in our production environment. Can you confirm that processingChannel: 'real-time-payments' will cause a transfer to fail, if that transfer is not originating from a balance? Is this a change or am I mistaken?

Say I’m creating a transfer from one verified customer’s bank to another (most of the transfers on our platform). I know there are usually 3 transfers under the hood, right? Bank => balance, balance => balance, balance => bank.

Assuming the destination account supports RTP, I could create a transfer from the verified customer’s bank to their balance, and after that completes, create a RTP from that customer’s balance to the destination bank account.

I would much prefer to create a transfer with the source and destination as the verified customers’s banks, pass in processingChannel: 'real-time-payments' and have the Dwolla network automatically create a RTP for the funded-transfer once the funds are in the Dwolla network. My understanding, though, is this is not how it currently works?

Confirmed. If you are passing in the processingChannel request param we’ll validate to see if the source href meets the requirements to utilize the RTP processing channel which includes being sourced from a balance. If it is not then it would return a ValidationError .

Correct. It is something we are taking into consideration and may support in the future. However, the current process for a bank to bank transaction where the debit is via ACH and the credit is RTP would need to be broken up into two API calls.

  • ACH-in bank-> balance (Source) - To fund the source user’s balance
  • RTP-out balance ->bank (Destination) - Transferring funds from source user’s balance to destination user’s bank.

Hello,I have another question. Is there a full list of possible webhooks events related to RTP? While testing in the sandbox, I’m seeing events not listed here nor in the webhooks documentation. One event I don’t see documented is customer_funding_source_rtp_enabled. That one is pretty self explanatory, but I’m wondering if there’s other’s I could be missing.

Thanks for all the help so far!

Hi @Cristian_Saucedo , thanks for pointing this out, we’ll get the documentation updated to include the missing events in this table! The missing events are customer_funding_source_rtp_enabled and customer_funding_source_rtp_disabled. These will be triggered when a financial institution contains support for RTP transfers or if they have removed support for RTP transfers respectively. The likelihood of removal is lower, but something we’ll check often against the directory of RTP enabled institutions and notify your application of a change.

1 Like