Most payments move through a recognizable sequence: a request, an identity check, validations, processing, and a record on each side. The details differ by system. This site gives the short answer first, then the mechanics underneath for anyone who wants them.
An illustration only. Cut-off hours, batch runs and holiday calendars differ by institution and by system, so treat this as the shape of the effect rather than a schedule.
A digital transaction is a short conversation about a promise, followed later by an actual movement of money. When you tap a card or confirm a transfer in an app, nothing physically travels. A message leaves your device describing what you want: an amount, a destination, and enough information to show the request came from you. Somewhere along the line a party decides whether to stand behind that request. If it does, you see an approval within a second or two and the cashier hands you the coffee. The money itself may not leave your account until hours later, and may not reach the other institution until an overnight batch is settled. The speed you feel and the speed of the funds are two different clocks, and most confusion about digital payments comes from assuming they are one.
Underneath that single breath sit five recognisable stages, and nearly every system uses some version of them: initiation, authentication, validation, processing and recording. Initiation is the request being created. Authentication answers whether this really is the account holder or their registered device. Validation asks whether the request should be allowed at all — sufficient funds, within daily limits, not matching a known fraud pattern. Processing moves the value, or the claim on value, between institutions. Recording writes the event into ledgers on both sides so the two sets of books can be compared later. The order is fairly stable; the timing is not. In some systems every check finishes before you see a result. In others a request is accepted provisionally and examined afterwards, which is why a payment can appear to succeed on a Friday and reverse on the Monday.
A card tap at a grocery till usually involves at least five parties: you, the merchant, the merchant's payment processor, a network that routes the message, and the institution holding your account. A transfer between two people over a domestic transfer service has a different cast — your institution, a central switch, and the recipient's institution — and no merchant at all. A bill payment may end at a biller's own system that reads its incoming file once a day. Each party keeps its own rules, its own operating hours and its own definition of a completed transaction. So when something goes wrong, the useful question is rarely whether the payment worked. It is which of these parties currently holds the request, and what that party is waiting for before it passes it on.
This matters because the party you can actually talk to is usually not the party holding things up. Your own app can only report what it sent and what came back. It cannot see a receiving institution's internal review, a biller's batch schedule, or a merchant's decision to keep an authorisation open for several days on a fuel purchase or a hotel booking. That is why a support conversation almost always begins with a reference number: that string is the one detail every party in the chain can look up in its own records. Keeping it, together with the exact date, time and amount in CAD, turns a vague complaint into a traceable event. Without it, each party can only confirm that nothing obvious looks wrong on their own side, which resolves nothing.
The word instant does a lot of work in modern payments, and it usually describes the message rather than the money. Some systems are built to settle in real time, around the clock: the receiving account is credited within seconds, the funds are final, and there is no simple way to pull them back. Others authorise instantly but settle in batches, netting thousands of transactions between institutions at fixed points in the day. Others again — cheque-style clearing and pre-authorised file-based systems — run on schedules measured in business days and will not process anything on a weekend or a statutory holiday. Nothing on your screen distinguishes these three. The interface looks identical, while the underlying rail decides whether sent means gone, reserved, or simply queued for later.
Cut-off times are where this becomes concrete. Every batch-based system has an hour after which a request joins tomorrow's run instead of today's, and those hours are set by institutions rather than by statute, so they vary. A transfer submitted at 15:00 on a Thursday and one submitted at 19:00 the same day can land a full day apart; if the Friday is a holiday, three days apart. Provincial holidays complicate matters further, because a system may operate on a day that is a holiday in one province and an ordinary working day in another. This mechanism also explains the most common false alarm in everyday banking: money that has left one account and not yet appeared in the other is not missing. It is sitting in the gap between two clocks.
A confirmation screen is a statement by one party, about one step, at one moment. Approved on a card terminal means the issuing institution agreed to guarantee that amount to the merchant; it does not mean money has moved, and it does not mean the merchant has finished the sale. Sent in a transfer app means the request was accepted for processing. Completed in the recipient's app means their institution has credited their balance. Those are three different facts, produced by three different systems, and they can become true at different times or briefly disagree with each other. Reading the wording literally is the single most useful habit a payer can build. Where a confirmation is ambiguous, the accurate description is usually accepted — and acceptance is not the same thing as finality.
Records are how the parties eventually agree. Each institution writes the event into its own ledger with a timestamp, an amount and a set of identifiers, then compares its version against the others on a fixed cycle, a process generally called reconciliation. Most differences are ordinary and mechanical: an entry recorded on one side just before midnight and on the other just after, a hold that expired without ever being claimed, a refund travelling home along a slower path than the purchase took outbound. Reconciliation finds these and adjusts them. It is also why a statement is a more reliable account of events than a push notification: the notification describes an intention at the moment it was sent, while the statement describes what the ledgers finally settled on.
Usually not. The simple answer: your balance changed, so something happened. Underneath, most systems separate authorization from settlement. An authorization holds or earmarks funds and tells the merchant the request looks good. Settlement is the later movement of value between institutions, often overnight or on the next business day. That is why a pending line can change amount, disappear, or post days after you tapped.
The simple answer: the message travels faster than the money. Underneath, a request is routed, authenticated, checked against limits and risk rules, then queued for a clearing cycle. Some systems clear in near real time; others batch by cut-off window. Weekends, statutory holidays, and time zones across the country shift cut-offs, so a Friday evening request may not settle until the next business day.
Declined is an answer, not an error. The simple answer: one participant said no. Underneath, the no can come from the account holder's institution, an intermediary, or the receiving side, and the reason code travels back with it. Insufficient available funds, an expired credential, a per-transaction limit, a mismatched verification field, or a risk rule are all common. The wording you see is often a generic translation of a more specific code.
The simple answer: no. A confirmation screen reports that a request was accepted at that moment. A receipt is a record produced by one party describing what it believes occurred. Underneath, they can disagree. A screen may confirm an authorization that later reverses; a receipt may show a total that settles differently after a tip adjustment or currency conversion. Records reconcile later, which is why statements are the reference point.
No, and assuming they do is where most confusion starts. Card networks, account-to-account transfers, bill payment systems, and internal ledger movements inside one institution each have different participants, message formats, and timing. Some never leave a single institution's books. The broad sequence — initiate, authenticate, validate, process, record — is a useful map, but the number of parties and the length of each leg vary a great deal.
The simple answer: one of the two lines is usually a hold. Underneath, a pre-authorization at a fuel pump, hotel, or rental counter places an estimated amount, then the final amount posts separately when the merchant completes the sale. The hold drops off on its own timetable, which is set by the card issuer rather than the merchant. A genuine duplicate is possible, and reconciliation is what distinguishes the two.
No. This is an independent educational publication about how transaction systems work mechanically. We describe participants, message flows, checks, and record-keeping. We do not offer financial advice, do not recommend products or institutions, and have nothing for sale. For questions about a specific transaction on your own account, your institution holds the records and is the only party able to act on them.
| System type | Who is involved | How timing usually behaves |
|---|---|---|
| Card payment at a terminal or online | Cardholder, merchant, merchant's acquirer, card network, card issuer | Authorization answers in seconds; settlement between institutions typically follows in one to three business days, with amounts able to change before posting |
| Account-to-account transfer between institutions | Sender, sending institution, a clearing or messaging system, receiving institution | Ranges from near real time to the next clearing cycle; cut-off windows, weekends and statutory holidays extend it |
| Internal movement inside one institution | Account holder and a single institution's own ledger | Often immediate, because no external participant or clearing cycle is involved — only one set of books is updated |
| Scheduled bill or pre-authorized debit | Payer, biller or originator, both institutions, the originating schedule | Initiated on a set date rather than on demand; the debit may appear a day or more after the due date shown on a bill |
| Cross-border or multi-currency transfer | Sender, both institutions, one or more intermediaries, a conversion step | Longest and least uniform; each intermediary adds its own checks, and the converted amount is fixed at a rate applied somewhere along the chain |
| Stored-balance or wallet movement | Account holder, wallet operator, and the institution holding the underlying funds | Inside the wallet it can look instant; moving value out to a bank account re-enters one of the paths above and takes that path's time |
The simple answer is that you tap, click, or authorize. Underneath, a structured request is assembled: amount, currency, account references, a device or terminal identifier, a timestamp, and a unique reference that every later step will quote. This page follows that first message from the moment it is created to the moment another participant acknowledges receiving it.
Before anything is decided, systems try to establish that the requester is who the credential says. This page moves from the familiar — a PIN, a passcode, a one-time code — to the quieter layers: device fingerprints, cryptographic keys inside a chip or phone, and the difference between proving identity and proving permission to spend.
Authentication asks who. Validation asks whether. This page sets out the checks that stand between a request and an approval: available funds rather than balance, per-transaction and daily limits, account status, format and field validation, and risk signals that score a request against patterns. Any one of them can stop the sequence on its own.
An approval is a promise; settlement is the movement. This page traces what happens after the yes: routing through networks or clearing systems, batching and cut-off windows, the netting of many transactions between institutions, and why the amount on your screen and the amount finally exchanged between institutions are recorded at different moments.
Confirmations tell you a step succeeded, not necessarily that everything finished. This page separates the on-screen acknowledgement, the merchant's receipt, the notification from your institution, and the posted statement line — explaining what each one actually proves, who produced it, and which of them holds up when two records disagree.
Two companion pages cover what goes wrong and what keeps things straight. One walks through why transactions stall, bounce, or decline — reason codes, timeouts, limits, mismatched details. The other looks at ledgers, logs, and reconciliation: how each participant keeps its own record, and how those records are brought back into agreement.
Every page here opens with the plain version of what happens, then adds the detail beneath it. Pick the stage you are curious about, or write to us if something on the site reads unclearly.
