Request-to-Pay in Canada: How to Design Your First RtP Flows Ahead of RTR

Most Canadian businesses bill the same way. An invoice goes out by email, the customer logs in to online banking and keys in the amount (or mails a cheque), and someone in finance spends part of the next week matching deposits to invoices. Sending the invoice is the easy part. Getting paid still involves a lot of manual work.

Request-to-pay (RtP) aims to fix that, and the industry expects it to be one of the services built on Canada's Real-Time Rail (RTR) when it launches in Q4 2026. You don't need to wait for the launch to get started, though. The flows can be designed and tested now on payment rails you already use.

Why this matters now

Late payment is still common. According to Atradius' 2026 survey, around seven in ten Canadian companies said they deal with late payments from business customers, and overdue invoices made up 25% of B2B receivables on average. Cheques haven't gone away either. According to Payments Canada, they were just 2% of retail payment volume in 2024 but 22% of its value.

Customers seem ready for something faster. Payments Canada found that 49% of Canadians find real-time payments appealing, and 36% say they would likely switch.

What is request-to-pay?

Request-to-pay is a digital payment request that a business sends to its customer. It sets out the amount, the due date and an invoice or account reference. The customer gets it by email or text, checks the details and pays from their own bank account through online banking. When the money arrives, the original reference comes with it, so the payment can be matched to the right invoice without anyone chasing it down.

The invoice reference coming back with the payment is what sets request-to-pay apart.

It also works differently from pre-authorized debit. With a PAD, the business pulls funds under a standing agreement. With request-to-pay, the customer approves each payment and sends it from their own account, which means no NSF returns and no chargebacks.

How request-to-pay fits with the RTR

The RTR is Canada's new payment system, built to move money between bank accounts in seconds, at any time of day, with each payment final and able to carry detailed information using the ISO 20022 standard.. . Its by-law and rules took effect on August 24, 2026. It launches with a $100,000 transaction limit, and its fraud services are built in from day one, according to Payments Canada.

Payments Canada designed the RTR so that other services can be built on top of it, and request-to-pay fits that model well. For now, Interac e-Transfer^® Request Money already lets Canadian businesses send payment requests, with an optional invoice number field and automatic reminders. Business use is growing quickly, with Business Request Money transactions up 81% in Interac^®'s 2025 fiscal year.

The RTR will roll out in phases, starting with the first participants go live in Q4 2026, and two later phases will move existing Interac e-Transfer^® volumes onto the RTR, with full industry participation expected in 2027. That gives businesses roughly 12 to 18 months to design, test and learn before the rail is fully up and running.

Why leaders should start now

For executives, the case for request-to-pay rests on cash flow as much as on payments technology. Three benefits stand out.

1. Working capital: Requests that can be paid as soon as they arrive keep invoices from sitting in a queue. As an illustration, a business billing $20 million a year has about $55,000 tied up for each day of days sales outstanding (DSO), so cutting 10 days would free up roughly $548,000.
   
2. Certainty: The customer pays with money that is already in their account, so the payment can't bounce, and they never need to share their banking details with you.
   
3. Lower collection costs: Cheques are still costly to handle in Canada. A Payments Canada study put the average cost of issuing a single cheque at $15, and found that around 70% of Canadian SMEs still accept cheques, covering about 26% of their annual sales. Request-to-pay takes out that handling and avoids card fees.

Five design choices to get right

In terms of implementation, here are five key design choices you want to get correct as you’re building your request-for-payment flow:

• Make each request easy to recognize, with your business name, the amount, the due date and a reference.
• Match expiry dates to your payment terms, and resend lapsed requests automatically.
• Decide early whether you'll accept partial payments, and how you'll track them.
• Send reminders before a request expires, and make sure a retry can't trigger a duplicate payment.
• Let customers decline easily, and send declines to customer service instead of collections.
• A unique reference that stays with the payment from start to finish
• Structured remittance details, such as an invoice, policy or account number
• The amount and the date you've asked to be paid
• Details of both the business requesting payment and the customer paying

Let the data do the matching

ISO 20022 is the messaging standard behind the RTR. A request built on it can carry:

You can get much of this benefit today. DCPayments' Direct Deposit Tracking uses unique sub-ledger numbers to match incoming Interac e-Transfer^® and EFT payments automatically.

A three-phase roadmap to launch day

Most of the value is available before the RTR goes live. Start with one or two collection points where slow payment costs you, such as rent, insurance premiums or B2B invoices under $25,000, and run them on Interac e-Transfer^® Request Money with DCPayments' APIs. From there, build a request layer that isn't tied to one rail, connect it to your ERP, and add the RTR as it becomes available.

Build trust in from day one

A request for money is exactly the kind of message fraudsters like to copy, so trust has to be designed in. Only send requests to customers who have agreed to receive them, show your business name and a reference they'll recognize so they know it's really from you, and make it just as easy for them to accept a genuine request as to decline one that looks wrong. The RTR's mandatory fraud services will help, but you'll still need your own controls.

How to measure success

Record a baseline for these four measures before the pilot starts, so you can prove the case with your own numbers.

The bottom line

The RTR will make request-to-pay faster and give it richer data, but the flows themselves still have to be designed. Businesses that arrive at launch with a tested pilot will be in the best position to use it.

Ready to prototype request-to-pay?

DCPayments helps Canadian businesses, platforms and marketplaces build request-to-pay flows on Interac e-Transfer^® and EFT today. Book a technical scoping session to prototype RtP with DCP APIs.

Further reading

• The Future of Payments in Canada: Inside the Launch of the Real-Time Rail
• What Canada Can Learn from the UK's Real-Time Payments Adoption
• The Way We Pay: A Mid-Year Review of the Payments Trends Shaping 2026

Frequently asked questions

What is Request-to-Pay in Canada?

Request-to-pay (RtP) lets a business send a customer a digital request to pay a set amount by a set date. The customer gets the request by email or text and pays it from their own bank account through online banking, with the business's reference attached. In Canada, Interac e-Transfer^® Request Money already works this way.

How will RtP work with Canada's RTR?

The Real-Time Rail launches in Q4 2026. It will clear and settle ISO 20022 payments in seconds, 24/7, with an initial $100,000 transaction limit. Payments Canada designed it so other services can be built on top of the rail, which means request-to-pay services could run on the RTR, with the rail carrying the payment for each request.

How can businesses pilot RtP before RTR launches?

Start with one or two collection points on Interac e-Transfer^® Request Money, using provider APIs to send requests, track their status and reconcile payments automatically. Then build a request layer that isn't tied to one rail and map ISO 20022 references to your ERP. Adding the RTR later then becomes a routing decision instead of a rebuild.