How a Transaction Begins
The short answer: someone asks a system to move value, and that ask has to be packaged before anything else can happen. Here is the simple version first, then everything underneath it.
The simple answer
A transaction begins the moment someone signals intent to move money or data from one place to another. That signal might be a tap on a card reader, a button pressed in an app, a check written by hand, or a scheduled instruction set up weeks earlier. Whatever the trigger, the system on the receiving end treats it as a request, not yet a done deal.
At this stage nothing has actually moved. Think of it like handing a sealed envelope to a courier. The envelope exists and has been accepted for handling, but delivery, verification, and confirmation all come later. The beginning of a transaction is simply the point where that envelope gets sealed and handed over.
What actually gets created
Underneath the tap or the click, the system assembles a small bundle of information: who is asking, what account or instrument is involved, how much, to whom, and when. This bundle is often called a transaction request or a payment instruction, and it gets a unique reference number the moment it is created, even before anyone checks whether it should be allowed.
That reference number matters more than most people realize. It is how the request gets tracked across every system it touches afterward — the bank, the card network, the merchant's processor, the ledger. Lose that number and a transaction becomes very hard to trace, which is why receipts and confirmation screens usually display it prominently.
Who is involved at this first moment
Even a simple purchase usually involves more parties than the two people who think they are transacting. There is the originator, the person or device sending the request. There is the receiving system, which might be a bank, a payment app, or a point-of-sale terminal. And there is usually an intermediary — a card network, a clearing house, or a payment gateway — that will eventually carry the request between the two.
At the moment of creation, though, only the originator's own device or terminal is doing anything. It is capturing the details, formatting them into a structure the next system in line will recognize, and preparing to send them onward. Nothing has left the building yet, in a manner of speaking.
What varies between systems
Not every transaction starts the same way. A card swipe generates a request instantly and expects a response in seconds. A bank wire initiated online may sit in a queue until a batch window opens, sometimes hours later. A recurring subscription payment is triggered not by a person but by a calendar date, with no human action at all on the day it fires.
This is the detail people often miss: the word transaction covers wildly different mechanics depending on the rail it travels on. Card networks, automated clearing houses, real-time payment systems, and internal bank transfers each define the starting moment differently, even though from the customer's chair it all looks like pressing the same kind of button.
Common misunderstandings
A frequent assumption is that a transaction is complete once it has been initiated — that pressing send is the same as the money arriving. It is not. Initiation only creates the request; authentication, validation, processing, and settlement still have to happen, sometimes within seconds, sometimes over several business days.
Another common mix-up is treating a confirmation screen as proof that funds have moved. Often that screen only confirms the request was successfully created and accepted for processing, not that it has cleared. The distinction matters most when something later goes wrong and a person is trying to understand at which stage the failure occurred.
How different transactions get triggered
| Trigger type | Typical example | When it actually starts moving |
|---|---|---|
| Manual, real-time | Tapping a card or approving a transfer in an app | Immediately, request sent within seconds |
| Manual, scheduled | Setting up a future-dated bill payment | At creation, but not sent until the scheduled date |
| Automatic, recurring | A subscription charge or standing order | On a calendar trigger, with no human action that day |
| Batch-based | Payroll deposits or bulk supplier payments | Bundled together and released at a fixed processing window |
What people ask about the start of a transaction
Is a transaction reversible right after it begins?
Sometimes, briefly. Some systems allow a short window to cancel before the request leaves the originating device, but once it has been sent onward for authentication and processing, reversal usually requires a separate dispute or refund process rather than a simple cancel.
Why does a payment sometimes show as pending before anything is approved?
Pending status usually reflects that the request has been created and accepted for handling, but is still moving through authentication and validation. It is a record of intent, not a guarantee of outcome, which is why pending transactions can still fail.
Does the receiving party know a request exists as soon as it is created?
Not necessarily. Many systems only notify the receiving party once validation has occurred. The originator's device may show a request as sent well before any other party in the chain has been informed.
Can two transactions be created from the same action?
Occasionally, due to network retries or double submissions, a system may generate a duplicate request. Most modern systems include safeguards to detect and discard duplicates, but it is one reason unique reference numbers exist.
What is the difference between initiation and authorization?
Initiation is simply the creation of the request. Authorization is a later, separate step where the request is checked and approved to proceed. A request can be initiated and never authorized if it fails a check.
Why do some transactions take longer to even start than others?
Some systems process requests only in batches at set times, rather than continuously. A request created outside that window waits until the next batch runs, which can look like a delay even though nothing has gone wrong.