Credit Card Payment Lifecycle. Follow a credit-card transaction through authorization, clearing, settlement, funding, disputes and reconciliation.
Block 10 · Chapter 48 of 75
A credit-card payment is easy to recognize at checkout but operationally very different from a debit-card payment. The cardholder is drawing on a credit facility provided by an issuer. The merchant is paid through an acquiring relationship. A payment-card network connects the issuer and acquirer, defines operating rules and carries authorization and clearing information. The cardholder’s statement, the merchant’s settlement report and the interbank settlement process are related, but they are not the same ledger or the same event.
This chapter follows a Canadian credit-card transaction from merchant initiation through real-time authorization, clearing, issuer posting, settlement, merchant funding, refunds, disputes and reconciliation. It also connects the operational lifecycle to Canadian merchant protections under the Code of Conduct for the Payment Card Industry in Canada. The exact network message formats, interchange tables and scheme rules are proprietary and change over time; this chapter stays at the functional level and points practitioners back to their network and processor documentation for implementation detail.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- identify the cardholder, issuer, merchant, acquirer/processor and card-network roles;
- distinguish authorization, capture, clearing, settlement, merchant funding and cardholder billing;
- explain authorization holds, incremental/final amounts and reversals at a functional level;
- trace a refund and distinguish it from a reversal or dispute;
- explain how issuer and acquirer reconciliation differ;
- describe fraud, authentication and transaction-risk controls;
- explain the difference between customer liability, network zero-liability commitments and a bank’s investigation obligations;
- describe merchant-facing protections under Canada’s payment-card Code of Conduct;
- investigate common cases such as duplicate charges, tips, pre-authorizations, cancelled hotel holds and delayed refunds;
- design a bank-grade test matrix covering happy paths, uncertain outcomes and reconciliation breaks.
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 examples and 5 minutes on takeaways and references.
Chapter navigator
- Business context and customer need
- Participants and responsibilities
- Authorization and capture
- Clearing, settlement and merchant funding
- Data, authentication and transaction identity
- Fees, service levels and customer impact
- Fraud, consumer protection and merchant rights
- Reversals, refunds, disputes and chargebacks
- Posting, accounting and reconciliation
- Implementation, testing and resilience
- Practical Canadian examples
- Key takeaways and authoritative references
1. Business context and customer need
A credit card separates purchase timing from repayment timing. The customer can buy now using a revolving or charge-credit facility, while the issuer later bills the customer according to the card agreement. The merchant receives value through the acquiring process rather than waiting for the cardholder to pay the issuer.
That creates three distinct commercial relationships:
- cardholder ↔ issuer;
- merchant ↔ acquirer/processor;
- issuer/acquirer ↔ network operating rules.
The customer normally experiences only the first. The merchant mainly sees the second. The network makes the transaction interoperable across institutions.
A bank operations team must therefore avoid statements such as “the merchant has been paid because the customer sees the charge” or “the cardholder owes the final amount because an authorization exists.” Authorization, clearing, merchant funding and cardholder billing can occur at different times and with different amounts.
2. Participants and responsibilities
The cardholder presents the card or digital credential and later repays the issuer.
The issuer provides the credit facility, authorizes transactions, applies fraud and credit controls, receives clearing, posts the cardholder account, handles billing and manages disputes.
The merchant initiates the purchase, captures the sale and provides goods or services.
The acquirer or payment processor supplies merchant acceptance, routes authorization, submits clearing and funds the merchant according to contract.
The payment-card network establishes the interoperable rules connecting issuers and acquirers. Major network operators in Canada include Visa, Mastercard, American Express, Discover, Interac and UnionPay, although not all serve the same product types.
FCAC publishes and explains the Code of Conduct for the Payment Card Industry in Canada. The Code applies to participating payment-card network operators and their participants, including issuers, acquirers, processors, payment facilitators and aggregators; it focuses on merchant transparency, flexibility, choice and complaint handling. [1]
3. Authorization and capture
A purchase starts when the merchant submits an authorization request. The issuer decides whether the transaction can proceed based on factors such as:
- card status;
- available credit;
- account restrictions;
- merchant and transaction context;
- authentication evidence;
- fraud scoring;
- velocity and behavioural patterns.
If approved, the issuer creates an authorization record and typically reduces available credit by the authorized amount. This does not yet mean final clearing has occurred.
Some merchant categories create special authorization patterns. Hotels and car-rental firms may place a pre-authorization before the final amount is known. Restaurants may authorize the base amount before gratuity. Fuel dispensers may use a temporary authorization amount. The later clearing amount can therefore differ within scheme rules from the initial authorization.
A capture tells the acquiring side that the merchant intends to complete the transaction. In integrated retail environments capture can be automatic; in other environments it may occur later or as part of end-of-day processing. If the sale is cancelled before capture or completion, the correct outcome may be an authorization reversal rather than a refund.
4. Clearing, settlement and merchant funding
After capture, the merchant/acquirer submits transaction data through the card-network clearing process. The issuer receives clearing details and converts the authorized transaction into a posted financial transaction on the card account.
The network calculates issuer and acquirer financial obligations according to its rules. Merchant funding then occurs according to the acquiring agreement, usually net of applicable fees and adjustments.
A practitioner should keep four clocks separate:
- authorization;
- capture/clearing;
- issuer posting;
- merchant funding/settlement.
A customer can therefore see a pending authorization that later disappears if the transaction is not captured. A merchant can have a successful authorization but still experience a later clearing exception. A posted customer charge can exist before merchant funding has completed.
5. Data, authentication and transaction identity
The functional data chain typically includes:
- card or token identity;
- merchant identity;
- terminal or e-commerce context;
- amount and currency;
- authorization reference;
- transaction/network identifiers;
- clearing reference;
- refund or dispute linkage.
The exact fields differ by network and processor. What matters to bank design is that each downstream event can be matched to the original authorization without relying only on date and amount.
Authentication can involve chip, PIN where relevant to a product, contactless cryptography, tokenized wallets, CVV/CVC, 3-D Secure or other e-commerce controls. Authentication is evidence, not proof of liability by itself.
6. Fees, service levels and customer impact
Credit-card economics include several fee layers: merchant service charges, interchange, network fees and cardholder pricing such as annual fees or interest. These are separate concepts and should not be mixed in product design.
The Code of Conduct for the Payment Card Industry in Canada requires important merchant-facing transparency. FCAC guidance notes that all major payment-card network operators in Canada have agreed to the Code and that it was revised in 2024. The Code supports clear disclosure, merchant choice and complaint handling.
Customer service should distinguish:
- pending authorization;
- posted purchase;
- reversed authorization;
- refund;
- disputed transaction;
- chargeback adjustment.
A common source of complaints is a pending authorization that remains visible after a merchant cancellation. The bank should explain that the authorization reduces available credit until it is reversed, expires or is replaced by clearing according to network and issuer rules.
7. Fraud, consumer protection and merchant rights
Credit-card fraud can involve stolen cards, account takeover, card-not-present misuse, credential theft, merchant compromise, synthetic identities and social engineering.
Controls include:
- card and token lifecycle management;
- real-time fraud scoring;
- e-commerce authentication;
- device and behavioural analytics;
- merchant-risk monitoring;
- velocity and geography checks;
- transaction alerts;
- card freeze/replacement;
- dispute and reimbursement workflows.
For a credit card issued in Canada, the Bank Act caps borrower liability for unauthorized use at $50 unless the borrower demonstrated gross negligence (or, in Quebec, gross fault) in safeguarding the card, account information or personal authentication information. Reporting loss or theft stops liability for unauthorized use after the report is received, and use of personal authentication information does not by itself establish gross negligence or gross fault. [2] FCAC also states that federally regulated financial institutions must investigate an unauthorized-transaction report and consider all relevant factors; authentication technology alone is not enough to find the customer at fault. [3]
For merchants, the Code of Conduct focuses on transparency, choice and complaint handling. Merchant disputes about processor pricing or Code obligations are not the same as cardholder disputes about a purchase.
8. Reversals, refunds, disputes and chargebacks
A reversal typically cancels or releases a prior authorization before or instead of final clearing.
A refund is a merchant-initiated credit after a completed purchase.
A dispute is a cardholder claim that the transaction is unauthorized, incorrect or otherwise eligible for investigation under the card agreement and network rules.
A chargeback is a network-governed financial adjustment process between issuer and acquirer. It is not a generic synonym for every customer complaint.
Common operational cases
Duplicate charge. Determine whether there are two authorizations, two clearings, or one authorization and one final posting.
Hotel hold remains after checkout. Check final clearing and reversal/expiry of the pre-authorization.
Restaurant amount differs. Compare original authorization, tip handling and final clearing.
Refund not received. Trace the refund as a new credit transaction linked to the purchase.
Customer denies purchase. Open a dispute and gather authentication, merchant, device and network evidence.
9. Posting, accounting and reconciliation
Issuer reconciliation should join:
- authorization to clearing;
- clearing to cardholder posting;
- cardholder posting to network settlement;
- refunds/reversals to originals;
- dispute adjustments to the correct transaction.
Acquirer reconciliation joins:
- merchant capture;
- network clearing;
- network settlement;
- merchant funding;
- fees;
- refunds;
- chargeback adjustments.
Useful exception queues include:
- authorized not cleared;
- cleared without matched authorization;
- duplicate clearing;
- settlement mismatch;
- unmatched refund;
- chargeback unmatched to original;
- merchant-funding difference.
Each queue should have an owner, ageing and service target.
10. Implementation, testing and resilience
A credit-card platform typically includes card management, credit-line management, authorization switching, fraud services, network connectivity, clearing, settlement, billing, collections, disputes and digital-wallet services.
Testing should cover:
- approval and decline;
- insufficient available credit;
- blocked card;
- fraud decline;
- chip/contactless/e-commerce;
- pre-authorization;
- incremental authorization where supported;
- cancellation and reversal;
- clearing with same and different final amount;
- duplicate retry;
- refund;
- dispute;
- chargeback;
- settlement mismatch;
- statement generation.
Resilience testing should include network timeout and issuer failover. Duplicate prevention and idempotency are essential when replaying uncertain transactions.
Deep dive: why authorization, capture and clearing must stay separate
Credit cards are especially prone to terminology problems because the customer, merchant and bank can all use the word “charge” for different events. A bank-grade operating model gives each event its own meaning.
Authorization is the issuer’s real-time permission for the transaction to proceed. It normally reduces available credit or creates a pending authorization state.
Capture is the merchant/acquirer’s indication that the merchant intends to complete the transaction.
Clearing is the financial presentation of the completed transaction through the card network to the issuer.
Issuer posting converts the completed transaction into a posted item on the cardholder account.
Settlement resolves the financial obligation between the issuer/acquirer sides under network arrangements.
Merchant funding is the commercial payment from the acquirer/processor to the merchant according to the merchant agreement.
Billing presents the cardholder’s posted transactions and other account activity on a statement.
Those events can occur on different dates and with different amounts. The most familiar example is a hotel. A hotel may authorize a deposit or estimated amount at check-in, update it during the stay and submit a final clearing amount at checkout. The cardholder may see a large pending authorization, then a smaller final posted charge. That is not necessarily a duplicate.
Credit-line and available-credit logic
The issuer authorization platform must understand the cardholder’s available credit.
A simplified calculation can include:
credit limit
minus posted outstanding balance
minus pending authorized amounts
plus eligible payments/credits according to posting policy
plus/minus account-specific adjustments
The exact calculation belongs to the issuer’s product and credit platform. What matters operationally is that the authorization platform and card-account platform agree.
A synchronization defect can cause:
- false declines even though the cardholder paid the bill;
- over-authorization beyond intended availability;
- stale holds after reversal;
- inconsistent balance shown in mobile banking.
The issuer should therefore define an authoritative available-credit service or a controlled synchronization model with measurable lag and reconciliation.
Authorization controls
A credit-card authorization decision can consider:
- card status;
- account status;
- credit availability;
- cash-advance or purchase limits;
- merchant category;
- country;
- transaction type;
- authentication evidence;
- token/device context;
- velocity;
- fraud risk;
- regulatory or internal restrictions.
The issuer should separate a credit decision from a fraud decision internally even if both produce decline. That supports analytics and customer servicing.
Pre-authorizations
Some merchant categories need an estimate because the final amount is unknown at the moment of service.
Common examples include:
- hotels;
- car rental;
- fuel dispensers;
- some restaurants/tipping contexts.
A pre-authorization can reduce available credit before final clearing. The merchant may later submit a final amount and release unused authorization.
Customer-service tooling should show:
- original authorization amount;
- current open amount;
- final clearing amount;
- reversal/release status.
Without this view, agents can misclassify normal hotel behaviour as duplicate billing.
Incremental authorization
In some card-network use cases, merchants can request additional authorization as the expected transaction increases.
From the issuer perspective, incremental authorization must remain linked to the original transaction context. The available-credit impact should reflect the authorized total correctly rather than stacking independent holds incorrectly.
The exact network rules are proprietary/current-rule dependent, so implementation must follow the specific network documentation.
Partial approval and special cases
Some payment products support partial approvals or other specialized flows. A bank should not assume a universal behaviour across networks and card types.
The requirement should be written as:
The issuer must support only those response and completion behaviours permitted by the current network specification and certified processor implementation for the product.
This prevents a generic card model from inventing capabilities.
Card-present versus card-not-present
Fraud and authentication differ by channel.
Card-present
- chip;
- contactless;
- tokenized wallet at terminal;
- physical terminal risk.
Card-not-present
- e-commerce;
- stored credential;
- digital wallet checkout;
- recurring merchant payment.
The issuer should normalize channel while preserving detailed evidence needed by fraud/disputes.
Tokenization and wallet provisioning
Tokenized mobile wallets create a credential different from the physical card number.
The lifecycle includes:
- token request;
- customer/card eligibility;
- identity verification;
- token provisioning;
- activation;
- transaction use;
- suspension;
- deletion;
- card replacement/account closure handling.
A fraudulent token provisioning event can lead to later transactions that appear strongly authenticated at the device. Fraud controls therefore need to link token-creation context to transaction risk.
Stored credentials and recurring transactions
Many credit-card payments are recurring or use a merchant-stored credential.
The issuer needs to recognize the appropriate transaction indicators according to network rules, while customer-service systems should help customers distinguish:
- subscription;
- installment;
- one-off e-commerce purchase;
- merchant-initiated recurring payment.
A customer saying “I cancelled this subscription” is not the same as saying “I never made this purchase.” Dispute categorization matters.
Clearing matching
When clearing arrives, the issuer attempts to relate it to the authorization.
Matching should use the network identifiers supplied by the scheme/processor plus controlled comparison of merchant, amount, date and transaction context.
Exception categories include:
- cleared, authorization matched;
- cleared, no authorization found;
- authorization open, no clearing;
- final amount differs;
- duplicate clearing;
- late clearing.
These categories drive both accounting and disputes.
Authorization expiry
A pending authorization cannot remain forever. The network/issuer rules define how open authorizations expire or are released.
The bank should avoid hard-coding a single expiry time across all merchant types. Hotels and other delayed-completion merchants can behave differently from normal retail.
Servicing should display an expected release window derived from the product rules rather than promise a generic date if not justified.
Merchant descriptors
The merchant descriptor shown on the cardholder statement often drives dispute volume.
Data quality problems include:
- legal name different from store brand;
- payment facilitator name instead of merchant;
- truncated descriptor;
- foreign city despite online purchase;
- unclear subscription name.
Issuers should preserve raw network merchant data and apply customer-friendly display rules carefully. If a descriptor is transformed, the lineage should be auditable.
Interchange, merchant service charge and network fees
These terms are related but not interchangeable.
Interchange is generally the network-governed amount transferred between acquiring and issuing sides for eligible transactions according to network rules.
Network fees are fees charged under the network model.
Merchant service charge is the merchant-facing price charged by the acquirer/processor, which can incorporate interchange, network and processor components.
A cardholder’s interest or annual fee is a different issuer-customer pricing relationship.
The Canadian Code of Conduct places strong emphasis on transparent merchant disclosure and choice. Product teams should not simplify all merchant cost into “interchange.”
Merchant settlement statement
A useful merchant settlement view can include:
- sales count/value;
- refunds;
- adjustments;
- chargebacks;
- fees;
- net deposit;
- settlement date.
Merchant support should be able to drill from the net funding amount to transaction populations.
Chargeback lifecycle at a functional level
Chargeback processes are network-specific, but a common functional pattern is:
- cardholder raises dispute;
- issuer validates eligibility/evidence;
- issuer raises network dispute/chargeback where applicable;
- acquirer/merchant receives case;
- merchant can accept or respond with evidence;
- network rules determine next steps;
- financial adjustments occur;
- cardholder account is finalized.
Not every dispute becomes a chargeback, and not every chargeback is final at the first stage.
A bank should preserve every financial adjustment separately rather than overwrite the original purchase.
Temporary/provisional credit
Issuers may provide temporary credit during a dispute according to law, policy or network requirements.
Temporary credit needs lifecycle:
- created;
- available/posted;
- final reimbursement;
- reversed if claim denied;
- statement description;
- customer communication.
Otherwise, final case closure can produce double credit or an unexpected debit.
Unauthorized transaction evidence
A credit-card fraud investigation should gather:
Account/card
- card status;
- token status;
- recent replacement;
- address/contact changes;
- password reset;
- prior fraud.
Transaction
- merchant;
- channel;
- amount;
- authentication;
- network data;
- authorization;
- clearing.
Customer statement
- customer account of events;
- possession of card/device;
- travel;
- when discovered;
- relationship with merchant.
Security
- wallet provisioning;
- device history;
- e-commerce authentication where available;
- failed authorization attempts;
- fraud-alert responses.
The decision should be explainable and documented.
Credit card payments by the cardholder
There is another “credit-card payment” meaning: the cardholder paying the card account balance. That payment is not the purchase lifecycle described in this chapter. It can arrive through bill payment, internal transfer, AFT or other channels.
Architecture should therefore avoid ambiguous object names such as CardPayment when one system means “purchase” and another means “card-account repayment.”
A card-account payment affects:
- outstanding balance;
- available credit;
- interest calculation according to product rules;
- statement/accounting;
- collections status.
Statement cycle
The issuer statement groups posted activity over a billing period.
Important elements include:
- opening balance;
- purchases;
- cash advances;
- fees;
- interest;
- credits/refunds;
- payments;
- closing balance;
- minimum payment;
- due date.
Pending authorizations normally belong to a different view from posted statement transactions.
Customer channels should make the difference clear.
Interest and purchase transaction timing
Interest treatment is product-specific and governed by the cardholder agreement and applicable law. Payments operations should not infer interest outcome purely from network settlement date.
The card platform should provide posted transaction date and amount to the account/billing engine, which applies the product’s interest logic.
Fraud versus merchant dispute
A customer may recognize the merchant but dispute quality or cancellation. That is not necessarily fraud.
Useful categories include:
- unauthorized;
- duplicate;
- incorrect amount;
- merchandise/service issue;
- refund not processed;
- recurring charge after cancellation;
- cash not received;
- other network-defined reason.
Correct categorization determines evidence and process.
Cash advances
Credit cards can support cash advances through ABMs or other channels. These can have different pricing, limits and interest treatment from purchases.
The authorization and posting model should identify transaction type explicitly.
A customer complaint about a cash advance requires cash-dispense evidence in addition to card/network evidence.
Foreign currency
A Canadian cardholder can make purchases in foreign currency.
The lifecycle then includes:
- transaction currency;
- network/issuer conversion arrangement;
- posted Canadian-dollar amount;
- applicable FX rate/fee under card agreement;
- refund FX handling.
This chapter does not set rates. The control point is transparency and correct mapping of original currency to posted amount.
Offline and contingency behaviour
Card networks can support various contingency behaviours depending on product and terminal/network rules. The issuer must understand exactly what can occur when it is unavailable.
If a transaction is completed under a contingency rule without the normal real-time issuer decision, later clearing still needs correct posting and risk handling.
Operational training should not assume every posted card transaction necessarily had an online issuer approval.
Settlement reconciliation
Issuer finance should reconcile:
- clearing files/messages;
- network settlement reports;
- settlement account movement;
- card-account postings;
- refunds;
- chargeback adjustments.
Acquirer finance performs a parallel reconciliation to merchant funding.
Differences should be classified:
- missing clearing file;
- duplicate file;
- network adjustment;
- FX difference where applicable;
- chargeback;
- posting failure;
- settlement interface problem.
Ledger model
A simplified issuer model can use:
Authorization hold — off-ledger/memo or dedicated pending representation.
Purchase clearing
Debit cardholder receivable
Credit network settlement/control
Network settlement
Debit/credit settlement/control according to net position
Offset settlement account
Refund
Debit network settlement/control
Credit cardholder receivable
Cardholder repayment
Debit deposit/cash/receiving account path
Credit cardholder receivable
Exact entries vary; separation is the key.
Delinquency and collections linkage
If cardholder payments are missed, the credit-card account can enter delinquency/collections processes. Purchase transaction processing continues to need consistent account status.
Authorization may be restricted or blocked based on collections status.
The card switch should consume a clear account-status signal rather than duplicate collections logic.
BA requirements for statement consistency
Given a transaction is in pending authorization state, it must not appear in the posted statement population.
Given final clearing posts, the posted transaction should reference the appropriate merchant and amount while the pending authorization is released according to issuer logic.
Given a refund posts after statement generation, it appears in the next relevant account activity/statement period according to the issuer product rules.
BA requirements for pre-authorization
Given a hotel authorizes $800 and later clears $620 under valid network rules, the issuer must release/adjust the remaining authorization impact and post only the valid final clearing amount, preserving traceability between authorization and clearing.
Given the merchant cancels and sends a valid reversal, the issuer must release the open authorization exactly once.
BA requirements for duplicate clearing
Given two identical clearing records with duplicate network identity are received, the clearing processor must not post the cardholder receivable twice and must route the duplicate according to network/operations procedures.
Testing matrix
Card state
- active;
- blocked;
- expired;
- replacement;
- tokenized.
Credit state
- ample credit;
- near limit;
- over limit;
- collections restriction.
Channel
- chip;
- contactless;
- mobile wallet;
- e-commerce;
- recurring;
- cash advance.
Authorization
- approve;
- decline;
- timeout;
- duplicate;
- reversal.
Completion
- exact clearing;
- different permitted final amount;
- clearing without authorization;
- duplicate clearing;
- no clearing.
Post-purchase
- full refund;
- partial refund;
- multiple partial refunds;
- dispute;
- temporary credit;
- chargeback adjustment.
Billing
- statement cutoff;
- payment received;
- late payment;
- interest/fee event under test product configuration.
Performance and resilience
Authorization is latency-sensitive. Clearing and billing are throughput-sensitive. Disputes are workflow/evidence-sensitive.
Each subsystem therefore needs different resilience measures.
Authorization:
- active-active or equivalent high availability;
- dependency timeouts;
- low latency;
- durable decision log.
Clearing:
- replay-safe file/message ingestion;
- batch completeness;
- duplicate detection;
- restart checkpoints.
Billing:
- cycle completeness;
- restartability;
- statement reconciliation.
Disputes:
- case durability;
- evidence retention;
- financial-adjustment integrity.
Production monitoring
Product/operations dashboards should include:
- authorization volume/value;
- approval rate;
- technical decline rate;
- fraud decline rate;
- p95/p99 latency;
- open authorization ageing;
- unmatched clearing;
- duplicate clearing;
- refund volume;
- dispute volume;
- chargeback loss;
- settlement breaks;
- statement-generation exceptions;
- customer complaint themes.
Merchant Code implementation view
The Canadian Code of Conduct is not merely a legal PDF for compliance. Acquiring/product teams need to translate it into controls.
Examples:
- merchant application includes required disclosures;
- merchant agreement stores current terms;
- fee-change notices are generated in the required timing window where applicable;
- merchant cancellation rights are supported;
- complaint-handling process is clear and accessible;
- network/card acceptance choices follow Code requirements;
- device/card provisioning choices are respected.
Most revised Code elements took effect on October 30, 2024; the remaining elements took effect on April 30, 2025. Merchant-acquiring controls should therefore use the current Code, not the 2015 version. [1]
Product analytics and economics
A product owner should connect operational quality with economics.
Metrics can include:
- purchase volume/value;
- active cards;
- spend per active;
- interchange revenue where relevant;
- fraud loss;
- dispute cost;
- chargeback loss;
- authorization false declines;
- customer attrition after declines;
- merchant acceptance complaints.
A high approval rate is not automatically good if fraud losses surge. A very low fraud rate is not automatically good if legitimate customers are routinely declined. Optimization is multi-objective.
Card-network change management
Networks update operating rules, dispute rules, security standards and message specifications.
A bank should maintain:
- rule-change inventory;
- impacted systems;
- required certification;
- effective date;
- backward-compatibility plan;
- regression pack;
- customer/merchant communication if needed.
Changes should be traced from external rule to internal requirement to test evidence.
Incident example: stale authorization hold
A hotel sends final clearing and the issuer posts it, but the original pre-authorization remains open because the matching service fails.
The customer sees reduced available credit beyond the posted debt.
Reconciliation detects a clearing matched to an authorization whose hold was not released. Operations releases it through controlled repair.
The root-cause fix is matching/hold-release logic, not a manual credit.
Incident example: duplicate clearing file
A clearing file is processed successfully, but acknowledgement to the upstream system is lost. The file is resent.
If ingestion is not idempotent, thousands of customers can be posted twice.
The clearing processor must use file and item identity to detect replay. Recovery should return the prior processing result rather than post again.
Incident example: dispute credit mismatch
A temporary credit was applied when a dispute opened. Later the claim was approved and a permanent credit was posted, but the temporary credit was not converted/reconciled.
The customer receives double credit.
The dispute platform must represent temporary and final credit as linked states, not independent manual journal entries.
Practitioner design-review checklist
Before approving a credit-card platform, ask:
- Can available credit be explained and reconciled?
- Can a pending authorization be linked to final clearing?
- Are pre-authorizations and final amounts handled correctly?
- Are token and physical card states independent?
- Are stored credentials/recurring transactions identified?
- Can customer service see authorization, reversal, clearing, refund and dispute in one journey?
- Can duplicate clearing be blocked?
- Is refund a separate credit?
- Is temporary dispute credit controlled?
- Are merchant descriptors traceable?
- Are foreign-currency details preserved?
- Is cash advance distinguished from purchase?
- Are network settlement and cardholder posting reconciled independently?
- Is the Merchant Code implemented in acquiring processes?
- Are network-rule changes governed?
- Can every financial adjustment be linked to its case/original?
- Does failover preserve authorization identity?
- Is clearing replay-safe?
- Are customer statements reconciled to posted accounts?
That is the difference between a card processor and a complete issuing/acquiring operating model.
Canadian operating boundary and evidence labels
This is a card-network transaction, not an ACSS, Lynx or RTR payment. The Bank of Canada describes exchange, clearing and settlement as separate processes and lists VisaNet and Mastercard’s Global Clearing Management System/Single Message System among the payment systems it oversees; it separately identifies ACSS as the system that clears cheques, pre-authorized debits, direct deposits and Interac debit items. [4] Payments Canada owns and operates ACSS, Lynx and the RTR programme, but that does not make a credit-card authorization an ACSS or RTR message. [5]
Use these labels throughout requirements and training:
- Regulatory rule — statute, regulation, FCAC Code or supervisory guidance. The Bank Act liability rule and the Canadian Payment Card Industry Code are examples.
- Scheme rule — a Visa, Mastercard, American Express, Discover, Interac or UnionPay operating rule. The network and product must be named; no single card rule should be presented as universal.
- Bank/processor implementation — issuer, acquirer, gateway or processor choices such as hold ageing, posting date, fraud score, retry policy, settlement-account mapping and merchant funding timing.
- Fictional example — the Montreal/Vancouver hotel and restaurant scenarios below illustrate control logic only; their amounts and dates are not regulatory limits.
Current RTR status
The RTR is a separate account-to-account payment system. Payments Canada currently describes it as launching in Q4 2026 and reports industry solution-assurance testing and rule publication activity. [6] Until Payments Canada declares production availability for the relevant participant and service, this chapter treats RTR as planned/under implementation, not as a production replacement for card authorization, clearing or dispute processing. Payments Canada’s public API catalogue includes ACSS, Lynx and sandbox RTR APIs; those APIs are not a universal card-network API. [7]
Implementation depth: channels, interfaces and ownership
| Layer | Production concern | Evidence/contract boundary |
|---|
| Customer and merchant channels | POS chip/contactless, mobile wallet token, e-commerce, mail/telephone order, recurring/stored credential, ABM cash advance | Merchant/acquirer agreement, terminal and gateway contract, scheme rules; do not infer channel behaviour from the card number alone |
| Acquirer/gateway | Merchant onboarding, MCC, terminal or gateway identity, amount/currency, token/PAN indicators, routing, authorization timeout, capture, refund and batch submission | Processor API and network certification are contractual; there is no public Canadian universal card API |
| Scheme messages | Authorization request/response, advice, reversal, completion/presentment, refund, dispute and settlement reports | Mastercard’s public rules use examples such as 0100/0110 authorization, 0400/0420 reversal and 1240 presentment; those identifiers are Mastercard examples, not a cross-network standard. [8] |
| Issuer services | Card/token status, available credit, fraud and authentication decision, hold ledger, clearing matcher, account posting, billing, disputes and customer servicing | Issuer product policy plus current scheme documentation; retain raw network data and a canonical internal event with idempotency key |
| Finance and operations | Network position/report, settlement-account movement, card subledger/GL, merchant funding, fees, refunds, chargebacks, suspense and aged exceptions | Network settlement report, processor report, bank ledger and independent reconciliation; merchant funding is not the same event as scheme settlement |
A minimum canonical identity should preserve the network transaction identifier, authorization code/reference, retrieval or linkage data supplied by the scheme, merchant/acquirer identifiers, token/PAN reference, amount/currency, event type, event time, clearing/presentment reference and dispute/refund linkage. Matching may use controlled amount/date/merchant fallbacks, but date and amount alone must not be the primary key.
A retry after a timeout must be safe in both the gateway and issuer. Persist the decision before returning the response where the design permits, deduplicate by source file and item identity, and make reversal, refund, posting and dispute adjustments independently idempotent. A “successful API call” is not a financial control unless the corresponding ledger and reconciliation evidence exists.
Cutoffs, cycles, settlement accounts and liquidity
There is no single Canadian card cut-off, hold expiry, presentment window, settlement cycle or merchant-funding SLA that applies to every network, product, channel and acquirer. The processor must load the current network/product calendar and contract configuration rather than hard-code a generic “end of day.” Issuer and acquirer operations should separately monitor authorization availability, clearing completeness, settlement position, merchant funding and statement cutoff.
The public Mastercard Transaction Processing Rules provide useful scheme-specific examples: an acquirer reversal is generally sent within 24 hours of cancellation or finalization below the approved amount; an issuer must release the matched hold within 60 minutes of receiving and matching the reversal; and a dual-message refund that is not reversed must be presented for clearing within five days. Regional, product and exception provisions apply, so these values must not be copied to Visa or another network without current rule confirmation. [8]
For settlement control, the issuer or acquirer should reconcile, by business date and currency:
- accepted authorization and capture populations;
- clearing/presentment files or messages received and acknowledged;
- network net position and settlement report;
- movement in the designated settlement or nostro/control account;
- card-account postings or merchant funding;
- fees, interchange/wholesale discount, FX and network adjustments;
- refunds, reversals, disputes and chargebacks.
Treasury should forecast the network’s net debit/credit position, prefund or collateral requirements where the arrangement requires them, and escalation for a failed settlement-account movement. A card network’s settlement arrangement is not automatically a Bank of Canada settlement account: direct participation, sponsored participation and correspondent arrangements must be documented for the particular scheme. Liquidity and operational risk remain even where the card processor is outsourced.
Returns, refunds, disputes and investigations
A reversal releases or adjusts an open authorization; it is not a credit for a completed purchase. A refund is a new merchant-initiated credit linked to the completed purchase. A cardholder dispute is an intake and eligibility workflow. A chargeback is a scheme financial process that may include representment and later stages. Each event needs its own immutable record and accounting entry.
For an unauthorized-transaction investigation, collect the customer statement, card/token status, provisioning and device evidence, channel and merchant data, authentication indicators, authorization and clearing references, prior replacement or contact changes, and any fraud-alert interaction. The decision must distinguish unauthorized use from a recognized purchase with a goods, service, amount, cancellation or refund complaint. Do not use a successful chip, CVV or 3-D Secure result as a legal conclusion about liability.
A bank-grade dispute case tracks reason/category, disputed amount, whole/partial status, evidence, deadlines, temporary credit, network case references, representment, final decision and every customer/merchant/GL adjustment. Temporary credit must be linked to the case and either converted to final credit or reversed once; it must not be recreated as an unrelated manual credit.
AML/ATF, sanctions and resilience boundaries
Canadian AML/ATF obligations depend on the entity and activity. FINTRAC states that financial entities, including Canadian banks, must maintain a compliance programme, conduct required identity and ongoing-monitoring measures, submit suspicious-transaction and listed-property reports, keep required records, and meet the applicable electronic-funds-transfer, 24-hour-rule and sanctions-evasion obligations. [9] A card authorization is not automatically an EFT report: the bank’s AML policy must determine which reportable activity, threshold and record rule is triggered.
FINTRAC requires reporting completed and attempted transactions where there are reasonable grounds to suspect sanctions-evasion offences, including activity involving sanctioned persons or entities. [10] Screening, hold/release, escalation, evidence retention and privacy controls should therefore exist at merchant onboarding, card/account servicing, authorization, clearing, refund and payout/funding points where the institution’s risk assessment requires them. Keep Canadian sanctions-law and FINTRAC reporting controls distinct from scheme fraud rules.
For federally regulated institutions, OSFI’s Operational Risk Management and Resilience Guideline expects senior-management accountability, documented critical operations and tolerances for disruption, scenario testing that includes critical third parties, and recovery/continuity planning. [11] A card processor, gateway, wallet-token service or dispute outsourcer may be a critical dependency; outsourcing does not transfer the issuer’s or acquirer’s accountability for customer, financial-control and regulatory outcomes.
Release and audit evidence
Before sign-off, retain one reconstructable sample for each of: normal card-present purchase, e-commerce or wallet purchase, pre-authorization with a different final amount, reversal, full and partial refund, duplicate-file replay, card-account repayment, dispute with temporary/final credit, and settlement reconciliation. For each sample, prove the network identity from authorization through clearing, posting, settlement/funding and any later adjustment. Also retain the relevant scheme rule/version, processor contract configuration, timestamps, operator actions and GL/control-account evidence.
The five diagrams in this chapter are intentionally functional. They retain role="img", aria-labelledby, a title and a description; they do not assert a universal network message format, timing or settlement account. Network-specific timing and message labels belong in the implementation contract and current scheme documentation, not in a generic diagram.
11. Practical Canadian examples
Example (fictional): hotel pre-authorization
A Montreal hotel places a fictional $600 pre-authorization at check-in and later presents a fictional $430 final amount. The customer may see a pending $600 and posted $430 while the issuer matches the final clearing and releases the unused hold. The amounts are illustrative, not a rule or limit.
Example (fictional): duplicate restaurant clearing
A restaurant’s batch submits the same captured sale twice. Operations distinguishes two clearings from one pending authorization, blocks duplicate replay by source/item identity, and routes the financial correction through the scheme and dispute/adjustment process. This is not automatically a fraud event.
Example (fictional): delayed refund
A retailer gives a refund receipt, but the issuer cannot find a posted credit. The investigation searches for the refund identity, checks acquirer/network delivery, checks issuer ingestion and suspense, and posts the received refund once if an internal queue failed. It does not ask for a second refund merely because the first is delayed.
12. Key takeaways and authoritative references
A Canadian credit-card purchase is a multi-stage scheme lifecycle. Authorization, capture, clearing, issuer posting, scheme settlement, merchant funding, billing, refund, dispute and chargeback are distinct events. The network and product must govern message formats, cutoffs, hold release, dispute windows and settlement arrangements. Canadian statutes and FCAC rules govern consumer liability and merchant protections; bank implementation determines account, fraud, reconciliation and operational controls.
Authoritative references
- [1] FCAC — Code of Conduct for the Payment Card Industry in Canada — scope, participants, disclosures and effective dates.
- [2] Justice Canada — Bank Act, s. 627.33 — unauthorized credit-card liability and reporting effect.
- [3] FCAC — Resolving an unauthorized transaction — investigation expectations and consumer responsibilities.
- [4] Bank of Canada — Payment systems the Bank of Canada oversees — exchange/clearing/settlement definitions, ACSS and designated card systems.
- [5] Payments Canada — Payment systems — Payments Canada systems and operating calendars.
- [6] Payments Canada — Real-Time Rail payment system — Q4 2026 launch statement and testing status.
- [7] Payments Canada — APIs — Payments Canada API catalogue and RTR sandbox boundary.
- [8] Mastercard — Transaction Processing Rules — scheme-specific authorization, reversal, refund and presentment examples.
- [9] FINTRAC — Financial entities — AML/ATF programme, reporting and recordkeeping obligations.
- [10] FINTRAC — Report suspected sanctions evasion — completed/attempted sanctions-evasion reporting.
- [11] OSFI — Operational Risk Management and Resilience Guideline — critical operations, third parties and scenario testing.
- [12] FCAC — Merchant rights under the Code — merchant disclosure, cancellation, choice and complaint rights.
- [13] FCAC — Merchant surcharges, service and convenience fees, and discounts — surcharge cap/disclosure and Quebec caveat.
- [14] Visa — Visa Rules and Policy — public rules boundary and VisaNet oversight disclosure.
- [15] Interac — Pay with Interac Debit — debit/account-linked service boundary; not a credit-card purchase rail.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.