Overview
Instant Payments combine two powerful US-based payment networks to provide 24/7/365 processing of payments within minutes for banks and other financial institutions:- RTP® Network - Launched by The Clearing House in 2017 as the first new payment rail in the U.S. in over 40 years
- FedNow® Service - Launched by the Federal Reserve in July 2023, providing instant payment capabilities to over 1400 banks and financial institutions
- Greater data transparency: Get real-time tracking of payment statuses and immediate confirmation of successful payments, failed payments and errors.
- Finality: Transactions settle within seconds, and payments are irrevocable.
- Data-Driven Insights: Instant payments operate via modern protocols and allow for more data to be attached to each payment, providing valuable insights for strategic decision-making.
| ACH | Instant Payments (RTP/FedNow) |
|---|---|
| Sent via the ACH Network operators (either the Federal Reserve Bank or The Clearing House). | RTP: Sent via the RTP® Network operator, The Clearing House. FedNow: Sent via the FedNow Service, Federal Reserve. |
| Rules and regulations issued by National Automated Clearing House Association (Nacha). | RTP: Rules and regulations issued by The Clearing House (TCH). FedNow: Rules and regulations issued by the Federal Reserve. |
| Supports both credit (push) and debit (pull) transactions. | Credit (push) transfers only - no debit (pull) capabilities. |
| Funds can take 1-3 business days to be available. | Funds made available within seconds. |
| Agreed-upon processes for correcting erroneous transactions (i.e. reversal requests). | Funds are irrevocable once sent. |
Instant Payments is a premium feature available for Dwolla customers. Enabling Instant Payments does require additional Dwolla approvals before getting started. Please contact Sales or your Relationship Manager for more information on enabling this account feature.
Use cases and characteristics
Instant Payments support credit “push” transfers, whereas ACH supports credit push as well as debit pull transfers. Instant payments are particularly suited to support disbursement use cases. Whether your business is built around B2B, B2C or a combination, you can power your application with Instant Payments.- Balance Funded Transfers - Instant Payment networks are good funds models, and to initiate Instant Payments transactions through the Dwolla Platform, funds must be available in the sender’s Dwolla balance.
- Credit Sends Only - Instant Payments transactions are all credits. While the RTP network and the FedNow Service do include Request for Payment capabilities, only a very small number of financial institutions support this, and it still relies on a credit to be initiated by the payer upon receiving the request. As adoption of Request for Payment increases among businesses, we expect more FIs will support this feature.
- Network Coverage - RTP Enabled Financial Institutions now reach 71% of US Demand Deposit Accounts with over 950 participating financial institutions (with technical reach extending to institutions holding close to 90% of DDAs), while FedNow participating organizations include over 1,400 banks and financial institutions, with adoption growing at an aggressive pace.
Transaction limits
Instant Payments (defined as including both RTP and FedNow® Service) have specific transaction limits that are configured on a per-client basis. Understanding these limits is crucial for successful payment processing.Daily transaction limits
Each client has a configurable daily transaction limit that applies to all instant payment transactions made under their account. This includes transactions initiated by the client and their customers.- Reset time: Daily limits reset at 12:00 midnight Central Time (CT).
- Configuration: Limits are set during client onboarding and can be adjusted based on your business needs.
Daily transaction limits are configured on a per-client basis and are not set by default. Contact your Relationship Manager to configure appropriate limits for your use case.
Per-transaction limits
Individual instant payment transactions are structured with a maximum limit of $100,000 per transaction. This limit applies regardless of your daily transaction limit configuration.Error handling for exceeding limit
When a transaction exceeds the daily limit the Dwolla API will return a HTTP 400ValidationError with specific details about the limit violation.
Once you reach your daily transaction limit, you cannot process additional instant payment transactions until the limit resets at midnight CT. Plan your payment volumes accordingly to avoid service interruptions.
Identifying an Instant Payment-enabled Funding Source
On the Dwolla Platform, Funding Sources allow bank accounts to be added or retrieved. Available for both a Dwolla Master Account and Customers (end users) resources, Funding Sources have represented payment accounts used for ACH and/or wire activities. Dwolla will be able to identify a bank account as Instant Payment-enabled upon creation of a Funding Source, so no additional information is needed from your end users or application.Retrieving an Instant Payment-enabled Funding Source
When retrieving an existing Funding Source resource from the API, the response will contain a “channels” attribute which represents the different capabilities available for transfers. For a bank account, historically the only values available have been “ach” and “wire”. The example below represents how “real-time-payments” is returned within the “channels” array to identify an Instant Payment-eligible account (supporting either RTP, FedNow, or both).The
real-time-payments channel indicates eligibility for Instant Payments. The specific Instant Payments method used, RTP or FedNow, is determined internally based on availability and company preference when a transfer is initiated. This channel value remains the same regardless of whether the Funding Source supports RTP, FedNow, or both networks.Initiating an Instant Payment transfer
In order to initiate a transfer with Instant Payment processing, an optionalprocessingChannel JSON object must be included in the transfer request. The processingChannel object contains the destination key with a value of instant. You can also use real-time-payments as an acceptable alternative value. The processingChannel object will be returned when retrieving the transfer from the API, though the returned value may differ from the request value depending on the payment network used (see retrieval examples below).
An optional instantDetails object can be included in the transfer request body. This allows additional information to be passed to the payment recipient’s bank account about their Instant Payment credit transfer. For backward compatibility, you may also use rtpDetails, but instantDetails is recommended for new integrations.
The following example assumes the sending party has funds pre-loaded to their balance Funding Source and that the destination party has a bank account connected that is Instant Payments-enabled.
Recommended approach for new integrations: Use
instant as the processingChannel.destination value and instantDetails for remittance data. This combination provides the most modern and future-proof approach for Instant Payments.Backward compatibility options: You can also use real-time-payments as the processing channel and rtpDetails for remittance data, or mix and match as needed. Both instantDetails and rtpDetails are functionally equivalent and will work with both RTP and FedNow transfers.Retrieving an Instant Payment transfer
When retrieving the transfer from the API, the response will contain either anrtpDetails object (for RTP transfers) or a fedNowDetails object (for FedNow transfers), depending on which payment network was used. Both objects have the same structure and contain a destination JSON object that includes:
remittanceData- The remittance data if included in the original transfer requestnetworkId- A unique identifier for the transfer within the payment networkendToEndReferenceId- An end-to-end reference identifier for the transfer
The
fedNowDetails object only appears in API responses and has the same structure as rtpDetails. You cannot include fedNowDetails in transfer creation requests - use rtpDetails or instantDetails for request payloads.Request and response examples
RTP Transfer Response:The response will contain either
rtpDetails (for RTP transfers) or fedNowDetails (for FedNow transfers) depending on which payment method was used. Both objects have identical structure but contain network-specific identifiers. This allows you to identify the specific payment network used for troubleshooting purposes.Processing Channel Behavior: The processingChannel.destination value in the response reflects the actual payment network used, regardless of the original request value:- If the transfer went via FedNow, the response will show
fed-now - If the transfer went via RTP, the response will show
real-time-payments
real-time-payments in your request, if the destination bank only supports FedNow, the response will show fed-now to indicate the actual network used.Webhook notifications
Webhook notification events will be processed in the same sequence as an ACH transfer. The primary difference is that once the transfer is created, the completion or failure events will be triggered moments later rather than days. The specific events include -| Event Topic | Description |
|---|---|
| customer_bank_transfer_created | Sent when the Instant Payment transfer is created |
| customer_bank_transfer_failed | Sent if the Instant Payment transfer fails* |
| customer_bank_transfer_completed | Sent when the Instant Payment transfer is completed successfully |
| customer_funding_source_rtp_enabled | Sent when a funding source is identified as Instant Payment eligible |
| customer_funding_source_rtp_disabled | Sent when an Instant Payment eligible funding source is later identified as ineligible |
The webhook event names remain the same for both RTP and FedNow transfers. The
customer_funding_source_rtp_enabled and customer_funding_source_rtp_disabled events are used for all Instant Payment eligibility changes, regardless of whether the funding source supports RTP, FedNow, or both networks. This means you’ll receive the same webhook events whether a funding source becomes eligible for RTP, FedNow, or both payment methods.Error Codes
Error codes provide the reason a message did not complete and can be found on the paymentResult.Code. The Result.Code will be OK if the payment was successfully sent/received.
| Code | Description |
|---|---|
| 650 | Cannot parse the message |
| 690 | Signature mismatch or verification error |
| BLKD | Payment has been blocked |
| AC02 | Debtor account is invalid |
| AC03 | Creditor account is invalid |
| AC04 | Account closed |
| AC06 | Account is blocked |
| AC07 | Creditor account closed |
| AC10 | Debtor account currency is invalid or missing |
| AC11 | Creditor account currency is invalid or missing |
| AC13 | Debtor account type missing or invalid |
| AC14 | Creditor account type missing or invalid |
| AG01 | Transaction is forbidden on this type of account |
| AG03 | Transaction type is not supported/authorized on this account |
| AGNT | Incorrect Agent |
| AM02 | Specific transaction/message amount is greater than allowed maximum |
| AM04 | Amount of funds available to cover specified message amount is insufficient |
| AM09 | Amount received is not the amount agreed or expected |
| AM11 | Transaction currency is invalid or missing |
| AM12 | Amount is invalid or missing |
| AM13 | Transaction amount exceeds limits set by clearing system |
| AM14 | Transaction amount exceeds limits agreed between bank and client |
| BE04 | Specification of creditor’s address, which is required for payment, is missing/not correct |
| BE06 | End customer specified is not known at associated Sort/National Bank Code or no longer exists in the books |
| BE07 | Specification of debtor’s address, which is required for payment, is missing/not correct |
| BE10 | Debtor country code is missing or invalid |
| BE11 | Creditor country code is missing or invalid |
| BE13 | Country code of debtor’s residence is missing or invalid |
| BE14 | Country code of creditor’s residence is missing or invalid |
| BE16 | Debtor identification code missing or invalid |
| BE17 | Creditor identification code missing or invalid |
| DS24 | Waiting time expired due to incomplete order |
| DT04 | Future date is not supported |
| DUPL | Payment is a duplicate of another payment |
| DS0H | Signer is not allowed to sign for this account |
| FF02 | Syntax error reason is provided as narrative information in the additional reason information |
| FF03 | Invalid Payment Type Information |
| FF08 | End to End ID is missing or invalid |
| MD07 | End customer is deceased |
| NARR | Reason is provided as narrative information in the additional reason information |
| NARR | Cannot validate retail account number |
| RC01 | Bank identifier code specified in the message has an incorrect format |
| RC02 | Bank identified is invalid or missing |
| RC03 | Debtor FI identifier is invalid or missing |
| RC04 | Creditor FI identifier is invalid or missing |
| TM01 | Invalid Cut Off Time |
| TK01 | Invalid Token |
| TK02 | Sender Token Not Found |
| TK03 | Receiver Token Not Found |
| TK04 | Token Expired |
| TK05 | Token Found with Counterparty Mismatch |
| TK06 | Token Found with Value Limit Rule Violation |
| TK07 | Single Use Token Already Used |
| TK08 | Token Suspended |
| NOAT | Receiving Customer Account does not support/accept this message type |
| OK | Completed |
| 1100 | Any Other Reasons Reason is provided as narrative in the additional information |
| 9909 | Central Switch (RTP) system malfunction |
| 9910 | Instructed Agent signed-off |
| 9912 | Recipient connection is not available |
| 9934 | Instructing Agent signed-off |
| 9946 | Instructing Agent suspended |
| 9947 | Instructed Agent suspended |
| 9948 | Central Switch (RTP) service is suspended |