Interac Debit and Domestic Debit Cards. Trace Canadian debit-card authorization, clearing, settlement, merchant funding and refund operations.
Block 10 · Chapter 47 of 75
Interac Debit is one of Canada’s most familiar payment experiences: the customer taps, inserts or presents a card or digital-wallet credential, and the financial institution normally authorizes the purchase online. Some supported delayed-authorization POS paths are a distinct exception. Behind the customer experience sits a wider operating model covering issuer authorization, account posting, fraud controls, acquiring, clearing, settlement, merchant funding, reversals, refunds, disputes and reconciliation.
This chapter explains that full lifecycle in the same practical way as the earlier Canada chapters. The central distinction is simple but essential: authorization is not settlement. For standard point-of-sale paths, an approved response is a real-time decision by the issuer; Rule E5 delayed-authorization paths are distinct. Clearing and settlement happen as separate downstream processes, and merchant funding follows the merchant’s acquiring arrangement. Customer service and operations must keep those layers separate when investigating a duplicate, timeout, refund or unauthorized transaction.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- identify the cardholder, issuer, Interac/network, acquirer/processor and merchant roles;
- trace chip-and-PIN, contactless and mobile-wallet debit transactions;
- distinguish authorization, customer posting, clearing, settlement and merchant funding;
- explain issuer controls for card status, available funds, limits and fraud;
- investigate declines, timeouts, duplicates, reversals and refunds;
- explain customer protections for unauthorized debit transactions;
- describe point-of-sale clearing at a functional level without inventing proprietary message details;
- reconcile authorization, clearing, settlement and posting records;
- design realistic implementation and testing scenarios for a Canadian debit-card platform.
For a roughly 60-minute core session, spend 10 minutes on Sections 1–2, 15 minutes on Sections 3–4, 10 minutes on Sections 5–6, 10 minutes on Sections 7–9, 10 minutes on the practical examples, and 5 minutes on the references.
Chapter navigator
- Business context and customer need
- Participants and responsibilities
- Authorization and customer-account processing
- Clearing, settlement and merchant funding
- Data, authentication and transaction identity
- Limits, service levels and customer impact
- Fraud, security and consumer protection
- Reversals, refunds and disputes
- Posting, accounting and reconciliation
- Implementation, testing and resilience
- Practical Canadian examples
- Key takeaways and authoritative references
1. Business context and customer need
A domestic debit card lets a customer pay a merchant using funds in a deposit account. It is not a revolving-credit product, and it is not the same as Interac e-Transfer. The transaction is initiated in a merchant environment through a debit credential linked to the customer’s account.
Interac Debit can be used through chip-and-PIN, contactless cards, mobile wallets and supported e-commerce experiences. Interac’s public guidance explains that the transaction is approved by the customer’s financial institution in real time. That real-time issuer decision is the first major event in the lifecycle, not the final accounting event.
The customer sees one purchase. The bank sees a chain: credential presentation, authentication, issuer authorization, account impact, merchant capture, clearing, participant settlement, merchant funding and reconciliation. Every incident needs to be placed on that chain before action is taken.
2. Participants and responsibilities
The cardholder presents the card or digital credential and authenticates according to the transaction type.
The issuer is the customer’s financial institution. It maintains the account, checks card and account status, validates authentication, applies limits, performs fraud decisioning, checks available funds and returns the authorization response.
The merchant captures the purchase amount and presents the transaction through a point-of-sale or e-commerce acceptance environment.
The acquirer or merchant processor provides the merchant-facing payment service, routes the transaction, receives clearing information and funds the merchant according to the commercial agreement. In Payments Canada Rule E4/E5 terminology, the Acceptor, Acquirer, Acquirer FI and Payor FI can be separate entities or, in some arrangements, one entity can perform several roles.
Interac/network services provide domestic debit acceptance and routing under their operating rules.
Payments Canada’s retail clearing framework applies to eligible intermember POS debit payment items. Rule E4 covers PIN-less POS items; Rule E5 covers delayed-authorization POS items. Exact technical message formats, network parameters and certification requirements belong to the applicable Interac, processor and Payments Canada operating documentation—not this chapter.
3. Authorization and customer-account processing
The authorization journey starts when the merchant captures the amount and the customer presents the debit credential.
For chip-and-PIN, the chip and PIN provide transaction and cardholder-authentication evidence. For contactless, the customer taps a card or device. Contactless limits and cumulative thresholds may cause the issuer or terminal flow to require chip-and-PIN. For a mobile wallet, device authentication may use biometrics or a passcode.
The issuer evaluates functional data such as:
- card or token identity;
- transaction amount and currency;
- merchant and terminal context;
- transaction type and channel;
- authentication evidence;
- account status and available balance;
- card and customer limits;
- fraud and velocity indicators.
The issuer can approve or decline. If approved, the purchase can proceed. The customer account may show an immediate debit or an authorized/pending state depending on the issuer’s posting model.
Current rule distinction. Rule E4 covers PIN-less POS transactions using an EMV or equivalent payment application. It requires online, real-time authorization; a duly authorized item creates an obligation for the Payor FI to honour, exchange and settle it, and the item is not subsequently dishonoured under the rule. Rule E5 covers delayed-authorization POS transactions: goods or services may be supplied before authorization, and authorization is performed online after that point. E5 currently permits submission or resubmission for authorization a maximum of four times within eight calendar days; once authorized, the transaction must not be submitted again. These are Payments Canada rule constraints, not universal customer-facing limits and not a statement that every Interac Debit product uses delayed authorization.
Timeouts and uncertain outcomes
A difficult case occurs when the issuer approves but the merchant terminal does not receive the response. The terminal may show failure while the issuer has already recorded an authorization. The correct response is not to assume success or failure from one side alone. Operations must check whether a reversal arrived and whether the transaction later cleared.
A useful internal state model is:
- declined;
- approved;
- timed out / uncertain;
- reversed;
- cleared / posted;
- refunded;
- disputed.
Those states should be visible to customer service rather than hidden inside separate card systems.
4. Clearing, settlement and merchant funding
Authorization is the payment decision; exchange, clearing and settlement are separate downstream processes. The Bank of Canada describes exchange as transmitting payment instructions, clearing as reconciling and establishing balances, and settlement as releasing payment obligations.
After merchant capture—or after the delayed-authorization step where Rule E5 applies—transaction records move through the acquirer and network processes. The issuer receives the payment item and applies its posting and exception rules. The Bank of Canada identifies Interac debit payments as electronic items cleared through ACSS. Under the current E4 and E5 rules, the relevant ACSS entries must be made as soon as possible and no later than the ACSS closing time for the Business Day following Authorization; Members must retain the required POS audit trail for at least 12 months and maintain records sufficient to reconcile ACSS amounts for one year.
ACSS direct clearers maintain settlement accounts at the Bank of Canada. Payments Canada states that the previous day’s net balances settle during the morning of each business day, with settlement-account balances extinguished through payments to and from the Bank of Canada. An indirect clearer relies on its direct clearer or clearing agent. This is a participant-level retail-batch position, not a promise that an individual POS approval has already settled or that merchant funding has occurred.
A bank practitioner should keep three clocks separate:
- authorization clock — seconds;
- cardholder posting clock — issuer-specific;
- intermember settlement and merchant-funding clock — downstream clearing and acquiring processes.
A merchant can receive an “approved” message without final interbank settlement having occurred at that exact moment. Likewise, the cardholder can see an account impact before clearing is complete.
Merchant funding is governed by the merchant’s acquiring contract. Sales, refunds, fees and adjustments may be combined in the merchant settlement report. That merchant report is not the same ledger as the issuer’s customer account.
5. Data, authentication and transaction identity
Operations needs stable transaction identity across:
- authorization;
- reversal;
- clearing;
- settlement;
- refund;
- dispute.
The exact network identifiers are proprietary, but the control principle is not: an investigation must be able to link the customer statement line to the corresponding authorization and downstream records without relying only on amount and date.
Authentication evidence differs by channel. Chip-and-PIN, contactless card and tokenized mobile-wallet flows produce different signals. A bank should preserve those signals for dispute analysis but should not treat the mere use of authentication technology as automatic proof that the customer authorized a disputed transaction.
FCAC guidance is important here: federally regulated financial institutions must investigate disputed unauthorized transactions and cannot hold a customer responsible simply because authentication technology was used.
6. Limits, service levels and customer impact
Debit-card limits are risk controls. A customer can have enough money in the account and still receive a decline because of a card limit, contactless threshold, fraud rule or account restriction.
The bank should explain limits clearly:
- transaction limit;
- daily debit limit;
- contactless per-transaction or cumulative threshold;
- ATM limit where applicable;
- merchant or channel restrictions.
These controls are not settlement rules. A contactless step-up simply changes the authentication path.
Customer-facing statuses should also be precise. If a transaction is only authorized, do not describe it as finally settled. If a reversal is expected after a failed merchant experience, explain the state and likely recovery path rather than saying only “wait a few days.”
7. Fraud, security and consumer protection
Debit-card risks include lost or stolen credentials, account takeover, social engineering, compromised merchant environments, unauthorized mobile-wallet provisioning, card-not-present misuse and abnormal transaction velocity.
A layered control stack includes:
- chip and PIN;
- tokenized mobile credentials;
- device authentication;
- card and account limits;
- real-time fraud scoring;
- velocity and merchant-pattern controls;
- alerts and card lock/unlock;
- monitoring of wallet provisioning;
- dispute and reimbursement workflows.
The Code of Conduct for the Payment Card Industry in Canada is a merchant-facing framework adopted by Payment Card Network Operators (PCNOs) that choose to adopt it, and by their Participants. It addresses transparency, pricing information, merchant choice and complaint handling; it is not a blanket statement that every debit transaction is governed by one identical scheme rule.
For consumer unauthorized transactions, FCAC guidance and network protections such as Interac Zero Liability are relevant. Operations must use the customer agreement, current legal requirements and network policy when deciding the case.
8. Reversals, refunds and disputes
A reversal is linked to an earlier authorization and is generally used when the original approved transaction should not complete.
A refund is a separate merchant-initiated value return after a completed purchase. Under the E4/E5 rules, returns and refunds operate in the reverse direction; Rule E5 also allows a return/refund to be initiated by the Acceptor without the payment application being present. The bank still needs the applicable network and product procedure for posting and linkage.
A dispute is a governed claim process and should not be confused with either of those.
Common cases
Declined but customer sees an amount. Check authorization state and reversal evidence.
Charged twice. Determine whether two authorizations and two clearing records exist. Do not infer duplicate settlement from two visible entries alone.
Merchant says refund sent. Trace the refund as its own transaction. Do not ask the merchant to refund again before confirming the first refund state.
Customer denies purchase. Open the unauthorized-transaction investigation. Authentication evidence is part of the case, not the entire conclusion.
E4/E5 Payor claims. For a claim concerning an approved PIN-less or delayed-authorization POS item, the Payments Canada rules require the Payor FI to maintain clear, timely investigation procedures and respond as soon as possible, but no later than 10 Business Days. The period may be temporarily suspended when the FI requests a statement/affidavit from the Payor or information from another Member and is waiting for it. This is a scheme-rule procedure for those payment items, not a universal deadline for every debit-card complaint or a substitute for applicable federal consumer-protection requirements.
9. Posting, accounting and reconciliation
Issuer reconciliation should connect:
- authorization to customer-account impact;
- clearing to final posting;
- clearing totals to settlement;
- reversals and refunds to their originals.
Useful exception categories include:
- approved not cleared;
- cleared without matched authorization;
- duplicate clearing;
- unmatched reversal;
- unmatched refund;
- settlement-total mismatch;
- customer-posting failure.
Each category needs an owner and ageing rule. A generic “card suspense” bucket is not enough for a production control model.
The acquirer has a parallel reconciliation: merchant capture, network clearing, merchant funding, fees, refunds and adjustments.
10. Implementation, testing and resilience
A debit-card platform typically spans card management, account processing, authorization switch, fraud engine, network gateway, clearing processor, settlement accounting, digital-wallet/token services and dispute tooling.
Testing should cover:
- chip-and-PIN approve/decline;
- contactless approve and step-up;
- mobile-wallet authorization;
- insufficient funds;
- blocked/lost card;
- fraud decline;
- terminal timeout after issuer approval;
- issuer timeout;
- reversal;
- duplicate retry;
- clearing after authorization;
- clearing without matched authorization;
- refund;
- unauthorized-transaction dispute;
- reconciliation mismatch.
Resilience design must preserve transaction identity during failover. Replay after recovery must be idempotent. A restarted authorization or clearing service must not turn a technical retry into a second economic transaction.
Deep dive: the authorization system as a bank control boundary
For Interac Debit, the issuer authorization platform is the moment where the bank decides whether a customer account may support the purchase presented by the merchant. That makes authorization much more than a network response generator. It is a control boundary joining card status, customer authentication, available funds, account restrictions, limits, fraud decisioning and channel context.
A good authorization design answers the following questions in a deterministic sequence:
- Is the credential recognized and active?
- Is the card or token permitted for this transaction type?
- Is the customer/account relationship still valid?
- Has the transaction been authenticated as required by the acceptance method?
- Is the amount within card, account and channel limits?
- Is sufficient available balance present?
- Are there blocks, holds or legal restrictions on the funding account?
- Does fraud decisioning permit the transaction?
- Is the issuer platform able to commit the decision safely and return a response?
The order matters. For example, a blocked card should not continue unnecessarily into an expensive fraud-model call. A fraud decline should not be converted into “insufficient funds” merely because the account also has low balance. The decline reason shown to the customer may be simplified, but the internal reason needs to remain precise for analytics and servicing.
Available balance is a product decision, not only a ledger field
The issuer must define which balance is used for debit authorization. A chequing account can have:
- ledger balance;
- available balance;
- overdraft availability;
- holds;
- pending credits;
- restricted funds;
- provisional deposits.
Authorization should use the bank’s approved available-funds logic. That logic needs to be consistent across debit card, ABM and other real-time account-access products where the same account is used.
A common production defect occurs when the card switch caches balances while the core ledger uses fresher holds. The card system approves using stale availability and the core later cannot post cleanly. Strong architecture either uses a real-time funds service or defines controlled synchronization with reconciliation for drift.
Chip-and-PIN flow from a functional perspective
The detailed EMV cryptography belongs in scheme and terminal specifications, but a bank practitioner should understand the business sequence.
The terminal reads the chip application. The transaction amount and merchant context are established. The cardholder enters a PIN when required. Transaction security data is generated. The request reaches the issuer through the acquiring/network path. The issuer verifies what it is responsible for verifying, applies account and fraud controls and returns approve or decline.
Important operational evidence includes:
- transaction timestamp;
- merchant/terminal context;
- chip/contactless indicator;
- verification-method result;
- issuer response;
- authorization reference;
- account impact;
- reversal/clearing linkage.
When a customer disputes a transaction, this evidence supports investigation. It should not be reduced to “PIN used = customer liable.” FCAC guidance on unauthorized transactions emphasizes that federally regulated institutions must investigate disputed transactions and cannot rely solely on the fact that authentication technology was used.
Contactless and cumulative-limit behaviour
Interac’s public guidance notes that contactless payments can be made with a card, phone or wearable, and that cumulative contactless limits vary by financial institution. When the cumulative threshold is reached, the customer may be required to insert the card and enter the PIN.
That creates useful test cases:
- contactless below threshold;
- transaction exceeding per-transaction rule;
- cumulative threshold reached;
- contactless followed by successful chip-and-PIN;
- contactless attempted with blocked card;
- mobile-wallet contactless with device authentication;
- retry after contactless timeout.
The customer should not be told that a threshold decline means the account lacks funds. The channel or terminal experience should encourage the stronger authentication path where applicable.
Mobile wallets and token lifecycle
A mobile wallet introduces a tokenized credential and a new lifecycle.
The bank needs processes for:
- token provisioning;
- device eligibility;
- customer verification during provisioning;
- token activation;
- token suspension;
- lost-device handling;
- card replacement;
- account closure;
- token deletion.
A card may be active while one device token is suspended. Conversely, replacing a physical card can have implications for wallet tokens depending on network/token-service rules. Servicing screens need to distinguish card status from token status.
Provisioning itself is a fraud event worth monitoring. If an attacker has compromised online-banking credentials and provisions a card to a new device, later purchase authentication may appear technically valid even though the original provisioning was fraudulent. Fraud models should therefore connect provisioning context to subsequent transactions.
Merchant and terminal context
Issuer fraud models use merchant context because transaction behaviour differs by merchant type, location and channel.
Useful signals include:
- merchant category;
- merchant identity;
- terminal type;
- country/location;
- contactless/chip/e-commerce channel;
- transaction amount;
- time of day;
- recent customer behaviour;
- repeated declines;
- velocity across merchants;
- device/token history.
The bank should not build customer-facing conclusions directly from a single signal. A late-night purchase can be perfectly legitimate; a combination of new device, distant location, rapid velocity and unusual merchant type is more meaningful.
Authorization timeouts and the two-generals problem
A payments timeout creates a classic distributed-systems uncertainty: one side may have committed while the other side did not receive the response.
Consider this sequence:
- merchant sends authorization;
- issuer approves and commits an authorization hold;
- issuer sends response;
- network or terminal connection fails before merchant receives it;
- terminal reports failure;
- customer retries.
The system now needs duplicate and reversal logic. If the customer retries, the issuer should be able to identify whether the second request is a new economic transaction or a retry/duplicate according to network identifiers and timing.
Customer service also needs a truthful state. “Declined” is wrong if the issuer approved. “Completed” is wrong if no clearing later arrives. The honest state is uncertain/pending until reversal or clearing evidence resolves it.
Reversal design
A reversal releases or negates a prior authorization when the transaction should not proceed.
Functional requirements should state:
- how the original authorization is identified;
- how much is reversed;
- whether partial reversal is supported;
- what happens if reversal arrives before authorization persistence;
- what happens if reversal is duplicated;
- how account availability is restored;
- how reversal is reconciled.
A reversal must be idempotent. Two copies of the same reversal must not release funds twice.
Clearing and completion
Authorization is permission. Clearing is the downstream financial presentation of the completed transaction.
Issuer processing needs to match clearing to the original authorization where applicable. Matching may consider network references, merchant, amount and dates according to scheme rules.
Possible outcomes include:
Exact match — clearing corresponds to authorization.
Allowed amount variation — for certain merchant types or approved circumstances, final clearing can differ from authorization.
Clearing without matched authorization — exception requiring scheme and bank handling.
Authorization without clearing — may expire/reverse.
Duplicate clearing — two clearing records appear for one economic transaction.
This is why card reconciliation cannot be replaced by customer-account balancing alone.
Merchant funding on the acquiring side
The acquiring side aggregates captured merchant activity and applies the merchant agreement.
A merchant settlement statement may include:
- gross sales;
- refunds;
- adjustments;
- fees;
- net funding;
- chargeback/dispute adjustments.
The merchant may be funded on a schedule independent of when individual issuers post customers. The exact commercial timing depends on the acquirer relationship.
For a bank that is both issuer and acquirer, internal architecture should still keep the roles separate. An issuer ledger should not rely on merchant funding data to prove cardholder posting.
Domestic debit clearing and Payments Canada rules
Payments Canada’s rule library includes rules for exchange of point-of-service debit payment items, including online and PIN-less/delayed-authorization categories. A practitioner should use those current rules for exact eligibility and settlement treatment.
The chapter deliberately does not invent field-level message flows. Network technical specifications and Payments Canada rule text are the implementation source of truth.
What matters functionally is that eligible intermember debit obligations are represented in retail clearing and settlement, and participants reconcile network activity to their financial positions.
A five-layer reconciliation model
Layer 1 — terminal/acquirer to authorization network
Does every merchant authorization request have a network outcome?
Layer 2 — authorization network to issuer decision
Does the issuer’s authorization log agree to network requests and responses?
Layer 3 — authorization to clearing
Did completed purchases clear once and only once?
Layer 4 — clearing to settlement
Do participant clearing totals agree to settlement accounting?
Layer 5 — clearing to customer/merchant books
Did the issuer post the correct customer account and did the acquirer fund the merchant correctly?
The same transaction can be healthy in four layers and broken in one. That is why incident teams need layer-specific dashboards.
Debit-card accounting states
A bank should document how authorization affects the deposit account.
Possible designs include:
- immediate final debit at authorization;
- memo/pending debit followed by final posting;
- available-balance reservation with ledger posting later.
Whatever model is chosen, three rules are essential.
First, available balance must prevent overspending. Second, clearing must not create a second economic debit. Third, reversal/expiry must restore availability exactly once.
Customer servicing vocabulary
Customer-service scripts should use state-specific words.
Declined — issuer/network returned a negative authorization result.
Pending/authorized — issuer approved, final completion not yet represented in posted clearing.
Posted — final transaction is on the account.
Reversed — prior authorization has been released/cancelled.
Refund pending/posted — merchant-initiated credit has its own lifecycle.
Disputed — formal investigation/claim is open.
Using “reversed” to describe a refund or “refund” to describe release of a temporary authorization confuses customers and operations.
Fraud decisioning architecture
A modern issuer fraud platform often receives:
- customer profile;
- account profile;
- card/token profile;
- device profile;
- merchant context;
- transaction history;
- real-time velocity;
- authentication result.
The decision can be approve, decline or step-up where the product/channel permits.
The fraud service should return a reason code meaningful enough for internal analytics while customer-facing responses remain appropriate and do not teach attackers exact rules.
Lost/stolen card journey
A complete lost-card journey is:
- customer reports loss;
- physical card is blocked;
- token/wallet implications are evaluated;
- recent authorizations are reviewed;
- suspicious transactions are disputed where appropriate;
- replacement card is issued;
- recurring token/card relationships are updated according to network capability;
- account monitoring continues.
A servicing application that blocks only the plastic and ignores active wallet tokens is incomplete.
Unauthorized-transaction investigation
A bank should build a structured evidence pack.
Customer evidence
- customer statement;
- date customer first noticed;
- possession/loss of card or device;
- travel/location context;
- prior fraud reports.
Transaction evidence
- card/token used;
- merchant;
- amount;
- channel;
- authentication indicator;
- authorization result;
- clearing record.
Security evidence
- device/token provisioning;
- PIN events where available;
- failed attempts;
- account takeover indicators;
- credential reset events.
Bank response
- card/token block time;
- alerts;
- subsequent transactions;
- investigation result;
- reimbursement decision.
The bank should document reasoning, not simply output a liability code.
Merchant protections under the Canadian Code
The Code of Conduct for the Payment Card Industry in Canada is relevant to merchants and network participants. The current federal Code page lists October 30, 2024 as the Code’s effective date. It emphasizes transparency, pricing information, flexibility and merchant choice. Do not carry forward an April 30, 2025 staged-effective-date claim without an element-specific official notice.
For bank and processor teams, relevant areas include:
- clear merchant agreements and fee disclosures;
- notice of certain fee changes;
- merchant choice over payment options;
- complaint handling;
- rules around competing domestic debit applications;
- device provisioning/default choice;
- clear separation of payment-card functions.
A consumer debit dispute and a merchant Code complaint are different operational cases and should route to different teams.
BA functional requirements
Card status
Given a card is reported lost, no new debit authorization using that card credential may be approved after the block becomes effective, subject to defined network/stand-in behaviour.
Available funds
The authorization service must use the approved available-balance definition and return a deterministic insufficient-funds result when availability is below the required amount and no overdraft covers it.
Timeout
If the issuer commits an approval but the outbound response times out, the authorization record must remain traceable and capable of matching a later reversal or clearing.
Duplicate
A duplicated network message for the same authorization must not create an additional hold or debit.
Reversal
A valid reversal must restore the authorization impact exactly once and preserve linkage to the original.
Clearing
A clearing record must match the original authorization where applicable and must post the customer account exactly once.
Refund
A refund must create a separate credit lifecycle linked to the original purchase where the network data provides the relationship.
Test matrix for issuer processing
A serious regression pack should include:
Credential state
- active;
- expired;
- lost/stolen;
- replaced;
- wallet token active;
- wallet token suspended.
Account state
- normal;
- insufficient funds;
- overdraft available;
- frozen;
- dormant/restricted.
Authentication
- chip-and-PIN success;
- wrong PIN;
- contactless below threshold;
- contactless cumulative threshold reached;
- mobile-wallet authentication success;
- e-commerce path where supported.
Risk
- normal;
- velocity;
- unusual geography;
- new device;
- merchant risk;
- suspected account takeover.
Network
- approval;
- decline;
- issuer timeout;
- network timeout;
- duplicate request;
- delayed reversal.
Clearing
- exact match;
- allowed amount difference;
- unmatched;
- duplicate;
- delayed;
- refund.
Accounting
- authorization hold;
- final posting;
- reversal;
- refund credit;
- reconciliation break.
Resilience and stand-in considerations
Card authorization is high-availability infrastructure. If the issuer host is unreachable, network or processor arrangements may support contingency/stand-in behaviour depending on the contractual design. Banks must understand exactly what can be approved during degraded operation and how those decisions are synchronized later.
Recovery requirements should cover:
- authorization log persistence;
- prevention of duplicate holds;
- reconciliation of stand-in decisions;
- late clearing;
- token/card status synchronization;
- fraud-rule consistency;
- customer balance accuracy.
A system that restores technical service but cannot reconcile what was approved during the outage is not recovered.
Operational day-in-the-life
Start of day — prior settlement and reconciliation breaks are reviewed.
Continuous — authorization traffic is monitored for approval rate, decline reasons, latency, fraud rate and network errors.
Continuous — card/token lifecycle events update the authorization platform.
Clearing cycles — incoming clearing is matched to prior authorization and posted.
Settlement — network/clearing totals are reconciled to financial accounting.
Refund/dispute queues — aged items are reviewed.
End of day — exceptions are categorized and metrics published.
Important metrics include:
- authorization approval rate;
- technical decline rate;
- fraud decline rate;
- average/percentile latency;
- unmatched clearing;
- duplicate clearing;
- reversal success;
- refund posting time;
- dispute volume;
- reconciliation breaks;
- customer complaints.
Practical design-review checklist
Before approving a debit-card platform, ask:
- Is card status authoritative and real-time?
- Is token status separate from plastic-card status?
- Which balance definition authorizes?
- How are pending authorizations represented?
- How is a timeout represented to servicing?
- Can duplicated requests create duplicated holds?
- Can reversal be applied twice?
- How are authorization and clearing matched?
- How are unmatched clearings handled?
- Can customer service distinguish pending from posted?
- Does refund have its own lifecycle?
- How is unauthorized-transaction evidence assembled?
- Are FCAC consumer-protection obligations reflected in process?
- Are merchant Code complaints routed separately?
- Can issuer and acquirer books reconcile independently?
- What happens during issuer/network outage?
- How are contingency approvals reconciled after recovery?
If the platform cannot answer those questions from stored data, it will struggle during its first serious incident.
Advanced operations: tracing a debit transaction across systems
A useful investigation discipline is to trace a disputed debit-card transaction through every system in the order in which evidence should exist.
Start with the customer statement line. Capture the amount, date, merchant description and customer account. This tells you what the customer sees, not yet what the network did.
Next retrieve the authorization event. Confirm whether the issuer approved or declined, the exact timestamp, the card/token credential used and the authorization reference. If no authorization exists, the clearing item may be unmatched or the search key may be wrong.
Then retrieve the reversal history. A terminal timeout can produce an approval and later reversal. If a reversal exists, confirm whether it released the hold and whether any subsequent clearing nevertheless arrived.
Next retrieve the clearing record. This is the evidence that the merchant/acquirer presented the completed financial transaction. Compare merchant, amount and network identifiers to the authorization.
Then check customer posting. Did the clearing item post once? Is there a pending authorization still open in addition to the posted debit? If so, the problem may be stale authorization release rather than duplicate settlement.
Finally check settlement/reconciliation. Did the clearing total participate in the expected participant accounting, and are there any network adjustments?
The chain should be navigable using linked identifiers. If investigators must copy amount and date into five different tools and visually guess the same transaction, the architecture is creating operational risk.
The “double debit” taxonomy
Customers use “charged twice” for several different situations.
Two pending authorizations, one completed purchase.
Often caused by retry after timeout. One may later reverse or expire.
One pending authorization plus one posted transaction.
The final clearing posted, but the original authorization hold has not yet released. Economically there is one completed purchase, but available balance may temporarily look reduced twice.
Two posted clearing transactions.
This is a genuine duplicate financial presentation unless two distinct purchases were made.
One purchase plus one unrelated similar amount.
A merchant can have repeated amounts; investigation must use identity, not amount.
Purchase plus cash-back or separate service amount.
Some transaction structures can create additional account movements that customers interpret as duplication.
Each class needs a different fix. A customer-service policy that refunds first and investigates later can create over-credit in the first two cases.
Decline analytics
Declines should be categorized carefully because they drive customer experience and fraud performance.
Useful internal categories include:
- insufficient available funds;
- card status;
- account restriction;
- PIN/authentication failure;
- limit exceeded;
- contactless step-up required;
- suspected fraud;
- technical/network failure;
- unsupported transaction;
- merchant/terminal issue.
Customer-facing wording may be intentionally generic for security, but analytics should retain the detailed reason.
An unusual rise in insufficient-funds declines may be real economic behaviour or a defect in available-balance synchronization. A spike in technical declines concentrated on one acquirer may be connectivity. A sudden increase in contactless declines after a parameter release may indicate threshold configuration.
Fraud-versus-technical-decline separation
Fraud systems and platform availability need separate measures.
If all declined transactions are combined, a fraud-rule tuning change can make the authorization platform appear less reliable. Conversely, a network outage can be misread as fraud prevention.
Recommended metrics:
- total authorization requests;
- issuer approvals;
- business declines;
- fraud declines;
- technical declines;
- timeouts;
- average latency;
- p95/p99 latency;
- stand-in rate where applicable.
PIN management and servicing
The customer PIN lifecycle includes:
- PIN selection or issuance;
- PIN change;
- failed-attempt counter;
- PIN retry/reset procedure;
- card replacement;
- compromised PIN handling.
The authorization platform must receive current PIN status. A customer who has reset a PIN should not experience a stale retry counter at the switch. Servicing should show whether a decline resulted from PIN attempts without exposing sensitive security detail beyond policy.
Contactless risk parameters
Contactless convenience depends on risk parameters.
Banks may maintain:
- per-transaction limits;
- cumulative amount;
- cumulative count;
- time/velocity thresholds;
- merchant/channel restrictions.
The exact values are FI-specific and can change. Training content should therefore explain the mechanism rather than hard-code a number that will go stale.
When the threshold is reached, chip-and-PIN can re-establish stronger cardholder verification and reset/affect the contactless state according to product design.
Card-present versus digital-wallet evidence
A plastic contactless transaction and a mobile-wallet transaction can both appear as “tap,” but the credential evidence differs.
A mobile wallet can involve:
- device token;
- device identifier;
- token provisioning history;
- device authentication;
- token status.
A plastic card uses the card credential directly.
For fraud investigation, this difference matters. A customer may physically possess the plastic card while an unauthorized token exists on another device. “Customer still has the card” does not rule out token compromise.
E-commerce debit considerations
Where Interac Debit is supported through e-commerce/digital-wallet experiences, the bank should treat the channel explicitly. Card-not-present risk patterns differ from physical point of sale.
Requirements should identify:
- supported wallet/checkout path;
- customer authentication;
- merchant information;
- issuer decisioning;
- refund path;
- dispute path;
- reporting label on customer statement.
Do not reuse a physical-terminal assumption simply because the funding account is the same.
ABM relationship
Interac Debit credentials can also support ABM access, but ABM withdrawal is a different transaction type with physical cash dispensing.
A bank’s card platform may share:
- card status;
- PIN;
- account selection;
- limits;
- authorization.
The ABM process adds:
- ATM/ABM terminal state;
- cash inventory;
- dispense sensors;
- partial/failed dispense handling;
- cash reconciliation.
A debit-card programme should ensure card-status changes propagate consistently to POS and ABM channels.
Merchant dispute versus consumer dispute
Two complaints can reference the same card transaction but belong to different frameworks.
A consumer dispute may concern unauthorized use, wrong amount, duplicate, refund or service issue.
A merchant complaint may concern processing fees, agreement disclosure, network choice or processor obligations under the Canadian Code.
A bank or processor that routes every complaint into the cardholder-dispute team will fail merchants; a merchant-service team that tries to resolve a consumer unauthorized-transaction case will also fail.
Routing criteria should be explicit.
Consumer reimbursement decision design
The decision process for an unauthorized debit transaction should be auditable.
It should capture:
- transaction(s) disputed;
- customer report;
- card/token status;
- authentication indicators;
- relevant alerts;
- device/account events;
- investigation notes;
- applicable customer agreement;
- applicable network protection;
- regulatory obligations;
- outcome;
- reason;
- reimbursement accounting.
The customer communication should explain the outcome in understandable language. Internal fraud codes alone are not sufficient communication.
Temporary credit
Some institutions may provide provisional or temporary credit during investigation according to policy. If used, temporary credit needs its own accounting identity.
Requirements should state:
- when temporary credit is created;
- whether it affects available balance;
- how it links to the dispute;
- how final reimbursement replaces it;
- how it is reversed if the claim is denied;
- statement description;
- customer notification.
Otherwise, investigation closure can accidentally leave both temporary and final credits.
Merchant refunds
A merchant refund is a new financial event.
The bank should record:
- original transaction link where available;
- refund amount;
- merchant;
- refund authorization/clearing reference;
- posting date;
- customer credit.
Partial refunds need to be supported without marking the original purchase as “reversed.”
A customer can receive multiple partial refunds against one purchase. The relationship is one-to-many.
Reconciliation tolerances and ageing
Not every authorization-to-clearing match resolves the same day. The issuer needs ageing buckets.
For example:
- authorized <24h not cleared;
- 1–3 days;
- older than expected;
- reversed;
- expired.
The expected age varies by transaction type and network rules, so the actual thresholds belong in current operational procedures. The design requirement is to classify and age, not leave unmatched items indefinitely.
Charge and refund descriptions
Customer statements are part of operational control.
A useful statement line should present enough information to recognize the merchant without exposing sensitive network data. Poor merchant descriptors drive disputes because customers cannot identify legitimate purchases.
Banks should monitor “merchant not recognized” disputes and work with acquiring/network data quality where systemic descriptor problems exist.
Data retention and privacy
Card transaction data includes personal and security-sensitive information. The bank should retain what is required for accounting, disputes, fraud and legal obligations while limiting unnecessary exposure.
Operations screens should mask credentials appropriately. Investigators need identifiers, but not every user needs a full PAN or token.
Logging systems should avoid accidentally writing sensitive authentication data into general application logs.
Authorization modernization: service decomposition
A modern card platform may decompose capabilities:
- card/token service;
- account/funds service;
- fraud decision service;
- limit service;
- authorization orchestrator;
- network adapter;
- posting service;
- reconciliation service.
This can improve scalability, but latency budgets become critical. An authorization path that calls eight services serially can fail its response objective even when every service is individually “fast.”
Architects should define:
- total end-to-end latency budget;
- timeout per dependency;
- fallback behaviour;
- circuit-breaker policy;
- data freshness;
- consistency requirements.
Failure-mode examples
Funds service unavailable.
Do not silently approve based on zero/stale data unless a formally approved contingency exists.
Fraud service timeout.
The bank needs an explicit fail-open/fail-closed/contingency policy by transaction type and risk, not an accidental default.
Token service stale.
A recently suspended token must not continue authorizing indefinitely.
Posting service delayed.
Authorization can still have committed. The bank needs a durable event and recovery queue rather than resubmitting the purchase.
Clearing processor unavailable.
Incoming clearing must be buffered/recovered without duplicate posting.
Test-data strategy
Card testing requires realistic combinations without using live sensitive data.
A controlled synthetic test set should include:
- multiple customer/account profiles;
- normal and low balances;
- blocked/restricted accounts;
- card states;
- token states;
- merchant categories;
- currencies/channels where relevant;
- transaction amounts;
- duplicate identifiers;
- reversal and refund chains.
Test cases should assert not only the response code but all side effects: hold, posting, fraud log, reconciliation record and customer status.
Production release controls
A release affecting authorization should use tighter controls than a static content release.
Recommended practices include:
- pre-production performance test;
- shadow/parallel comparison where feasible;
- canary rollout;
- live approval-rate monitoring;
- decline-reason monitoring;
- latency monitoring;
- rollback plan;
- reconciliation after release.
A small unexpected decline increase can affect many customers quickly.
Incident example: authorization latency
Suppose p99 authorization latency rises from normal levels to several seconds. Customers begin removing cards from terminals early, terminals retry and duplicate-looking authorizations increase.
The incident team should correlate:
- latency;
- timeout rate;
- duplicate requests;
- reversal rate;
- processor/acquirer distribution;
- recent releases.
The solution may be a dependency slowdown rather than network failure. Customer complaints are a downstream symptom.
Incident example: stale card block
A card-management service records a stolen-card block, but replication to the authorization switch is delayed.
Transactions continue to approve for several minutes.
This is a control incident because the authoritative risk state did not propagate within the required time. The fix is not only to decline the later transactions; architecture needs a measurable propagation SLA and alert when card-state synchronization lags.
Incident example: settlement mismatch
Authorization and customer posting look healthy, but settlement reconciliation shows a difference against network/clearing totals.
The team should not “fix” individual customer accounts unless item-level investigation proves a posting defect. The break may be participant accounting, a late clearing file, duplicate file load or settlement interface.
The reconciliation system should isolate the population contributing to the difference.
Product-owner metrics
A product owner should see more than transaction volume.
Useful scorecard:
- active debit cards/tokens;
- purchase volume/value;
- authorization approval rate;
- customer technical-decline rate;
- contactless share;
- mobile-wallet share;
- fraud loss rate;
- false-positive decline indicators;
- reversal rate;
- refund rate;
- dispute rate;
- unauthorized claim cycle time;
- reconciliation breaks;
- merchant/customer complaint themes.
The point is to connect customer experience, financial control and fraud performance.
BA acceptance criteria: additional examples
Token suspension
Given token T is suspended while physical card C remains active, when an authorization using T arrives after suspension effective time, then the issuer declines according to token status while transactions using valid C continue according to normal controls.
Contactless step-up
Given the customer has reached the configured cumulative contactless threshold, when another contactless attempt is made, then the transaction follows the required step-up behaviour and a later chip-and-PIN transaction can restore permitted contactless use according to FI/network rules.
Lost card propagation
Given a card is marked lost at time T, then the authorization platform receives the block within the defined propagation SLA and monitoring alerts if the SLA is breached.
Unmatched clearing
Given a clearing item cannot be matched to prior authorization, then it is not silently discarded; it enters the defined exception path, is posted or held according to scheme/bank rules, and remains traceable.
Refund chain
Given two partial refunds against one purchase, then both credits link to the original transaction and the original remains posted as the purchase rather than being overwritten.
Practitioner checklist
When reviewing an Interac Debit design, confirm:
- current Interac/Payments Canada rule references are used;
- no proprietary message behaviour is invented;
- card and token states are separate;
- available funds are defined;
- authorization and settlement are separated;
- customer posting and merchant funding are separated;
- timeouts have an uncertain state;
- retries are duplicate-safe;
- reversals link to originals;
- refunds are new credits;
- dispute evidence is structured;
- consumer investigations do not assume authentication proves liability;
- merchant Code complaints have a separate route;
- settlement reconciliation is independent of customer posting;
- outage/stand-in behaviour is documented;
- all lifecycle events are observable.
That checklist is the difference between a debit-card feature that works in the happy path and a bank-grade debit-card service that can survive incidents, disputes and audit.
The following implementation scenarios are fictional and illustrate control design; they are not claims about a named bank or Interac’s proprietary processing.
Detailed scenario laboratory
The following scenarios are useful because they force a team to reason across authorization, customer posting, network processing and operations rather than solve only the front-end symptom.
Scenario A: contactless retry after a slow terminal
A customer taps at a convenience store. The issuer approves in 400 milliseconds, but the acquirer-to-terminal path is delayed. The terminal waits several seconds, then displays an error. The cashier asks for another tap. The second request reaches the issuer with a different network transaction identifier because the terminal created a fresh attempt.
The bank now sees two approved authorizations for the same merchant and amount within ten seconds.
A simplistic duplicate engine might automatically decline the second request. That can help, but it can also create false declines where the customer genuinely buys the same amount twice. The correct control combines network identifiers, merchant/terminal context, timing and product rules. The customer-facing tool should show that the first authorization is unresolved, not “definitely charged.”
Later the acquirer sends a reversal for the first authorization and clearing for the second. Reconciliation proves only one completed purchase.
Acceptance criteria should assert:
- two authorizations remain distinct;
- first reversal maps to first authorization;
- second clearing maps to second authorization;
- only one final debit remains;
- temporary balance impact is released correctly;
- customer servicing can see the full sequence.
Scenario B: lost phone, active wallet token
A customer loses a phone containing a provisioned debit token but still has the physical card. The customer calls to report the phone lost.
If the servicing agent blocks the physical card unnecessarily, the customer loses all card access. If the agent does nothing because the plastic card is safe, the lost token may remain active.
The platform must expose token-level controls. Operations should suspend or delete the lost-device token according to the wallet/network process while preserving the physical card if appropriate.
Testing should verify:
- token status update reaches authorization;
- physical card remains usable where intended;
- later token transactions decline;
- replacement device provisioning requires fresh verification;
- fraud monitoring links attempted token use to the lost-device case.
Scenario C: core balance lag
The authorization switch uses a balance cache refreshed every few seconds. A large account debit posts through another channel, but the cache has not yet updated. A debit-card purchase is approved against the stale higher balance.
The design question is not merely “how often should we refresh?” It is what consistency the bank promises. If the available-funds service is authoritative, the switch should call it or receive event-driven updates with a defined maximum lag. If the bank knowingly authorizes using a cache, overdraft and reconciliation handling must be designed around that choice.
Metrics should track authorization approvals that later fail posting for insufficient funds. A rise in this metric is a consistency signal.
Scenario D: refund after card replacement
A customer buys an item, then the physical card is replaced because it expires. The merchant later issues a refund against the original transaction.
The issuer should be capable of routing the refund to the underlying account relationship according to network rules even though the physical credential changed. The customer should not be told that the merchant must refund to a new card number unless that is actually required by the network/process.
Operations needs the original transaction link and current account relationship.
Scenario E: suspicious merchant velocity
A customer normally makes a few debit purchases per day. Suddenly 25 low-value transactions arrive from the same merchant in ten minutes.
The fraud engine may decline later transactions and alert. Operations should examine whether this is:
- card/token compromise;
- merchant retry loop;
- legitimate micro-purchase pattern;
- technical duplication.
Fraud and technical teams should share evidence because both can produce rapid repetitive activity.
Settlement and treasury perspective
Although individual debit purchases are small relative to high-value payments, aggregate debit-card settlement can be material. Treasury and finance teams care about the net position arising from retail clearing.
The card product team should provide predictable reporting:
- gross issuer debit purchase value;
- refunds;
- reversals where financially relevant;
- clearing adjustments;
- net settlement position;
- reconciliation breaks.
Treasury should not need customer-level authorization data to manage aggregate liquidity, but finance must be able to drill from a settlement difference to the underlying clearing population.
General-ledger design
A simplified issuer accounting model can involve:
Authorization
May affect available balance without final GL posting, depending on bank design.
Clearing/posting
Debit customer deposit account
Credit card-clearing/control account
Settlement
Move between card-clearing/control and settlement accounts
Refund
Debit settlement/card-clearing as appropriate
Credit customer account
The exact entries vary by institution. What matters is that authorization holds, final postings, settlement and refunds do not collapse into one opaque account.
Suspense accounts should have:
- defined purpose;
- expected clearing time;
- owner;
- ageing;
- reconciliation;
- escalation.
A permanent “card difference” account is not a control.
The following figures are an illustrative fictional processor example, not a Canadian market statistic.
Merchant-side reconciliation example
A merchant processor may see:
- 10,000 successful debit sales;
- 120 refunds;
- 15 reversals/cancellations;
- fees;
- net merchant funding.
The merchant statement should reconcile transaction totals to funding. If a merchant says “your network short-paid me,” merchant support should compare capture, clearing and funding rather than send the case to issuer customer service.
Data lineage
For every field used in customer or merchant reporting, the bank should know its source.
Example:
Merchant name on statement
Source: network/acquirer merchant descriptor → transformation rules → statement display.
Transaction date
Source may differ between authorization time and clearing/posting date. The statement label should be intentional.
Debit-card channel indicator
Source: network transaction data → internal normalized channel.
Token indicator
Source: network/token service → internal card/token model.
Lineage matters when the customer says the statement descriptor is wrong or when fraud rules use a field differently from customer reporting.
Schema evolution
Network and clearing specifications change. Bank systems should version parsers and mappings rather than hard-code assumptions.
A safe change process includes:
- receive updated specification;
- impact analysis;
- mapping changes;
- regression tests;
- certification where required;
- parallel validation;
- controlled cutover;
- post-release monitoring.
A field added by the network should not silently disappear because the internal canonical model has nowhere to store it.
Canonical transaction model
A bank-wide card model can reduce complexity.
Core attributes might include:
- internal transaction ID;
- network transaction ID;
- card ID;
- token ID where applicable;
- account ID;
- merchant ID/descriptor;
- amount/currency;
- channel;
- authentication method;
- authorization status;
- clearing status;
- posting status;
- reversal status;
- refund relationships;
- dispute status;
- timestamps.
This model supports customer service, fraud and reconciliation without exposing raw network payloads everywhere.
Event-driven integration
Authorization systems are synchronous, but many downstream actions are naturally event-driven.
Events can include:
- AuthorizationApproved;
- AuthorizationDeclined;
- AuthorizationReversed;
- ClearingReceived;
- TransactionPosted;
- RefundReceived;
- DisputeOpened;
- CardBlocked;
- TokenSuspended.
Consumers of these events should be idempotent. A duplicated event must not create a second posting or customer notification.
Customer notifications
Real-time purchase notifications can improve fraud detection because customers recognize unauthorized activity quickly.
Notification design should consider:
- approved transaction;
- declined transaction;
- high-value transaction;
- refund posted;
- card/token provisioning;
- card block.
Notifications should not expose full card numbers or sensitive authentication data.
A notification is not the system of record. If push delivery fails, the underlying transaction remains valid.
Dispute case integration
The dispute platform should be integrated with transaction search. The agent should not re-key merchant, amount and date.
Opening a dispute should attach:
- transaction ID;
- customer/account;
- card/token;
- relevant authentication evidence;
- statement line;
- fraud signals.
This reduces manual error and speeds investigation.
Model-risk considerations in fraud
If machine-learning models contribute to debit authorization, governance should cover:
- training data;
- feature quality;
- drift;
- performance by segment;
- false positives;
- explainability appropriate to operations;
- override/governance process;
- fallback if model unavailable.
A model that reduces fraud loss but dramatically increases legitimate declines can harm customers and merchant acceptance. Product, fraud and model-risk teams should measure both sides.
Customer vulnerability and scam handling
Some unauthorized-looking debit transactions arise from scams where the customer participated under manipulation. The exact liability and recovery framework depends on circumstances and policy, but servicing should distinguish:
- credential theft;
- lost/stolen card;
- account takeover;
- coerced or manipulated customer action;
- merchant dispute.
The bank should avoid collapsing every case into “fraud” without classification.
End-to-end acceptance checklist
A release is ready only when:
- card state is synchronized;
- token state is synchronized;
- account availability is authoritative enough for the product;
- authorization meets latency target;
- timeout state is visible;
- duplicate/retry logic is proven;
- reversal restores availability;
- clearing matches authorization;
- unmatched clearing is controlled;
- settlement reconciles;
- refunds post once;
- disputes can be opened from transaction data;
- unauthorized claims have evidence workflow;
- consumer-protection language is approved;
- merchant Code complaint routing is defined;
- monitoring and alerts are active;
- rollback and outage procedures are tested.
This is the standard of a bank-grade Interac Debit implementation: not merely a transaction that approves at a terminal, but a service whose full lifecycle can be explained, reconciled and recovered.
Compliance boundary: AML/ATF, sanctions and technology resilience
AML/ATF and sanctions controls are overlays around card servicing and payment operations, not additional issuer authorization response codes. A bank should connect customer/account risk, transaction monitoring, sanctions escalation, investigation evidence and post-event controls to the canonical transaction ID. FINTRAC requires reporting entities to submit a Suspicious Transaction Report when a transaction or attempted transaction gives reasonable grounds to suspect money laundering or terrorist activity financing. That threshold is not a claim that every ordinary POS debit is reportable; the bank must apply the PCMLTFA and Regulations to the facts and must not tip off a client about a report. Sanctions-evasion escalation and reporting follow the applicable FINTRAC and sanctions framework. The exact screening vendor, rules, queues and interfaces are bank-specific.
For federally regulated financial institutions, OSFI Guideline B-13 is a technology and cyber-risk resilience overlay. It supports the outage, failover, incident-response, access-control, logging and recovery requirements described here; it does not define Interac message formats or replace Interac/Payments Canada rules.
RTR status and scope
This chapter describes production Interac Debit and ACSS-linked POS processing. It does not describe RTR as a production card rail. As of the audit date, the Bank of Canada describes RTR as a planned system being designed by Payments Canada; its settlement-account policy is for planned RTR direct participants. Do not substitute RTR ISO 20022 messages, 24/7 processing or RTR finality for current Interac Debit/ACSS behaviour. Any future RTR integration belongs in a separately versioned modernization chapter.
11. Practical Canadian examples
Example (fictional): grocery-store timeout
A customer taps for an $86 grocery purchase. The issuer approves, but the terminal loses connectivity before receiving the response. The cashier asks the customer to tap again, and the second attempt succeeds.
The customer later sees two debit-related entries. Operations finds two authorization attempts but only one completed clearing record. The first authorization is reversed or expires according to the processing path. The correct resolution comes from lifecycle evidence, not from crediting both entries immediately.
The lesson: merchant-terminal outcome, issuer authorization and clearing are separate facts.
Example (fictional): unauthorized mobile-wallet transactions
A customer reports a lost phone and denies three debit purchases made through a mobile wallet. The bank retrieves wallet-provisioning history, device signals, transaction timestamps and the customer’s report time.
The case is investigated under the bank’s unauthorized-transaction process. The presence of device authentication is evidence, but it does not remove the bank’s obligation to investigate.
Example (fictional): merchant refund
A merchant issues a refund for a returned jacket. The customer has the merchant receipt but does not see the credit.
Issuer operations traces the refund separately from the original purchase and finds that the refund reached the issuer but failed in the account-posting interface. The bank posts the credit and fixes the break. Asking the merchant to submit a second refund would have created a duplicate.
12. Key takeaways and authoritative references
Interac Debit is primarily a real-time issuer-authorization service, with distinct delayed-authorization paths and downstream clearing, settlement and merchant-funding processes. Authorization, clearing, settlement, reversal, refund and dispute are different events and should be represented separately in bank systems.
The issuer owns the customer-account decision. The acquirer/processor owns merchant acceptance and funding. Network services connect them. Payments Canada’s retail rules provide the applicable intermember clearing framework for eligible point-of-service items.
The operational rule is simple: preserve transaction identity across the whole lifecycle, investigate from evidence rather than assumptions, and reconcile authorization, clearing, settlement and posting every day.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.