If your business collects the same payment from the same customer on a regular schedule, membership dues, loan installments, rent, or ongoing service fees, Pre-Authorized Debit (PAD) is worth understanding even if you don't end up using it. PAD lets you pull funds directly from a customer's bank account instead of charging a credit card. It's common in Canada for exactly this kind of billing, but it comes with its own rules, timelines, and failure patterns that are different enough from card payments to trip up a business that assumes they work the same way.
What PAD Is, and Why Businesses Use It
PAD is an electronic funds transfer that moves money out of a customer's bank account into yours, based on a standing authorization the customer gave you in advance. It runs through the same clearing system as other interbank transfers in Canada, not through a card network. Businesses lean on it for recurring billing because it tends to have fewer involuntary interruptions than card billing: there's no card expiry to track, no card reissue after a security breach, and no customer forgetting to update a card number. Once a mandate is in place, the debit keeps running until the customer cancels or the agreement ends.
How PAD Differs From Credit Card and Interac-Based Billing
Credit card billing gives you an answer in seconds: approved or declined. PAD doesn't work that way. You submit the debit, and it clears through the banking system over the following business days. If there isn't enough money in the account, or the account is closed, you find out after the fact through a returned item, not at the moment of the transaction. That delay is the single biggest mental shift for teams moving from card billing to PAD. If you're also considering Interac-based options for one-time payments, it's worth reading about accepting Interac Debit and e-Transfer separately, since that's a different mechanism built for one-time purchases rather than standing recurring debits.
The Rules Behind Every PAD Transaction
PAD in Canada operates under a Payments Canada rule that every financial institution and payment processor agrees to follow. It sets out what a valid authorization has to contain, how much notice customers need before a debit, and what rights a customer has to dispute a debit they didn't agree to. You don't need to read the rule itself to use PAD responsibly, but your payment processor or PAD-enabled platform should be building its mandate forms and dispute handling around it. If a provider can't explain how their mandate and notification process satisfies these requirements, that's a sign to ask more questions before signing on.
What a Valid PAD Mandate Must Include
The mandate (sometimes called a PAD agreement) is the written or electronic authorization the customer gives you. A proper mandate sets out the amount being debited or how that amount will be calculated, the frequency and timing of debits, the customer's right to cancel at any time, and how to reach you to do so. You're expected to keep a copy of that authorization on file for a set period after the arrangement ends, not just at signup. If you're building a custom checkout or billing portal, this record-keeping needs to be designed in from the start rather than bolted on later, since it's the evidence you'd rely on if a customer later disputes a debit.
Setting Up PAD in Your Billing Process
In practice, adding PAD to a billing flow means a few concrete pieces working together: a mandate capture step that records consent clearly, a connection to a bank or processor that can submit the debits, a way to store and retrieve signed mandates, and logic for what happens when a debit is returned. This is usually built as part of a broader checkout or subscription system rather than bolted onto an existing one, which is where custom software development earns its keep, particularly if you're already managing subscriptions, invoices, or memberships in another system that needs to stay in sync.
Pre-Notification: Telling Customers Before You Debit Them
Beyond the initial mandate, customers generally need to be told in advance, in writing, before each debit if the amount or date varies from what was originally agreed. For fixed-amount, fixed-schedule billing, this notice requirement is often satisfied once, at signup, since the customer already knows what's coming. For variable amounts, usage-based billing, or irregular timing, you typically need to notify the customer before each specific debit. This is a detail that's easy to miss when a product evolves, if your pricing shifts from flat-rate to usage-based later on, your pre-notification approach needs to evolve with it.
When a PAD Payment Fails
Returned PAD payments happen for reasons similar to declined cards, non-sufficient funds, closed accounts, or disputed debits, but the notification lag means you'll often be acting on information that's a few days old. A sound process includes a defined retry policy that doesn't simply resubmit immediately and risk additional NSF fees for the customer, a clear communication step so the customer knows what happened and why, and a decision point for when to pause service rather than keep retrying indefinitely.
Cancellation Rights and Customer Recourse
Customers have the right to cancel a PAD agreement at any time, and the rule framework gives them recourse if a debit was taken without proper authorization or didn't match the terms they agreed to, including a path to get their money back through their bank. For your business, this means cancellation needs to be genuinely easy, not buried behind a support ticket queue, and your records need to clearly show what the customer agreed to if a dispute ever comes up. Treating PAD cancellation as a one-click or one-email action tends to prevent far more friction than trying to make it hard to leave.
Is PAD Right for Your Business?
PAD tends to make the most sense for predictable, ongoing charges where the relationship is expected to last a while: memberships, tuition or program fees, loan or lease payments, rent, and similar arrangements. It's less suited to impulse purchases or situations where customers expect instant confirmation, since the multi-day clearing cycle doesn't fit that experience. Many Canadian businesses end up running PAD alongside card billing rather than instead of it, offering PAD as an option for customers who prefer it or whose payment pattern suits it, while keeping cards for faster-moving transactions. Pairing PAD with automated status updates, through webhooks that notify your CRM or billing system when a debit clears or returns, keeps your team working from current information instead of stale assumptions.
Common Mistakes to Avoid
- Treating a PAD debit like an instant card charge and granting access or shipping goods before the debit has actually cleared.
- Storing mandates informally, in email threads or spreadsheets, instead of a retrievable, time-stamped record.
- Skipping pre-notification when amounts or dates change, even by a small margin.
- Retrying failed debits aggressively, which can compound NSF fees for the customer and damage the relationship.
- Making cancellation hard to find, which increases disputes and bank-level reversals rather than reducing churn.
A Practical PAD Checklist
Before adding PAD to your billing options, confirm the following:
- You have a mandate form that captures amount, frequency, and cancellation terms clearly.
- Signed mandates are stored and retrievable for as long as required after the relationship ends.
- Your process sends advance notice whenever a debit amount or date varies.
- You have a defined, documented retry policy for returned debits.
- Cancellation is a simple, clearly advertised step for customers.
- Your team or system can reconcile which debits cleared, failed, or are pending at any time.
If several of these aren't true yet, that's not a reason to avoid PAD, it's a sign the groundwork needs to be built before you turn it on for customers.
Wrap-Up
PAD isn't complicated once you understand its shape: a signed mandate, a multi-day clearing cycle, and clear rules around notice and cancellation. The businesses that get the most out of it are the ones that design for the delay and the paperwork up front rather than discovering the gaps after a customer dispute. Whether you're adding PAD to an existing store, a membership platform, or custom billing software, a properly built checkout and account flow and ongoing maintenance to keep payment logic current as rules or processors change will save far more trouble than retrofitting it later.
Put this into practice with CodeLuma
CodeLuma builds and wires up Canadian PAD flows, from mandate capture and e-signature records to failure handling and retry logic, as part of a custom checkout or billing system. We can also connect PAD to your existing invoicing, CRM, or subscription tools so failed debits trigger the right follow-up automatically.
- Custom software development - tailored systems, integrations and internal tools.
- Website and web application development - fast, accessible, search-friendly builds.
- Maintenance and support plans - updates, monitoring and ongoing improvement.
- Managed hosting - monitored, backed-up, Canadian-friendly hosting.
Start a conversation. Tell us about your project and we will reply with practical next steps, or browse all CodeLuma services. CodeLuma Development Inc. is based in Nova Scotia and works with teams across Canada and remotely.
