Interac Direct and Pay by Bank. Compare account-based digital checkout with other Interac payment journeys and their bank integration points.
Block 7 · Chapter 34 of 75
This chapter compares account-based digital checkout with the other Interac payment journeys you already know, and shows where each journey touches the bank. The running question is simple: when a customer pays online straight from their bank account — the pattern this course calls pay by bank — what actually happens, how is it different from paying by card or sending an e-Transfer, and which bank integration points have to work for the merchant, the payer, and operations to all agree on what happened?
Pay by bank, as used here, means the payer authorizes a direct account payment inside checkout through their own bank. The payer picks the account-based option on the merchant page, is handed securely to their bank, signs in the way they normally do, sees the amount and the payee, and gives explicit consent for the account to be debited. They then return to the merchant with a confirmation, and the merchant fulfils the order. Nothing in that sentence should be read as a technical specification. The exact screens, the exact message names, the exact timing of the underlying bank legs, and any commercial terms vary by implementation and are deliberately not stated here. What matters for this chapter is the shape of the journey and how that shape differs from the two journeys it is most often confused with: card authorization with later clearing and settlement, and e-Transfer addressing with notification, acceptance, and deposit.
That distinction is worth a full chapter because the three journeys look alike on a phone and behave differently behind the glass. A card checkout creates an authorization against a card account in seconds and sorts out clearing, interbank settlement, and merchant funding afterwards, with dispute rights that belong to the card world. An e-Transfer moves on addressing — an email address, a mobile number, or an Autodeposit registration — with a notify-and-accept handshake that customers experience as near instant while bank settlement legs follow their own cycles. A pay-by-bank checkout creates a direct account-payment consent inside the purchase itself: the payer, the exact amount, the exact payee, and the exact moment are bound together before anyone talks about settlement. If you can explain those three promises in plain language — what the customer authorized, when the merchant may treat the order as paid, and what happens when something goes wrong — you can do the job this chapter trains.
The chapter sits in Block 7, after the Interac ecosystem, e-Transfer, debit, and business-payment chapters. It assumes you can already describe an e-Transfer send, an Autodeposit receipt, a request-money flow, and a debit authorization at a high level. It does not repeat that detail. It adds the checkout lens: the merchant as a participant, the checkout session as a stateful object with a beginning, a middle, and an end, and the bank integration points — the places where the merchant world and the bank world exchange identity, consent, status, value, and evidence — as the joints where implementations succeed or fail.
A word on names. Interac Direct is Interac Corp.'s account-based online payment offering. Interac's current product pages say it is available exclusively through the Konek platform, at participating Canadian merchants, for eligible chequing, savings or line-of-credit accounts at participating financial institutions; the business page says Konek transactions are currently CAD-only.[1][2] This chapter uses “Interac Direct” for that product and “pay by bank” for the broader pattern. The generic pattern is bigger than one product, but this chapter must not imply that every pay-by-bank implementation uses Interac, Konek, Payments Canada's ACSS, or the future RTR. Where public product pages do not publish APIs, message names, cutoffs, clearing paths, settlement accounts or SLAs, the chapter says so rather than inventing them.
What you will be able to do after this chapter
After working through this chapter, you should be able to:
- explain pay by bank in one plain paragraph: who authorizes what, where, and with what evidence, without reaching for card or e-Transfer vocabulary;
- walk a pay-by-bank checkout end to end — merchant selection, secure handoff to the bank, authentication, amount-and-payee authorization, return, confirmation, fulfilment — and name what can stall or fail at each step;
- compare pay-by-bank checkout with card checkout and with e-Transfer on authorization, addressing, clearing and settlement, timing, finality language, and recourse, and state the comparison without inventing fees, timings, or specifications;
- name the participants in an account-based checkout — payer, merchant, the payer's bank, the merchant's bank or provider, and Interac Corp as ecosystem operator — and state what each owns and what each never owns;
- describe the bank integration points functionally — identity and consent capture, payment execution, interbank settlement legs, status reporting, and reconciliation evidence — without inventing API names, message formats, or settlement mechanics;
- explain why "authorized," "confirmed," "settled," "posted," and "available" are five different statements, and choose the honest one for each audience after a pay-by-bank checkout;
- place fraud, authentication, FINTRAC record-keeping, and RPAA supervision considerations at the correct point in the checkout flow;
- classify checkout exceptions — abandoned sessions, declines, timeouts with unknown outcome, duplicate submissions, refunds, and suspected fraud — and describe the safe recovery for each;
- explain merchant posting, settlement reporting, and three-way reconciliation for account-based checkout receipts;
- advise a merchant, at overview depth, when pay by bank fits, when a card or e-Transfer journey fits better, and what has to be true before launch;
- work through two fictional checkout stories — an online retailer sale and a tuition payment — and extract the control and reconciliation lesson from each;
- navigate to the authoritative sources for anything this chapter deliberately leaves unspecified.
For a roughly 60-minute core session, spend about 10 minutes on this introduction and Sections 1–2, 15 minutes on Sections 3–4 with the two journey diagrams, 10 minutes on Sections 5–6 with the integration and comparison material, 10 minutes on Sections 7–8 with controls and the refund path, 10 minutes on the fictional stories in Section 11, and 5 minutes on takeaways and references in Section 12.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Initiation, authentication and the checkout core
- Clearing, settlement and what the customer may be told
- Data, identifiers, consent and references
- Rules, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, refunds and recovery
- Posting, accounting, reporting and reconciliation
- Merchant and bank implementation, testing and resilience
- Practical fictional checkout stories
- Key takeaways and authoritative references
1. Business context and customer need
Start with the merchant, because the merchant is the participant this block has said least about so far. An online retailer in Winnipeg sells a winter jacket on a Tuesday evening. The customer has the jacket in the cart, the price on the screen, and three ways to pay. The retailer wants three things that are in tension: the highest possible completion rate, the lowest possible cost of acceptance, and the fewest possible "where is my money" investigations. The customer wants two things that sound simple and are operationally demanding: to pay with money they actually have, and to know immediately whether the order will ship. The payer's bank wants something else again: a consent it can defend — the right customer, the right account, the right amount, the right payee, at the right moment — captured in a channel it controls. Pay by bank exists to satisfy all three at once, and it fails whenever any one of the three is designed as an afterthought.
The customer need behind account-based checkout is best understood as a reaction to the two familiar journeys. Card checkout is universal and fast, but some customers do not want to use a credit line for a debit-shaped purchase, do not have a card they want to use online, or simply prefer to see the money leave the account they budget from. E-Transfer is familiar and trusted, but it was designed around addressing a person — send to an email or a mobile number, wait for acceptance unless the recipient uses Autodeposit — and adapting that handshake to a merchant checkout with a cart, a session timeout, and an inventory hold creates friction the merchant has to absorb. Pay by bank keeps the purchase context intact: the amount comes from the order, the payee comes from the merchant, the authorization happens before the session expires, and the confirmation returns to the same screen the customer started on. That continuity is the whole commercial argument. Everything else — cost, risk, reporting — is secondary to whether the customer completes the purchase without leaving the story of the order.
Consider the tuition payment, the chapter's second anchor. A college in Nova Scotia collects a term fee of several thousand dollars. The payer is often a parent, sometimes from another province, paying against a student number with a hard deadline and a late-fee cliff. Card payment would work technically but sits uneasily beside institutional policies and the economics of large single payments; e-Transfer works socially but strains against per-transaction habits, addressing errors, and the manual matching of a payment to a student record. An account-based checkout that carries the exact amount, the institution as payee, and the student number as remittance, authorized directly at the payer's bank, matches the shape of the obligation. The lesson generalizes: pay by bank fits obligations that are specific in amount, specific in payee, and specific in timing — the invoice-shaped payments of online life — and fits them better the more the merchant values a clean match between payment and order.
The bank's need is quieter but decisive. Every checkout payment the bank touches becomes a record it must keep, a consent it must be able to replay, and a customer interaction it must be able to explain. Account-based checkout concentrates that responsibility at a moment of high emotion — the customer is spending money right now — and the bank either captures a crisp, replayable consent or inherits a dispute it cannot reconstruct. Banks that treat the checkout handoff as a product surface, with clear authentication, clear amount-and-payee display, and clear success-and-failure states, earn the dispute the merchant cannot win alone. Banks that treat it as plumbing earn volume they cannot defend. This chapter therefore keeps returning to evidence: what was shown, what was agreed, what reference binds the agreement to the money, and where that reference lives afterwards.
The merchant's need completes the triangle. A merchant who accepts account-based checkout needs to answer four questions for every order: is this order paid, when will the money be in my account, what reference ties the money to the order, and what do I do when the customer says otherwise. The first question is about status discipline. The second is about settlement reporting, not about the customer's screen. The third is about references carried end to end. The fourth is about the refund and exception path being designed before launch, not after the first complaint. Merchants who get crisp answers to all four treat pay by bank as a growth channel. Merchants who get vague answers — "the payment went through" with no reference, no settlement expectation, and no refund story — treat it as a support cost and quietly remove the button. Section 10 is written for that merchant, and Section 9 gives finance the reconciliation design that keeps the button on the page.
Consumer-driven banking is now a federal framework under development, not evidence that Interac Direct uses open-banking data or payment-initiation APIs. Finance Canada's Budget 2025 framework describes initial read access to account, balance, transaction and product data, while “write access” such as payment initiation is a later phase under policy work; it also says the screen-scraping prohibition comes into force only once the framework is fully operational.[14] Treat that as regulatory outlook and implementation context. It does not change the current Konek checkout facts in this chapter.
The diagram above is the chapter's anchor. Five boxes, one direction, no branches. Merchant checkout, secure move to the bank, authentication, authorization, return and confirmation. Every later section is a deeper pass over one of those boxes or over the lines between them, and every comparison in the chapter is a second journey drawn beside this one to show where it diverges.
2. Participants, responsibilities and system boundaries
Five roles commonly appear, but the exact legal and processing chain is product- and contract-specific. The payer owns the economic decision and consent; the merchant owns the order and fulfilment; the payer's financial institution owns the account relationship and its authentication/payment-consent process; the merchant's acquirer or payment processor owns merchant acceptance, support, reporting and funding under its agreement; and Interac/Konek supplies the branded platform and network services described in its public materials.[2][3][4] Interac's public pages do not establish that Interac Direct uses ACSS, RTR, a particular settlement account, or a named interbank message. Do not assign those roles from the Interac brand alone.
The payer's responsibility is narrower than it looks and more important than it sounds. The payer chooses the account-based option, arrives at their own bank through the secure handoff, authenticates as the bank requires, checks the amount and the payee as displayed, selects the account where a choice exists, and gives or withholds consent. The payer also owns the consequences of inattention: consenting to the wrong amount, consenting on a device they do not control, or abandoning the session and then assuming the order was cancelled. Good implementations make the payer's job easy — one amount, one payee, one account decision, one clear confirm — and make abandonment safe by treating no-consent as no-payment, always. The payer never owns interbank settlement, never owns merchant funding timing, and never owes the merchant an explanation of bank-leg mechanics. "My bank said yes" is the most the payer should ever need to say, and the receipt should make even that unnecessary.
The merchant owns the order and everything that follows from it. The merchant presents the payment choice honestly, builds the order with the exact amount and its own identity as payee, holds inventory or capacity for the session window it advertised, accepts the returned confirmation or handles the abandoned session, fulfils against confirmed orders, and answers the customer when the story breaks. What the merchant must never do is interpret bank mechanics it cannot see: it must not treat a handoff as an authorization, must not treat an authorization notice as settled funds, and must not fulfil against a screen the customer shows at the door without checking its own order status. The merchant's system of record is its own order status driven by the integration's authoritative status, not the customer's phone. Every fulfilment-before-confirmation loss in e-commerce history involves a merchant overriding that principle under pressure.
The payer's bank owns the part of the journey the customer trusts most and understands least. It receives the handoff, establishes who is signing in with its own authentication, applies its device, behavioural, and session controls, displays the amount and payee for approval, captures the explicit debit consent, executes the account leg according to its own books and arrangements, and returns a result the merchant can rely on without seeing inside the bank. The bank also owns the record: what was displayed, what was consented, when, on which device and session, under which reference. That record is what makes the payment defensible months later when the payer says "I never agreed to that" and the merchant says "your bank said yes." Banks that capture crisp consent records resolve those disputes in minutes. Banks that capture thin ones relitigate the whole purchase.
The merchant's bank or payment provider owns the merchant's side of the money story. It onboards the merchant, settles or arranges settlement of account-based receipts to the merchant's account per its agreement, reports each receipt with the reference the merchant needs for matching, and supports the merchant's refund originations. Its boundary matters: it does not authenticate the payer, does not capture the payer's consent, and does not decide whether the payer's bank should have authorized. When merchants ask "why did this payment decline," the answer lives with the payer and the payer's bank, not with the merchant's provider — and the provider's job is to say so kindly while giving the merchant the status code and next step its integration contract defines.
For Interac Direct, the defensible public description is narrower: Konek is powered by Interac, backed by participating financial institutions, and directs merchants to their acquirer for onboarding and transaction support.[2][3][4] Interac's e-Transfer FAQ separately says Interac does not hold funds or trace e-Transfer funds; issues go to the financial institution.[5] That is useful boundary evidence, but it is not proof of the settlement mechanics of Konek. Treat scheme rules, processor contracts and bank operating procedures as the source for any message, clearing, exchange, settlement, refund, dispute or cutoff detail that is not public here.
Two boundaries deserve emphasis because implementations violate them most. First, authentication belongs to the payer's bank, always. The merchant must never see, handle, or replay bank credentials, and any design that asks the payer to type bank secrets into a merchant-shaped screen has left the pattern this chapter describes. Second, fulfilment belongs to the merchant's order status, always. The payer's bank must never promise the merchant that goods shipped, and the merchant must never promise the payer that the bank debited. Each side promises what it controls and reports what it observed; the integration binds the two with a shared reference rather than with shared assumptions.
3. Initiation, authentication and the checkout core
The checkout core is a state machine with five states, and operational discipline means naming the current state honestly at every moment. State one is order-built: the merchant has an order with an amount, a payee identity, and a session. State two is handed-off: the payer has left the merchant for the bank through the secure handoff and nothing is yet authorized. State three is authenticated: the bank knows who is signing in. State four is authorized: the authenticated payer has approved the specific amount to the specific payee. State five is returned-and-confirmed: the payer is back at the merchant and the merchant holds a confirmation it can fulfil against — or a definitive failure it can communicate. Every exception in Section 8 is one of these states failing to advance, and every control in Section 7 is a guard on one of these transitions. Teams that use these five names in incident tickets resolve checkout problems in half the time of teams that say "the payment failed" and start guessing.
Initiation looks trivial and repays attention. The payer selects the account-based option, and the merchant builds the handoff with the minimum the bank needs to present a meaningful consent: the amount, the payee, a merchant order reference, and a return path. The amount must be exact and final for the consent being sought; a consent for "about this much" is not consent. The payee must be the name the payer will recognize on their statement, not an internal trading name or a processor's name. The order reference must survive the round trip so the returning payer lands on the right order. Implementations that get initiation right feel boring: the customer clicks once, arrives at a familiar bank screen showing a familiar merchant name and the exact total, and decides. Implementations that get it wrong feel suspicious: the amount differs from the cart, the payee is unrecognizable, or the return lands on a generic page with no order context. Suspicion abandons carts faster than price does.
The handoff between merchant and bank is the most security-sensitive line in the chapter, and it is described here functionally on purpose. Its job is to move the payer, with the order context, from a context the bank does not control to a context the bank does — without letting anyone in the middle read, alter, or replay the move. What that requires in practice — integrity of the order data in transit, binding of the handoff to the session that created it, expiry of stale handoffs, and a return that can only complete the order that started it — is implementation detail this chapter does not specify. The operational tests, though, are generic and every merchant and bank should apply them: tampering with the amount in transit must fail closed, replaying yesterday's handoff must fail closed, returning to a different order must fail closed, and an expired session must tell the payer plainly rather than authorizing against a cart that no longer exists. If those four tests pass, the handoff is doing its job regardless of the technology underneath.
Authentication at the bank follows the bank's own rules — the same sign-in, device recognition, and step-up the payer meets in any sensitive bank session — and the chapter states that deliberately as a boundary: the merchant neither sees nor influences how the bank authenticates. What the merchant should understand is the consequence. A payer who sails through on a recognized device experiences checkout as one smooth motion. A payer challenged with step-up on a new device experiences checkout as a pause that protects them, and the merchant's session window and messaging must tolerate that pause rather than timing out the order mid-challenge. Operations teams should know the shape of their own authentication funnel — how often step-up triggers on checkout handoffs, how often it succeeds, how often the payer abandons instead — because that funnel, more than any marketing copy, determines the channel's completion rate. And fraud teams should treat the authentication event as the evidentiary anchor: the device, the session, the time, and the result, bound to the consent that follows.
Authorization is the moment the chapter exists to describe, and it has exactly three ingredients: a specific amount, a specific payee, and an explicit yes. Display the amount as a number the payer can verify against the cart, display the payee as the name the payer will see on their statement, offer the account choice where one exists, and capture an affirmative action that cannot be mistaken for navigation. Everything about this screen should slow the payer down by half a second and speed the dispute team up by half a day. Pre-ticked boxes, bundled consents, vague mandates, and "authorize future payments" language smuggled into a single purchase all convert a crisp purchase consent into a blurry relationship the bank cannot defend and the merchant cannot explain. The consent being captured here authorizes this payment, full stop; any ongoing authority is a separate agreement with separate disclosure, and Section 7 treats it as such.
The return and confirmation close the loop, and status discipline here separates professionals from amateurs. Three outcomes exist and only three: confirmed, definitively failed, or unknown. Confirmed means the merchant holds a confirmation bound to its order reference and may fulfil. Definitively failed means the bank declined, the payer withheld consent, or the session expired before authorization, and the merchant may invite another attempt without fear of a duplicate. Unknown means the return never arrived, arrived corrupted, or describes a state the merchant cannot interpret — and unknown must never be treated as either success or failure. Section 8 gives unknown its full procedure: check authoritative status before acting, never fulfil on assumption, never retry blindly. The five-state machine from the top of this section exists so that "unknown" is a first-class state with an owner and a runbook, not a shrug in a chat log.
Through all five states, two invariants hold. First, the payer's credentials never leave the bank's context; the merchant authenticates the shopper as its customer, the bank authenticates the payer as its account holder, and neither borrows the other's proof. Second, the order reference and the payment reference travel together from initiation to reporting; Section 5 names them, Section 9 reconciles them, and Section 11 shows what breaks when they part. A checkout implementation that preserves both invariants can survive any single component failure with its story intact. One that breaks either will eventually fulfil the wrong order or debit the wrong understanding — and discover the break from the customer, which is the most expensive monitoring available.
4. Clearing, settlement and what the customer may be told
Behind the confirmation screen, the public record is intentionally limited. Interac describes Konek authentication, payment consent, merchant acceptance, refunds and support boundaries, but does not publish a Direct/Konek API, ISO message set, file format, cutoff, clearing/exchange path, settlement account, settlement cycle or merchant-funding SLA.[1][2][3][4] The merchant may therefore promise only the status and funding terms in its acquirer/processor agreement. Do not state that a Direct transaction clears through ACSS or settles through RTR unless the applicable contract or rule says so. Payments Canada's ACSS is a separate retail-batch system whose direct clearers settle prior-day net balances in the morning of each business day,[6] while RTR is a separate modernization system scheduled to launch in Q4 2026 and still undergoing testing.[7][8]
Five words carry five meanings, and the chapter insists on all five. Authorized means the payer's financial institution approved the payment-consent event. Confirmed means the merchant and its provider accepted the transaction and returned an order confirmation; Konek tells consumers to contact the merchant if the store did not display one.[4] Settled means value moved finally between the relevant settlement parties. Posted means an account was debited or credited. Available means the beneficiary may use the funds. These events need not occur in a fixed order across implementations, and the public Konek pages do not guarantee that they occur within a stated time. Use the provider agreement and account records for posted, settled, funded and available; never infer them from a checkout screen.
The comparison with the other two journeys makes the discipline concrete. In card checkout, authorization, clearing, settlement and merchant funding are governed by the applicable card network and acquirer/issuer arrangements; the Payment Card Networks Act defines the network as the system that accepts, transmits or processes card transactions and transfers information and funds among issuers, acquirers, merchants and users.[16] In e-Transfer, the official FAQ describes a transfer as almost instant but potentially taking up to 30 minutes depending on the bank or credit union; Autodeposit removes the security-question step, and Interac directs transaction issues to the financial institution.[5] Pay by bank needs the same language discipline: promise only a documented confirmation-to-fulfil and funding/reporting story, and never let checkout copy imply that those are one event.
The comparison diagram above belongs on the wall of every team that writes checkout copy. Three columns, same rows: how the journey is authorized, how it is addressed, how money follows, and what recourse looks like. Read it across to feel why customers confuse the journeys, and read it down to feel why operations must not. The card column authorizes against a card account and sorts money out later with chargeback rights attached. The e-Transfer column addresses a person, handshakes acceptance, and confirms deposit while bank legs follow. The pay-by-bank column binds consent to the order itself and returns confirmation to the session that created it. Three authorizations, three addressings, three money stories — one checkout screen the customer must navigate without a manual.
For the merchant, the practical translation has three sentences. First, fulfil against confirmation, not against hope: a confirmation bound to your order reference is a shipping instruction, and anything else is a reason to check status. Second, plan cash against your funding agreement, not against the customer's screen: the seconds the customer sees are your conversion story, and the funding rhythm in your provider agreement is your treasury story. Third, speak to customers in states, not mechanics: "your payment is confirmed and your order is being prepared" is honest, "your payment has settled between banks" is a claim you cannot verify from the checkout screen and should never make. Train support to use the first sentence, train finance to use the second, and put the third on a card by every phone.
The payer's account story and the merchant's report should be tested against the provider's documented descriptors, posting rules and references; Interac's public Konek material does not guarantee a particular statement descriptor or posting time.[1][4] The merchant's account story, via its acquirer/provider, should match the provider report line for line. Both sides should preserve the references Section 5 defines, because the settlement legs may be invisible to customers but the references must not be.
One misunderstanding deserves a paragraph of its own, because it causes real losses. A merchant who receives a confirmation and then watches their bank balance for the exact amount within the hour will sometimes conclude the confirmation was false when the balance has not moved. It was not false; the merchant confused confirmation with interbank settlement, the way a card-accepting merchant in their first week confuses an approval slip with the funding batch. The cure is the same one the card industry applied decades ago: teach confirmation-to-fulfil and funding-to-cash as two tracks from day one, show both tracks in the merchant dashboard, and make the settlement report — Section 9's subject — as prominent as the order screen. Merchants who see both tracks trust the channel. Merchants shown only one track file tickets about the other.
5. Data, identifiers, consent and references
Payments fail more often from bad data than from bad rails, and checkout concentrates every data risk into a single session. The payer, the order, the consent, and the money must all carry references that survive the round trip from merchant to bank and back, and the consent record must be replayable months later by people who were not in the room. This section names the minimum data each participant needs, the references that must travel end to end, and the consent record that makes the payment defensible — all functionally, without inventing a single message name or field specification.
Start with what the merchant must build before the handoff. The order needs an identifier the merchant owns and never reuses, an exact amount with currency, a payee display name that matches what the payer will see on their statement, and the remittance the merchant needs for matching — an order number, a student number, an invoice reference, whatever closes the loop in the merchant's own system. The session needs a lifetime that tolerates bank authentication including step-up, and a return binding that delivers the payer to the order that started the journey. None of this is scheme detail; it is order hygiene. Merchants who reuse order numbers, who amend the amount mid-session, or who accept returns to a generic landing page donate their reconciliation team a permanent investigation queue, and no bank integration can save them.
The consent the bank captures needs three data qualities that auditors check first. Specificity: the amount and the payee as displayed, the account selected where a choice exists, and the timestamp of the affirmative action. Integrity: evidence that what was displayed is what was consented — no substitution between display and capture, no pre-confirmation, no bundled authorities smuggled into the purchase. Retrievability: the ability to replay, months later, what the payer saw and did, under which session and device, tied to which order reference. A consent record with all three ends disputes. A payer who says "I never agreed" is shown the amount, the payee, the time, and the session, and the conversation ends. A record missing any one of the three turns every dispute into archaeology.
References are what let humans and systems agree they are discussing the same payment, and four must survive the whole journey. The merchant order reference, owned by the merchant, binds the purchase across handoff, return, fulfilment, refund, and support contact. The payment or consent reference, owned by the bank side of the integration, binds the authorization event itself. The end-to-end reference shared between merchant and bank binds the two together so a support agent with either one can find the other. And the remittance reference — student number, invoice number, policy number — binds the payment to the obligation it discharges in the merchant's books. Drop any one and a different team suffers: lose the order reference and support cannot find the order; lose the consent reference and the bank cannot defend the debit; lose the shared reference and the two sides argue about different payments; lose the remittance and finance matches by amount and date, which works until the day two customers pay the same amount.
Addressing is where the three journeys diverge most visibly, but the product boundary matters. Card checkout addresses a card account through the applicable network and acquirer. E-Transfer addresses a recipient through an email address, mobile number or Autodeposit registration, with notification and deposit handled through participating financial institutions.[5][16] Konek public material describes selecting the participating financial institution and an eligible account, but does not publish a generic “purchase address” field or bank-to-bank message model.[1][2][4] Therefore present “purchase-bound consent” as this chapter's functional control model, not as a published Interac Direct protocol.
Privacy follows the same boundary as authentication. The merchant learns what it needs to fulfil and reconcile — that this order is confirmed, under which references, with which remittance — and does not learn the payer's account number, balances, or bank credentials. The bank learns what it needs to authorize — the amount, the payee, the order context — and does not hand the merchant the payer's banking profile. Data minimization here is not a slogan; it is the reason the handoff exists as a handoff rather than as a data dump. Each side holds its own evidence, shares the binding references, and can prove its half of the story without exposing the other half.
Two failure patterns close the section because they recur in every implementation review. The first is the amended cart: the customer edits the order mid-session, the consent authorizes the old amount, and fulfilment ships the new contents. The rule is absolute — any material change after handoff starts a new consent, never a silent carryover — and the session design must enforce it rather than documenting around it. The second is the truncated reference: a student number, invoice suffix, or apartment identifier that fits on the checkout screen but not in some downstream report, silently dropped, leaving finance to match by detective work. The rule is equally absolute — validate reference lengths and character sets at initiation, carry them end to end, and surface them in the settlement report exactly as captured. Data discipline at initiation is cheap. Data archaeology after settlement is not.
6. Rules, service levels and customer impact
Customers experience rules as promises: will my order ship tonight, when will the merchant see the money, what reference appears, what happens if it goes wrong. Banks and providers experience rules as agreements: who promises what to whom, on what timetable, with what evidence, under whose brand. This section connects the two without inventing a single rulebook clause, cutoff time, or fee. Exact times, exact windows, and exact commercial terms vary by bank, by provider, by agreement, and by day, and they belong in the merchant's contract and the bank's published schedules — not in a course chapter. What belongs here is the shape of the promises and how to communicate them honestly.
The payer-facing service level is the simplest: a checkout that usually completes in the same session, with clear states at every point. The payer should always know which of four situations they are in — choosing, at the bank, confirmed back at the merchant, or failed with a next step — and should never be left on a spinner with no owner. Session lifetimes should tolerate bank step-up authentication; failure messages should distinguish "you declined or abandoned" from "your bank declined" from "something timed out, check before retrying"; and the receipt should carry the references the payer needs if they ever call either side. None of this requires scheme knowledge. It requires treating the payer's attention as the scarcest resource in the flow and spending it only on decisions only the payer can make.
The merchant-facing service level has two tracks that must never be blended in conversation. Track one is confirmation-to-fulfil: how quickly and reliably a completed consent becomes a fulfilment-ready confirmation bound to the order. Track two is receipt-to-cash: how the merchant's provider reports and funds account-based receipts, on what rhythm, with what references, and with what handling of refunds and adjustments. Track one drives conversion and support load. Track two drives treasury and reconciliation staffing. A provider that quotes track-one speed when the merchant asked about track-two funding has not answered the question, and a merchant that plans staffing from checkout anecdotes instead of the funding schedule will be surprised on its first busy weekend. Put both tracks in the launch checklist in Section 10, and make the dashboard show both.
Availability language needs the same care the ecosystem chapter demands for every rail. "Confirmed" means the merchant may fulfil — it does not mean interbank value has moved, and merchant copy must never imply otherwise. "Funded" or "paid out" means the merchant's provider has credited the merchant per their agreement — it does not describe the payer's account, which is the payer's bank's story to tell. "Refunded" means a return leg has been originated and reported — it does not mean the payer can spend the money yet, and support must give the payer a next-check time rather than a shrug. Train every customer-facing colleague on those three sentences and half the checkout complaint volume disappears, because most of it was never about money movement at all. It was about words.
Edge calendars deserve a short paragraph because checkout never sleeps and back offices do. Do not promise 24/7 confirmation, funding or support from a generic pay-by-bank label. Konek's public pages specify participating Canadian merchants and CAD payments, and direct operational questions to the merchant, financial institution or acquirer; they do not publish a Konek availability SLA or funding calendar.[2][3][4] Publish the actual provider schedule, holiday treatment, refund timing and support coverage in the merchant agreement and checkout copy.
Finally, a note on cost and recourse. Fees and rates are agreement-specific. Do not claim that Interac Direct/Konek has “no chargebacks” or no disputes: Konek says disputes are handled through existing acquirer and issuer processes consistent with the underlying payment network, with liability shift only for eligible fraud or account-takeover cases.[4] The durable comparison is structural: cards use a payment-card network; e-Transfer uses an identifier, notification and deposit flow; Direct uses Konek and a participating financial institution. State the actual dispute, refund and liability terms from the merchant agreement and applicable scheme, not from a generic pay-by-bank label.[15][16]
7. Fraud, compliance and operational controls
Controls fail when they are complete but misplaced, and checkout concentrates every misplacement into a session the customer is watching. A device check that runs after consent, a sanctions screen that runs after the bank leg, a velocity limit nobody owns across channels, an ongoing authority nobody disclosed — each is a control that exists and still loses. This section places each control family at the point in the checkout flow where it can still change the outcome, without duplicating the rail-level control detail that lives in Block 13.
Authentication and session integrity come first because everything downstream inherits their strength. The bank's sign-in, device recognition, and step-up challenge stand between an attacker and the consent screen, and the handoff binding from Section 3 stands between an attacker and the order context. Fraud teams should monitor both together: sign-in anomalies on checkout handoffs, handoffs tampered or replayed in transit, sessions that authenticate cleanly and then consent to payees the customer has never paid, and devices that appear for the first time at the exact moment of a large tuition payment. The response to a suspicious authentication is never to "let it through and watch the settlement" — there is no settlement-stage control that repairs a consent that should never have been captured. Challenge, hold, or decline before consent, and log the decision with the session.
Transaction risk scoring sits between authentication and authorization, and its checkout-specific signals deserve enumeration. New payee with no history plus a first-time device is the classic takeover shape. Amount just below a step-up or review threshold, tried twice, is the classic probing shape. A tuition-sized payment to an institution the payer has never paid, initiated late at night from a new location, may be entirely legitimate — a parent paying from a hotel — and the control design must allow it with step-up rather than blocking the family's term. Velocity across the payer's other channels matters too: a customer who just added a new bill payee, changed their contact details, and now authorizes a large checkout payment is telling a story no single channel sees alone. The bank that scores the checkout event against the customer's whole recent history catches what the bank that scores it in isolation misses.
Ongoing authorities need a paragraph because checkout is where they are most easily blurred. The consent captured for a one-time purchase authorizes that purchase, but Konek publicly supports recurring and pre-authorized payment scenarios as well as reversals and refunds.[2][4] Do not automatically label every recurring Konek transaction a Payments Canada PAD or assume that a one-time consent creates a stored mandate. Determine the legal/instrument classification, disclosure, revocation, evidence and dispute terms from the Konek/acquirer agreement and the applicable rule set. Konek tells customers to contact the merchant to cancel a recurring payment.[4]
Record-keeping and FINTRAC considerations are entity- and activity-specific, not a blanket rule that every Interac Direct checkout is a reportable EFT. FINTRAC's record-keeping guidance says the EFT definition excludes direct deposits and pre-authorized debits, and its $1,000 EFT record rules are framed around specified international EFT initiation, sending and final receipt activities.[13] Confirm the classification and obligations with the relevant reporting entity and current FINTRAC guidance. Separately, an RPAA-subject PSP must keep intelligible records sufficient to demonstrate compliance and protect them from loss, falsification, inaccuracy and unauthorized access under the Act and Regulations.[11][12] The architectural lesson remains: preserve consent, status, identity and references without truncation, and feed only the obligations that actually apply.
Supervision under the Retail Payment Activities Act adds a provider boundary. The Bank of Canada supervises in-scope PSPs for registration, operational risk, incident response, safeguarding and mandatory reporting; it does not provide individual dispute resolution or broader consumer redress.[10] The RPAA excludes banks and certain other entities, while registered PSPs must meet the Act and Regulations; as of September 8, 2025, PSPs that apply after that date must be registered before performing retail payment activities.[10][11] A merchant must map which entity performs each payment function, who authenticates, who holds records or funds, who screens, who communicates status and who handles complaints. Do not infer a Konek entity's regulatory classification from the Interac or Konek brand.
Operational controls complete the plane: entitlement and dual control over merchant configuration and refund origination, amount and velocity limits on checkout and refunds, session-expiry enforcement, amendment discipline, evidence preservation, and segregation between staff who configure the integration and staff who move money through it. These are recommended implementation controls, not a published Interac Direct sequence. The RPAA/RPAR framework separately requires in-scope PSPs to manage operational risk, incident response, records and safeguarding.[10][11][12] Manual overrides — a forced confirmation, verbal fulfilment instruction or after-hours refund through an alternate path — must be controlled, dual-approved and time-bound.
8. Exceptions, refunds and recovery
Every checkout breaks differently, but every break is managed the same way: detect fast, classify correctly, contain within the rights that actually exist, recover as a new linked event, and reconcile with evidence. Teams that classify first recover cheaply. Teams that act first — re-charging, manually fulfilling, editing a settled entry — create duplicate debits, duplicate shipments, and audit breaks that dwarf the original error. This section teaches the classification and the recovery discipline; Block 14 teaches each mechanism at rail depth.
Start with the taxonomy, because checkout conversations drown in the word “failed.” An abandoned session means no consent was captured; a decline means the provider or bank refused the attempt; and a timeout-with-unknown-outcome means the merchant cannot yet establish whether the payment was accepted. A duplicate submission means two attempts require status comparison before fulfilment. A refund or reversal is a separately reported event linked to the original; Konek says refunds are applied to the same payment method used at checkout, but the merchant manages the policy and the provider defines the processing mechanics.[3][4] Suspected fraud means the order, refund and support paths are held while the applicable bank/acquirer process investigates. Exact status codes, retry windows and return rights belong in the provider contract.
The unknown outcome deserves its full procedure because it is where duplicates are born. When the return never arrives, the merchant must not fulfil and must not invite an immediate blind retry. The runbook is short: hold fulfilment, query authoritative status using the order and handoff references, and branch on the answer. If the authoritative answer is confirmed, fulfil the original and suppress any retry. If it is definitively not authorized, release the hold and invite one clean new attempt. If it is still unknown after the defined status window, keep holding, tell the customer plainly what is happening and when to check back, and escalate to the integration owner rather than letting support improvise. The payer-side mirror matters too: tell the payer not to "just pay again" until the first attempt's status is known, because two attempts the system cannot distinguish become two debits the bank must unwind. Every duplicate-debit complaint in account-based checkout traces to someone retrying through an unknown state.
Refunds follow the diagram above: request, eligibility validation, a linked refund or reversal through the provider, notification to both sides, and reconciliation with evidence. Konek says the merchant determines and manages its refund policy and that an approved refund is applied to the same payment method used at checkout.[3][4] Do not describe every refund as a new interbank payment or promise a value date unless the provider documents that mechanic. Validate the original status, refund amount, duplicate-refund risk, staff/system authority and original reference; report the refund as a linked event rather than editing the original transaction.
Containment differs by stage, and the stage determines who acts. Before consent, containment is free: expire the session, invalidate the handoff, invite a fresh attempt. After consent but before fulfilment, containment means holding fulfilment and resolving status before anything ships. After fulfilment, containment means the refund path with its validation, not a backdated cancellation — shipped goods are recovered through returns handling, not through payment editing. After a fraud signal at any stage, containment means freezing the fulfilment and refund paths for the affected order until the trust decision lands, because refunding an attacker closes the loop the attacker designed. The hub principle from the ecosystem view applies with checkout wording: fail visibly and early, with a named state, an owner, and a next-check time.
Communication during exceptions is a control, not a courtesy. The merchant tells the customer the order state and the next step in merchant vocabulary — confirmed, held while we check with your bank, declined with an invitation to try another way, refunded with a next-check time. The bank tells its customer the account story in bank vocabulary — authorized or not, debited or not, with references. Neither side narrates the other's internals, and neither side promises what the other owns. The shared reference from Section 5 is what lets the two conversations meet when the customer calls both sides: either agent, given either reference, finds the same payment. Support teams measured on "references captured per contact" outperform teams measured on "contacts closed per hour," because the first metric builds the evidence the second metric spends.
9. Posting, accounting, reporting and reconciliation
Money stories end in ledgers, and checkout receipts are no exception. The payer's financial institution posts according to its own books and arrangements; the merchant's acquirer/provider reports and funds receipts under its agreement. Interac's public pages do not guarantee a statement descriptor, posting time or settlement-report schema, so those items must be tested and documented before launch.[1][3][4] Finance matches orders, provider reports and merchant bank credits through stable references; it does not infer settlement from a customer screenshot.
Posting honesty on the payer side has three tests any operations reviewer can apply. Recognition: does the statement line name the merchant the payer saw at consent, or a processor name the payer has never heard of. Completeness: does one authorization produce exactly one debit, with duplicates from unknown-state retries detected and contained rather than posted twice. Traceability: can the payer, the bank agent, and the merchant support agent all reach the same payment from the reference on the statement. Banks that pass all three get short dispute calls. Banks that fail recognition get "what is this charge" calls. Banks that fail completeness get duplicate-debit complaints. Banks that fail traceability get three-way calls where nobody can find the payment and everybody bills the time.
Merchant reporting needs the same three tests from the other side. Completeness: every confirmed order appears in the settlement report, every report line ties to exactly one order, and no confirmed order waits silently outside the report. Matchability: each line carries the merchant order reference, the shared payment reference, the remittance where one exists, the amount, and the status the line represents — receipt, refund, or adjustment — in fields finance can join without manual retyping. Cadence honesty: the report arrives on the rhythm the agreement promises, refunds appear as linked lines rather than disappearing the original, and adjustments carry reasons rather than codes nobody documented. Finance teams that receive that report close the day. Finance teams that receive amount-and-date soup staff a reconciliation desk.
The integration diagram above shows where reporting sits: downstream of execution and settlement legs, fed by the same references that drove the checkout, consumed by merchant finance and bank operations alike. Read it bottom-up for ownership — checkout owns the order, the bank connection owns consent and references, execution and settlement legs own value movement, reporting owns evidence — and read it top-down for flow. The generic labels are deliberate. No API name, no message format, and no settlement mechanic appears, because none is needed to design reconciliation that works: shared references in, matched lines out, exceptions queued with owners.
Three-way reconciliation is the daily proof, and it has exactly three legs. Leg one is orders: the merchant's confirmed-order list for the day, with amounts and references. Leg two is money: the provider report and the merchant bank credits, with amounts and references. Leg three is evidence: the consent and status records for each order, with the shared references that bind legs one and two. The close matches all three; the exceptions queue carries the rest with named owners — unreported confirmations to the integration owner, unmatched credits to finance with provider support, missing evidence to the bank side. Breaks age visibly: anything unmatched past the agreement's window escalates rather than lingering, because a three-day-old break is a question and a three-week-old break is a write-off discussion. The reconciler's motto fits on a card: no reference, no match, no assumption — queue it, own it, age it.
Two patterns deserve naming because they recur in implementations, but neither is a published Konek timing rule. Receipts may confirm throughout the day while funding or reporting is batched under the provider agreement; refunds may be originated before they appear in a later report. The cure is to show confirmation, funding and refund-reporting tracks separately, carry the original reference, and reconcile to the actual provider schedule. Do not turn these possible patterns into a universal cutoff, value date or “next cycle” promise.
10. Merchant and bank implementation, testing and resilience
Launch checklists exist because checkout fails at joints, and joints are owned by different teams. The merchant owns order hygiene. The payer's financial institution owns its authentication and consent process. Konek/Interac supplies the platform controls described publicly. The acquirer or processor owns merchant onboarding, support, reporting and funding under its agreement; Konek says the acquirer is the first contact for merchant help and escalations.[3][4] The launch review must walk one order, one timeout, one dispute and one refund through those ownerships and record the actual references, statuses, cutoffs, report fields and funding terms.
Testing should rehearse the failures, not just the sunshine path. Confirm a clean purchase end to end, then abandon a session mid-handoff and confirm nothing authorizes and the order stays open. Decline an authorization and confirm the merchant invites one clean retry without a duplicate. Break the return so the outcome is unknown, run the status-query runbook from Section 8, and confirm nobody fulfils and nobody double-charges. Originate a full and a partial refund and confirm both report as linked lines the reconciler matches without detective work. Tamper the amount in transit and replay a stale handoff in a test harness and confirm both fail closed. Each test names its expected state from the five-state machine in Section 3, and each result is kept as launch evidence rather than hallway memory.
Resilience is visible-state design plus staffing honesty. Do not assume that a checkout product is 24/7 merely because the payment concept is digital; document the actual Konek, acquirer, bank and support availability. Monitor handoff arrival, authentication, consent completion, return, confirmation binding, refund linkage and unknown-outcome rates. Keep a runbook for status queries, provider outage, duplicate attempts and customer complaints, and retain evidence under the applicable PSP and financial-institution requirements.[4][10][11][12]
11. Practical fictional checkout stories
Example (fictional) — an online retailer checkout. A customer in Winnipeg orders a winter jacket on a Tuesday evening, chooses the account-based option, arrives at her own bank, signs in on a recognized device, sees the retailer's name and the exact total, approves the debit from her chequing account, and returns to a confirmation page showing her order number. The merchant fulfils against that confirmation the same evening. The funding for the order arrives per the merchant's provider agreement and appears in the settlement report with the order number and the shared payment reference, which finance matches in the morning close. The control lesson is status discipline: fulfilment followed the merchant's authoritative confirmation, treasury followed the funding schedule, and neither side borrowed the other's promise. The reconciliation lesson is reference carriage: because the order number travelled the round trip intact, the morning match took seconds.
Example (fictional) — a tuition payment with a near miss. A parent in Halifax pays a Nova Scotia college term fee against a student number the morning of the deadline. He authorizes at his bank on a new tablet, completes step-up, and approves the exact amount — but his train enters a tunnel before the return loads, so the merchant sees an unknown outcome. Support holds fulfilment-enrolment confirmation, queries authoritative status with the order and handoff references, finds the payment confirmed, binds the confirmation to the order, and tells the parent his receipt reference and next step instead of asking him to pay again. The refund path stays holstered because no duplicate was created. The control lesson is the unknown-state runbook: hold, query, then act — never retry blind. The reconciliation lesson is the remittance: because the student number survived end to end, the college posts the payment to the right record before the late-fee cliff, and the evening report closes without a detective case.
The decision map above turns both stories into advice. Account-based checkout fits the invoice-shaped obligation — known payee, exact amount, session context — where the payer prefers a direct debit and the merchant values a clean order match. It fits less where credit is the point, where person-to-person addressing is the need, or where the merchant cannot staff the refund and reconciliation disciplines this chapter describes. Before launch, the merchant confirms the refund path, the reporting match, and the support story for the bank handoff; after launch, it watches completion, unknown-outcome, and exception rates weekly. The map is intentionally modest: it recommends a journey, not a product, and it sends the merchant to its provider agreement and its bank for every number that matters.
12. Key takeaways and authoritative references
Pay by bank can bind payment consent to an online purchase, but the exact product promise must be named. Interac Direct is currently presented through Konek for eligible accounts at participating Canadian merchants, while Konek's public pages disclose CAD scope, bank authentication/payment consent, merchant/acquirer support, recurring/pre-authorized scenarios, reversals/refunds and dispute handling.[1][2][3][4] Cards use payment-card networks; e-Transfer uses recipient identifiers, notification and deposit; the applicable contracts and rules determine recourse, timing and funding. Do not substitute an abstract pay-by-bank narrative for current product documentation.
Integration points are functional joints, not specifications: the merchant builds an exact order and bound session; the financial institution authenticates and captures payment consent; Konek/acquirer status and reporting bind the merchant event; and any clearing, settlement, posting, refund, dispute, AML or safeguarding treatment follows the applicable provider, scheme and regulatory documents. Authorized, confirmed, settled, posted and available stay distinct. Unknown stays a first-class state with a hold-and-query runbook. RTR is not silently treated as the current Direct rail: Payments Canada says RTR is scheduled for Q4 2026 launch with sequenced onboarding and ongoing testing.[7][8] Consumer-driven banking is a separate federal framework whose initial scope is data sharing; payment initiation/write access is described as later-phase work.[14]
Authoritative references (official URLs only; product pages and rules checked 2026-10-05):
- [1] Interac Corp., “Interac Direct” — current consumer product scope, Konek exclusivity, eligible accounts, authentication and tokenization: https://www.interac.ca/en/payments/personal/interac-direct/
- [2] Interac Corp., “Introducing Interac Direct for your business” — supported transaction types, CAD/Canada scope and acquirer participation: https://www.interac.ca/en/payments/business/interac-direct-for-business/
- [3] Konek, “For Merchants” — merchant onboarding, acquirer support, refund policy and platform boundaries: https://konek.ca/en/merchants/
- [4] Konek, “FAQs” — confirmation, refunds, recurring cancellation, limits, disputes, support, CAD scope and payment scenarios: https://konek.ca/en/support/
- [5] Interac Corp., “Interac e-Transfer FAQ” — timing, Autodeposit, bank responsibility and notifications: https://www.interac.ca/en/resources/personal-resources/personal-faq/interac-e-transfer/
- [6] Payments Canada, “Retail batch payment system” — ACSS/USBE, direct clearers and morning settlement of prior-day net balances: https://www.payments.ca/systems-services/payment-systems/retail-batch-payment-system
- [7] Payments Canada, “Real-Time Rail payment system” — separate real-time exchange/clearing/settlement system and Q4 2026 launch: https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- [8] Payments Canada, “Testing and launch” — testing phases, sequenced onboarding and Q4 2026 launch timeline: https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
- [9] Payments Canada, “Payment service providers and the Real-Time Rail” — eligibility, settlement account/agent and ISO 20022 preparation: https://www.payments.ca/connect/membership/payment-service-provider-participation
- [10] Bank of Canada, “Retail payments” — RPAA supervision, PSP registration, operational risk, incident response, safeguarding and limits of consumer redress: https://www.bankofcanada.ca/regulatory-oversight/retail-payments/
- [11] Justice Laws, “Retail Payment Activities Act” — definitions, scope, exclusions, PSP functions and statutory duties (current to 2026-09-21): https://laws-lois.justice.gc.ca/eng/acts/R-7.36/page-1.html
- [12] Justice Laws, “Retail Payment Activities Regulations” — risk-management framework, incident response, records and retention: https://laws-lois.justice.gc.ca/eng/regulations/SOR-2023-229/FullText.html
- [13] FINTRAC, “Record keeping requirements for financial entities” — EFT definition/exclusions and specified EFT record requirements: https://www.fintrac-canafe.gc.ca/guidance-directives/recordkeeping-document/record/fin-eng
- [14] Department of Finance Canada, “Budget 2025: Canada’s Consumer-Driven Banking Framework” — initial data-sharing scope, consent and later write-access/payment-initiation work: https://www.canada.ca/en/department-finance/programs/financial-sector-policy/open-banking-implementation/budget-2025-canadas-framework-for-consumer-driven-banking.html
- [15] Financial Consumer Agency of Canada, “Unauthorized credit and debit transactions: know your rights and responsibilities” — card protections and investigation/complaint boundaries: https://www.canada.ca/en/financial-consumer-agency/services/rights-responsibilities/protection-unauthorized-transactions.html
- [16] Justice Laws, “Payment Card Networks Act” — card-network, issuer and acquirer definitions and scope (current to 2026-09-21): https://laws-lois.justice.gc.ca/eng/acts/P-4.3/FullText.html
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.