The short version, then everything underneath it

How a request gets started

The simple answer: a transaction begins the moment someone or something asks a system to move value or information from one place to another. That request can come from a tap on a card reader, a click in a banking app, or an automated instruction set to repeat on a schedule.

The detail underneath: the request itself is only a message. It carries an amount, a source, a destination, and a timestamp, but nothing happens until that message reaches a system capable of interpreting it. Different networks format this message differently — a debit card, an e-transfer, and a wire each package the same basic intent in distinct ways, which is one reason they behave differently when something goes wrong.

Authentication — proving it is really you

The simple answer: before a system acts on a request, it needs to confirm that whoever sent it has the right to do so. That might be a PIN, a fingerprint, a password, or a one-time code sent to a phone.

The detail underneath: authentication and authorization are related but not identical. Authentication confirms identity; authorization confirms that the authenticated party is allowed to do this specific thing, such as spend this amount from this account. Systems layer these checks — a card chip might authenticate the card itself, while a PIN authenticates the person holding it, and a spending limit set by the issuing bank authorizes or blocks the amount.

Validation — checking the request makes sense

The simple answer: once identity is confirmed, the system checks whether the request itself is workable — is there enough balance, is the account active, does the destination exist.

The detail underneath: validation happens in stages and often across more than one organization. A retailer's payment terminal checks basic formatting, the card network checks that the card is not reported lost, and the issuing bank checks the actual balance and any holds. A request can pass one stage and fail the next, which is why a card can be swiped successfully but still be declined moments later.

Processing — where the movement actually happens

The simple answer: after validation, the systems involved update their internal records to reflect that value or information has moved.

The detail underneath: this rarely happens instantly across every party at once. Many transactions are provisionally approved in real time — the merchant sees a green light — while the actual settlement between banks happens later, sometimes hours or days afterward, in a batch. This gap between approval and settlement is normal and is one reason a pending charge can still be reversed before it finalizes.

Confirmation and the record left behind

The simple answer: once processing completes, all parties receive some form of confirmation, and a record is stored so the transaction can be checked or disputed later.

The detail underneath: consistency matters here. Ideally, the merchant's record, the bank's ledger, and the customer's statement all agree on the amount, date, and outcome. Achieving that agreement across separate organizations, each keeping its own books, is a genuine technical challenge, and reconciliation processes exist specifically to catch and correct the moments where records briefly disagree.

Why transactions get delayed or declined

The simple answer: delays and declines usually come down to a mismatch somewhere in the chain — insufficient funds, a security flag, a formatting error, or a system that has not yet synced with another.

The detail underneath: some causes are mundane, like a card's expiry date not matching what the merchant has on file. Others are protective, like a bank temporarily pausing a transaction that looks unusual compared to someone's normal spending pattern. And some are structural — a transfer between two different networks or countries may simply require more intermediate steps, each adding time, before it can be confirmed.

Not every system works the same way

The simple answer: it is a mistake to assume all digital transactions follow one universal process.

The detail underneath: a domestic debit transaction, an international wire, and a cryptocurrency transfer each rely on different participants, different confirmation methods, and different timing expectations. A debit purchase might involve a card network, an issuing bank, and an acquiring bank. A wire might route through correspondent banks with no shared network at all. Treating these as interchangeable leads to confusion about why one moves in seconds and another takes days.