A step-by-step map of how digital transactions actually work

Starting with the first click, tap, or swipe

Every digital transaction begins with a request. That might be tapping a card at a terminal, approving a transfer in a banking app, or clicking pay on a checkout page. For someone doing this for the first time, the important thing to understand is that this first step is just a message being formed, not the transaction itself being completed. The request carries details such as the amount, the sender, the intended recipient, and a timestamp.

We walk through what happens on your screen versus what happens behind it, because the two are easy to confuse. The confirmation you see on your device is often just an acknowledgement that your request was received, not proof that money has actually changed hands. Understanding that distinction early makes the rest of the process much easier to follow.

How systems check it is really you

Before anything moves, most systems try to confirm that the person making the request is who they claim to be. This is authentication, and it can take several forms: a PIN, a password, a fingerprint, a one-time code sent by text, or a combination of these. We explain why some transactions ask for more than one of these steps and others do not, since the level of checking usually depends on the amount involved and the risk associated with the channel being used.

This section also covers what happens when authentication fails, which is one of the most common points of confusion for first-time users. A failed authentication is not the same as a failed transaction in a technical sense, but it produces the same result for the person trying to pay: nothing goes through, and a decision has to be made about what to try next.

Validation: the quiet checks nobody sees

Once identity is confirmed, the request passes through a series of checks that most people never see. Is there enough balance or available credit. Is the recipient account real and able to accept funds. Does the request look consistent with typical patterns, or does it resemble something that might be fraudulent. These checks happen quickly, often in under a second, but they involve multiple systems communicating with each other.

We describe this stage in plain terms, using examples like an interac e-Transfer between two Canadian bank accounts or a point-of-sale purchase, so readers can see how validation differs depending on the type of transaction and the institutions involved, without assuming every system works the same way.

Processing and the handoff between participants

A digital transaction usually involves more than two parties. There may be a bank, a card network, a payment processor, and the recipient's own financial institution, each playing a distinct role. This section explains who typically does what, using generic terms rather than naming specific companies, since the exact participants vary by country, by payment method, and by the size of the transaction.

We also cover timing here, because processing does not always happen instantly even when it appears to. Some transactions settle within seconds; others are provisionally approved right away but only fully settle hours or days later. Knowing this distinction helps explain why a balance might show as pending rather than final.

Confirmation and what a receipt actually means

After processing, both sides of a transaction usually receive some form of confirmation: a receipt, a notification, or an updated balance. This page explains what these confirmations actually guarantee and what they do not. A notification on your phone, for instance, tells you your bank has recorded the transaction on its side, but it may take longer for the other party's system to reflect the same update.

We also look at common formats of confirmation used in Canada, including email receipts, SMS alerts, and in-app transaction histories, so readers know what details to check when reviewing whether a payment went through as expected.

How records stay consistent across systems

Once a transaction is confirmed, it needs to be recorded in a way that both parties, and any intermediaries, agree on. This section explains, in accessible terms, how systems keep their records aligned even though they are operated independently. It covers reconciliation, the periodic process by which institutions compare their records to catch and correct discrepancies.

This is not a technical deep dive into any particular ledger technology. Instead, it focuses on what a reader needs to know practically: why a transaction might appear differently on two statements for a short time, and why that is usually normal rather than a sign of a problem.

Why transactions get delayed or declined

One of the most searched topics on this site is why a transaction did not go through, or why it took longer than expected. We cover the most common and mundane reasons: insufficient funds, a mismatched billing detail, a temporary network issue, a security hold, or a recipient's bank taking extra time to process an incoming transfer.

This section is written to be calming rather than alarming. Most delays and declines have ordinary explanations and are resolved by checking a few basic details or simply waiting. We also explain when it makes sense to contact your financial institution directly rather than trying to resend a request repeatedly.