A business receives a $5,000 payment on Saturday afternoon. The funds reach its account in seconds. Inside your software, the business can see the payment, check its updated available balance, and decide what to do with the money next.
Receiving real-time payments makes that experience possible outside the banking-day schedules that govern ACH and wires. Building it into your product means connecting incoming funds to the account, information, and workflows your customers already use.
This guide explains the product decisions behind receiving RTP: recognizing completed payments, displaying balances, identifying incoming funds, and handling exceptions.
TLDR:
- Receiving RTP can support customer account funding and business collections around the clock, including weekends and holidays.
- A payment record being created and a payment completing are distinct events. Your application should use the documented outcome to determine what it tells the customer.
- Payment data helps connect incoming money to customers and business activity. Matching an invoice or order still requires application logic.
- Unit supports both sending and receiving RTP on the same native ledger and dashboard as its other payment rails.
How Receiving Real-Time Payments Works
The sender initiates a payment through a financial institution that supports sending over The Clearing House RTP network. The receiving institution must support receiving, and the destination account must be eligible. Accepted payments settle in seconds, with funds available around the clock under applicable network rules.
For a software company, receiving can serve several purposes. A customer might transfer money from an external bank account to fund the account in your product. A business might receive payment from a buyer. In either case, the incoming funds need to appear in the right account and become visible in the application.
RTP does not let your software debit an external account. The sender initiates the transfer. Your funding instructions should explain how to send to the destination account and offer another supported method when the sender cannot use RTP.
For network mechanics and rail comparisons, see our RTP overview.
What account eligibility is required to receive RTP?
Receiving RTP payments generally requires support at both ends: the originating institution typically needs to support sending, and the destination institution and account (sometimes structured as an FBO account) need to support receiving. Receive capability does not imply send capability.
Give the sender the correct routing and destination account numbers and instructions for authorizing an RTP push through their institution. Confirm institution and account limits, which can be lower than the network’s transaction ceiling.
If the sender’s institution cannot send RTP, your funding flow should show supported alternatives, such as ACH funding or a wire, with expected timing for each, as real-time payments become more widely available.
Responding to Incoming Payment Events
Your application needs to connect the payment outcome to what the customer sees: transaction activity, available balance, and any notification or next step.
Start by distinguishing incoming activity from confirmed completion. Unit’s receiving webhook documentation describes separate events for a received payment being created, completing, and generating a transaction.
In the Saturday example, completion is the point at which the application can tell the business that its $5,000 payment arrived. The balance shown should come from the account system, while the activity view should identify the corresponding payment and transaction. Avoid independently adding money to the displayed balance each time a notification arrives.
From there, the workflow depends on your product. An account-funding experience might notify the customer that funds are available. An accounts-receivable product might attempt to match the payment to an invoice. Neither requires the customer to leave your software to check a separate bank portal.
Design event processing so repeated notifications do not create repeated actions. If an event is missed or the application needs to recover, retrieve the payment and transaction records and compare them with the application’s state. A delay in your software should not be presented as a confirmed payment failure.
How do you match an incoming RTP payment to an invoice?
Identifying the receiving account and identifying the business purpose of a payment are separate tasks. The account relationship tells your software where the money arrived. Other payment information can help explain why it arrived.
Unit’s received-payment resources include account relationships, sender information, descriptions, payment identifiers, and remittance fields. Your matching rules should account for the information actually provided with each payment.
For account funding, identifying the destination account may be enough to present the receipt to the customer. For invoice collection, the software needs a further matching step.
Suppose the $5,000 payment includes an invoice reference. Your application can compare that reference, the amount, and available payer information with the outstanding invoice. If two invoices have the same total and no reliable reference is supplied, the amount alone is insufficient to choose between them.
Record the receipt and route ambiguous matches for review. Funds can have arrived successfully even when your application has not determined which invoice to close. Keeping those states separate gives customers an accurate balance without overstating what your automation has resolved.
What happens when an incoming payment does not complete?
Instant settlement does not eliminate exceptions. Your product should distinguish a payment still awaiting completion from one rejected before crediting, and distinguish both from a subsequent return of funds.
For unresolved activity, show a clear message such as “Awaiting confirmation.” For a rejected payment, use the available reason information to guide support and customer communication. An application timeout alone is not a reason to ask the payer to send again, as the original payment may have completed even if your interface has not caught up.
Keep payment identifiers, transaction links, timestamps, and reason information available to the teams investigating an issue. These records help establish what happened without relying on a customer’s screenshot or recollection.
Final settlement and returning funds are also distinct. A completed RTP payment cannot simply be canceled by the sender; a separate return process may apply. Preserve the connection between the original receipt and any subsequent movement of funds.
Keeping Incoming RTP Workflows Reliable
Receiving RTP payments calls for reliable event handling. Authenticate webhooks and process duplicates idempotently with durable identifiers to help prevent repeat fulfillment or notifications. Handle delayed and out-of-order events without letting older events overwrite completed states.
Recover by retrieving authoritative payment and transaction records, comparing them with application state, and repairing gaps. Audit processing attempts and corrections. Track application lag separately from settlement timing to distinguish internal backlogs from network delays.
Before launch, assign escalation owners for ongoing coverage:
- Weekend coverage: Name the on-call lead and bank escalation contact.
- Missing notifications: Engineering owns detection and record recovery.
- Unavailable dependencies: Engineering owns retries; product defines the degraded experience.
- Payments awaiting a match: Assign a review owner and escalation deadline.
- Suspicious incoming activity: Route alerts to the designated risk team and bank contact through the agreed response process.
How Unit Approaches Receiving RTP Payments
Unit enables software companies to send and receive RTP payments in seconds, 24/7/365. Unit connects directly to The Clearing House, without an intermediary processor. RTP uses the same native ledger and dashboard as ACH, wires, checks, and international payments.
Incoming RTP payments are processed automatically. When a payment completes, it credits the account and creates a related transaction. Webhook events let your application respond to payment activity, while the payment resource provides status, sender information, remittance fields, and relationships to account and transaction records.
RTP also uses the same received-payments endpoints as incoming ACH and wire payments. Teams can retrieve receipts across those rails or filter specifically for RTP, supporting a consistent view of incoming money.
That shared infrastructure connects receipt to the customer’s next action. A business can receive money over RTP on a weekend and use available funds through supported card or payment capabilities. The application decides how to present the receipt, match business records, and trigger its own workflows.
Final thoughts on Reliable RTP Receipts
You can help keep receipts traceable without guessing which invoice they satisfy. Give your team a clear review path for missing references. Explore the receiving documentation or talk to our team about your account and payment flow.
FAQ
Does receiving RTP mean an institution also supports sending it?
No. Sending and receiving are separate capabilities. For an incoming payment, the payer’s institution must support sending and the destination must support receiving. Unit supports both, subject to applicable eligibility and program requirements.
Can RTP fund a customer account on weekends?
Yes. The network operates 24/7/365, including weekends and holidays. An eligible customer can receive a transfer initiated through an institution that supports sending RTP. Your product should reflect confirmed completion and the account’s available balance.
Does receiving RTP automatically reconcile an invoice?
No. Receiving the funds establishes the account credit. Invoice matching depends on your application’s records and the payment information supplied. References and sender details can support matching, while incomplete or ambiguous information may require review.
The content in this article is provided for general informational and educational purposes only and should not be construed as legal, tax, accounting, or regulatory advice. Unit does not warrant or guarantee the accuracy, completeness, adequacy, or currency of the information provided, and the content may not reflect all considerations relevant to a particular business, product, or use case.
Unit is a financial technology company and is not a bank. Banking services are provided by Unit's bank partner(s), Members FDIC. Unit provides technology infrastructure and program management services to enable clients to offer financial products.
