Receiving moneyCAD & Interac

CAD & Interac

CAD doesn’t use a VIBAN. Instead, the merchant or customer has a registered Interac e-Transfer address, and senders e-Transfer to that address. When a transfer lands, the funds settle to your merchant wallet and Swappr fires a wallet_funded webhook — the same attribution model as the VIBAN rails.

Recipient vs sender

An inbound Interac transfer has two parties, and getting them the right way round matters:

  • Recipient — your registered Interac address (payee_collection_email on the inbound event). This is the address the money was sent to, and it’s what determines whose wallet/customer the funds belong to.
  • Sender — a separate address (source_information.collection_email) identifying who sent the transfer.

Funds are attributed to the recipient address’s owner — never to the sender. (Resolving an inflow against the sender’s address instead of the recipient’s was a real bug; the recipient is always the side you own.) On the wallet_funded payload the sender’s Interac email surfaces in sender.interac_email (see the field reference in Webhooks). To distinguish Interac inflows, branch on event.rail === 'interac', not a provider slug.

Only successful collections credit

A CAD collection credits your wallet only when it completes successfully. Failed or other inbound states are recorded for audit but do not credit the wallet and do not fire a wallet_funded event — so a wallet_funded for CAD always means money actually landed.

Attribution

Just like the VIBAN rails, the merchant wallet is credited, and the wallet_funded payload carries a customer block when the registered Interac address belongs to a customer (omitted for a merchant/treasury address). Branch on event.customer?.id. See Attribution & balances.

Sandbox limitation: CAD/Interac inflows aren’t simulated in the development environment — only NGN settles in sandbox. Test the webhook-handling path with a sandbox NGN credit, then validate CAD inflows in live.

Next

What’s next