Interac, decoded: what platforms actually need to ask about

Canadian buyers keep asking for Interac, and most vertical platforms answer with a vague yes. The demo works, a payment lands, and everyone moves on. Then the questions get specific. Which Interac? Who holds the funds before they reach the merchant? What happens when a customer says they never authorized it? Teams that sold Interac as a feature discover they bought a different product than the one they described, with different economics and a different risk profile than the card flow sitting next to it.

The argument here is simple. Interac should be evaluated as a separate payment product with its own P&L, not as a checkbox appended to your card stack. Platforms that treat it that way capture real margin. Platforms that treat it as a compatibility item hand the economics to whoever integrated it for them.

What Interac is, and how the money moves

If most of your selling has been in the US, Interac can look like a regional card brand. It is closer to the plumbing of everyday Canadian banking. RBC, CIBC, Scotiabank, TD and Desjardins set it up in 1984 as a nonprofit association so their customers could use each other's bank machines. In 2018 the association merged with Acxsys, the company that ran e-Transfer, and became Interac Corp., a for-profit business. Today the name covers two products Canadians use constantly.

Interac Debit is the first. A customer pays with their bank card and the money comes straight out of their bank account, with no credit line in between. At a terminal that means chip and PIN, or a tap through Interac Flash up to whatever limit their bank sets. The same card taps from a phone through Apple Pay or Google Pay, and it shows up online through those wallets more every year. Canadians made about 7 billion Interac Debit transactions in 2025, and 1.8 billion of them came from a phone.

The pricing is what should get a platform's attention. Interac Debit fees are charged per transaction, a few cents each, instead of as a percentage of the sale. A $40 purchase and a $4,000 purchase cost the merchant roughly the same.

Interac e-Transfer is the second, and it has no card in it at all. It launched in 2003. Someone sends money from their online banking to another person's email address or mobile number, and the recipient either answers a security question or, if they have registered for Autodeposit, sees the funds land in their account automatically, usually within minutes. If nobody accepts the transfer it expires and the money goes back. Businesses run it in reverse with Request Money, sending a customer a payment request they approve inside their own bank. That is where business adoption is moving fastest. Interac counted 1.6 billion e-Transfers in 2025, and Request Money for business passed 160 million transactions, up 81 percent on the year before.

So when a vendor says "we support Interac," they could mean a tap at a counter, a wallet payment inside your app, or a bank-to-bank transfer that happens entirely outside your checkout. Those three have different flows, different pricing and different ways of going wrong.

Interac is a family of rails, not one integration

The two products look alike on a feature list and behave nothing alike inside your software. Interac Debit is a card-present and in-app flow that behaves, operationally, somewhat like the card rails your platform already knows. It runs through terminals, through mobile wallets, through network tokens, and it settles in a rhythm your finance team will recognize. Interac e-Transfer is account-to-account messaging between financial institutions. Request Money, Autodeposit, bulk sends, and account validation all sit in that second world, and none of them behave like a card authorization.

The practical consequence shows up in your product, not your ledger. A card authorization is a real-time decision you can gate a workflow behind. An e-Transfer request is an invitation your customer fulfills at their own bank, on their own schedule, through an interface you do not control. If your platform books appointments, releases inventory, or unlocks a job on successful payment, those two rails demand different state machines. Teams that map e-Transfer onto their existing card status model end up with orders stuck in pending and a support queue full of customers who insist they already paid.

Ask any prospective partner which specific Interac products are in scope, in writing. Ask what happens to your webhook contract when a request expires, when a customer partially pays, and when funds arrive against an invoice that was already closed.

The economics are the reason to care

Card interchange scales with ticket size. Interac pricing generally does not, which is exactly why it matters to you. On a platform processing high-ticket B2B invoices, a flat-fee rail is dramatically cheaper for the merchant and, handled correctly, still profitable for you. On low-ticket consumer volume the math inverts.

That asymmetry is a product decision, and it belongs to you rather than to your processor. You know the ticket distribution in your vertical. You know which of your merchants are quietly begging customers to send an e-Transfer outside the software because the card fee on a $14,000 invoice is intolerable. Every one of those transactions is revenue that left your platform and took the data with it. You lose the reconciliation, the reporting, the working capital signal, and the reason the merchant stays.

Under a PayFac-as-a-Service model you set the pricing on Interac the same way you set it on cards. You can charge a flat convenience fee, absorb it into a subscription tier, or price it as a cheaper alternative that pulls large invoices back in-product. What you cannot do is make any of those choices if the rail is resold to you at a fixed rate by a vendor who owns the merchant relationship.

Risk does not follow the card playbook

This is where platforms get surprised. The card networks give you a defined chargeback process with timelines, representment, and a referee. Interac e-Transfer, once deposited, is effectively final. There is no equivalent consumer-initiated reversal you can litigate months later.

That sounds like a gift, and for legitimate merchants it largely is. The exposure moves somewhere else. Fraud on e-Transfer concentrates in social engineering, redirected deposits, and impersonated invoices, and the losses land on parties who cannot claw funds back. Your platform becomes the control point. Autodeposit registration, recipient validation, invoice tampering detection, and velocity limits on request generation are now your responsibility, because there is no network rulebook doing that work in the background.

Your vendor should be able to describe, concretely, what tooling exists for this. Who is named in the KYC and onboarding chain. Who bears loss when a merchant's account is compromised and requests go out under their name. How disputes are surfaced to your support team when the rail itself provides no formal dispute mechanism.

What to do next

Pull the last twelve months of Canadian volume and split it by ticket size. Find the transactions above the threshold where card economics stop making sense for your merchants, then estimate how many of those are already happening off-platform. That number is your Interac business case, and it is usually larger than executives expect.

Then take three questions to whoever provides your payments infrastructure. Which Interac products do I control, not just support. Who sets the price to my merchant. Who owns the loss. If the answers are not yours, yours, and clearly defined, you are building a Canadian payment feature that someone else will monetize.

Sources: Interac 2025 Corporate Year in Review · Interac, Understanding Fees · Interac history · Interac e-Transfer, Wikipedia