Digital Payments in India: The Options and How Each Settles

Pressing pay sends a message. The money itself moves later, when the two banks square up between themselves, and the route the payment took decides how long that takes and whether anything can be undone. Some routes finish in seconds. Some wait for a scheduled run. A cheque waits for the paper to be checked. Cash finishes the moment the notes change hands, and leaves nothing behind.

Here is what sits underneath that. Every payment is two separate things that feel like one. One is the instruction, a message saying who should be paid and how much. The other is the settlementThe moment the two banks actually square up between themselves, so that one holds less and the other holds more., the two banks actually shifting the money between each other. The instruction is quick. The settlement is slower, sometimes by a second and sometimes by days. Almost everything a household needs to know about paying, including every single thing about what can be stopped and what cannot, falls out of the space between those two events.

Seven ways of paying answer the same four questions differently: how fast each one settles, when it runs, what can be undone afterwards, and what record it leaves. One rule about a payment personal identification number (PIN) cuts across all seven and needs no judgement at all.

What actually happens between pressing pay and the money arriving?

Something easier to picture comes first. A customer hands a chit to the cashier at a busy sweet shop and the cashier calls the order through to the back. The call takes a second. The box of sweets takes ten minutes. Both are in plain sight, so nobody confuses the call with the box. On a phone only the call is ever visible.

Pressing pay sends an instruction from the payer's phone to the payer's bank. The paying bank checks that the account exists, that the money is there, and that whoever gave the instruction was entitled to give it. The instruction then travels onward, and at the far end the receiving bank credits the receiving account. Somewhere inside that sequence the two banks square up with each other, and that squaring up is the settlement.

Sent and arrived are two different words because they describe two different events, and a phone can only ever show the first of them. The difference is not a defect in the phone. The phone sits at the paying end of the chain, it has been told the instruction was accepted, and it says so honestly. The phone has no way of showing what the far end of the chain has done. So a payment can sit for a while in a state where the money has left one account and the other person cannot yet see it.

The waiting feels alarming the first time and it is completely ordinary. For the Bhosale household it happens every month on the 5th, when rent of Rs 14,000/- leaves the salary account. The screen says sent within a second or two. Whether the landlord sees it within seconds or later in the day depends on which route the instruction was handed to, and not at all on how much was paid or how badly it was needed on time.

How Digital Payments Work: who handles a payment, and what does each one do?

Four parties handle every payment, always in the same order, and a fifth person stands at the end and is handed the result. A parcel travelling from a shop in one lane to a cousin in another city works the same way. The sender gives it to the shop. The shop gives it to a van. The van takes it to a sorting depot. The depot gives it to a delivery rider at the other end. At every moment the parcel is in exactly one pair of hands, and the only useful question about whether it can still be pulled back is whose hands.

A payment runs the same way. The payer gives the instruction. The paying bank checks it, holds the money, and passes it on. The railOne of the routes a payment can travel along. Each rail has its own operator, its own rulebook and its own timing. carries it, keeps the record that lets the two banks square up afterwards, and decides nothing about whether the money was there. The receiving bank credits the account of the beneficiaryThe person or the account a payment is being sent to.. The rail is not a bank, holds nobody's account and never holds anybody's money for them; it is the road and the rulebook together.

A payment is handled by four parties in a fixed order, and every question about stopping, tracing or reversing a payment is really a question about which of the four is holding it at that moment. Once that is clear, a lot of confusing situations resolve themselves. A payment the paying bank has not yet released is in one pair of hands. A payment sitting with the rail waiting for a scheduled run is in another. A payment the receiving bank has already credited is in a third. At that point it is somebody else's money in somebody else's account, a very different situation from the first two even though the screen looked the same in all three.

Notice what is not on the list. The application on the phone is not one of the four. The application is a way of composing the instruction, in the same way that an envelope is a way of composing a letter, and it neither holds money nor settles anything. The answer to what happens when a payment goes wrong therefore almost never lies inside the application, and almost always lies with one of the two banks.

Which routes settle in seconds, and what does that cost?

The first group of routes is built to finish one payment at a time, on receipt, without waiting for anything. The instruction and the settlement land so close together that they feel like a single event. The closeness is exactly the point. Paying this way feels like handing over cash, and it was designed to feel like that. The address is an account number, or a short identifier that stands in for one, and the payment goes wherever that address points.

An immediate route gains finality within moments and gives up the space in which anything could have been changed. Because an immediate route closes the gap between instruction and settlement almost to nothing, no room is left in which to undo it. The absence of that room is not a flaw somebody forgot to fix. Speed and reversibility are the same space measured two ways, and no route can offer both.

One more thing about the address is worth holding on to. The rail sends the money to the account the address points at. The rail has no way of knowing who the payer had in mind. Checking that the account belongs to that person is no part of the rail's job. A name shown on the screen comes from the receiving bank's own record of that account, so it confirms which account the instruction points at and nothing more.

Which routes wait for a scheduled run instead?

The second group works in batchesGroups of payments processed together at a set time, rather than one at a time as each arrives.. Instructions are collected and processed together at set times published by the operator of the route, so a payment handed over between two runs waits for the next one. Picture a school bus. The bus leaves at a fixed time, arriving early makes no difference, and arriving a minute late means the next bus rather than a faster one.

From the household's point of view the waiting is not wasted. A batch run is the only window of its kind that a route itself provides. A batch route leaves a real gap between the instruction and the settlement, and inside that gap a payment may still be capable of being stopped. The immediate routes gave that possibility away in exchange for speed. Whether a given payment can actually be stopped is decided by the bank's own rules and by how far the run has got. The possibility exists. The answer for any one payment comes from the bank.

What is the route built for one large payment at a time?

The third group handles large payments one at a time. Rather than netting a pile of instructions off against each other and settling the difference, each payment is settled individually and in full, and once it has settled it is treated as final. The large-value route is used where finality is the whole point: buying a flat, settling with a builder, a business paying another business a sum that neither of them wants sitting in an uncertain state.

The large-value route trades away batching entirely. Every payment on it stands alone, and nothing about it waits for anybody else's payment to be ready. The route runs during a window its operator publishes. A household notices the practical difference: the immediate routes are designed to be available around the clock, and the large-value route is not. For the Bhosale household this route never comes up. Nothing they pay is large enough to need it.

Why does a card payment authorise now and settle later?

A card splits the two events further apart than any electronic route, and does it on purpose. When the card is used, the bank authorises the amount. Authorising means the bank agrees to pay and sets that money aside. The actual settlement happens afterwards, when the shop's own bank claims it. In between, the amount is visible on the cardholder's account as blocked or pending, and the shop has not been paid yet.

A card is the one route where the gap between instruction and settlement is deliberately held open, and that held-open gap is where the card dispute route lives. Because the shop is paid through a network of intermediaries rather than directly, there is a route back through those intermediaries. A chargebackA card dispute route in which a payment is reversed after it has settled, worked out between the banks and the card network rather than between the two people. is that route back: a formal process, run between the banks and the network, with its own rules and its own evidence. No other route on this list has anything like it. The difference is real and it is not a small one.

What is a standing mandate, and why is it a different shape?

Everything so far has been a push: the payer sends money out. A mandateA standing permission that allows somebody to collect an agreed amount from an account, rather than waiting to be sent it. is a pull. The permission is given once, and after that the other side collects on the agreed dates without anybody doing anything each month. The Bhosale household's two-wheeler instalment of Rs 3,150/- leaves the salary account on the 7th of every month this way, and nobody in the household touches a phone to make it happen.

A mandate reverses who starts the payment, so stopping it is a matter of ending the permission rather than of stopping any one payment. A collection that has already gone is a settled payment like any other and follows the rules of whatever route carried it. The permission itself, though, is a live thing that can be ended, and the place to end it is the bank that holds the account, not the person collecting. The two are routinely mistaken for one another. Holding them apart matters.

What is a cheque doing between the day it is written and the day the money moves?

A cheque is an instruction on paper. Handing it over transfers nothing at all. The instruction has to reach the receiving bank, be sent through clearingThe process by which a cheque is checked and the money is then moved between the two banks. to be checked against the paying account, and only then does the money move. The gap between handing over the paper and the money moving is the longest gap of any route here.

A cheque leaves the longest gap between instruction and settlement of any route on this list, and the length of that gap is why a cheque is the one payment that can still be stopped by the person who wrote it. The instruction to stop goes to the bank that holds the account, not to the person holding the paper. A stop instruction only works before clearing has finished. Whether a cheque can be stopped is therefore always a question about timing rather than about entitlement.

What does cash settle, and what does it leave behind?

Cash is the odd one out and it is worth stating plainly why. The handover is the instruction and the settlement at once. There is no gap between the two. No bank is involved. No rail is involved. The money is in one hand and then it is in the other, and that is the entire transaction.

Cash is the only payment where settlement is the handover itself, and settling that way makes it both the hardest of these routes to undo and the easiest to lose track of. Nothing can be stopped. There is no moment between the two events to reach into. And nothing is recorded anywhere, by anybody, unless a person chooses to write it down. When a customer at Ashok Bhosale's tailoring counter pays Rs 900/- in cash, the only record that will ever exist of that Rs 900/- is the line Ashok writes in his own book.

Seven ways of paying have now been described one at a time. Put them beside each other and read them across the same four questions. Reading them that way is the whole of understanding the choice. How fast does it settle, when does it run, what can be undone, and what record does it leave.

Read the grid once more and one relationship does all the work. The routes at the top settle almost instantly and can be undone by almost nothing. The routes lower down settle slowly and can be interrupted. Cash sits at the bottom of the first column and the bottom of the third at the same time, settling instantly and leaving nothing at all. Settling instantly while leaving nothing is what makes cash the strangest option on the list rather than the simplest.

The other way to see it is the same payment sent three ways at the same moment, with attention on when each one lands. The differences are not seconds. The gap is the difference between a payment that is done before the phone has been put down and one that is still in progress the following week.

Which payments can be undone, and which cannot?

Undoing a payment is not one thing, and treating it as one is what makes the answers seem arbitrary. Three separate questions are hiding inside it. Has the payment settled yet. Is there a route back that exists at all. And does somebody have to agree before that route can be used. A payment can fail the first test and still be recoverable, and it can pass every test and still take weeks.

The immediate route carries most payments now, and for a household it is therefore the most important case. Once it has settled, the money is in another person's account and it belongs to that account holder. The paying bank cannot simply reach in and take it out, and the reason is not unhelpfulness: a bank that could pull money back out of accounts on request would be a far worse bank to hold anybody's money in. Recovery therefore runs through the receiving person's agreement or through a formal process, and both of those take time.

Everything that can be undone is undone in the gap between the instruction and the settlement, and the fastest routes have almost no gap at all. Speed and reversibility therefore pull against each other. The same trade-off predicts every row of the drawing below. The card looks like an exception and is not. A card payment is carried by a network of intermediaries who can be instructed to unwind it, and instructing an intermediary is a different thing from a bank reaching into an account.

Which way does the money go when a request appears on a phone?

Every payment has a shape, and there are only two. In a push, the account holder starts it and money goes out of that account. In a pull, somebody else starts it, asks the account holder to agree, and money goes out of that same account once the agreement is given. Both shapes end the same way.

A collect requestA request that arrives on a phone asking the person receiving it to send money out. is a pull. The request arrives on the phone of the person who would be paying, carries an amount and a short note written by whoever sent it, and asks to be approved. Approving it moves money out of the account of the person who approved it. There is no version of it that moves money in.

A collect request asks the person looking at it to pay, so approving one sends money out of their account. Somebody expecting a payment reads the screen as the exact opposite. The difficulty is not complexity. A request and a receipt can carry the same amount to the rupee, the same note, and arrive in the same second, and the only thing separating them is a direction that the screen states once, quietly, in the middle of a busy moment.

Take Ashok Bhosale's counter. A customer collects an order worth Rs 1,450/-, says the money has been sent, and a screen appears on Ashok's phone a second later carrying Rs 1,450/- and the note payment for order. If it is a confirmation, the counter's balance goes from Rs 12,400/- to Rs 13,850/-. If it is a request and it is approved, the counter's balance goes from Rs 12,400/- to Rs 10,950/-. The two outcomes are Rs 2,900/- apart, on identical screens, at the same moment, for the same order.

The three stops read like this. At the first stop the payment arrives and the customer pays: the customer falls from Rs 8,000/- to Rs 6,550/-, the counter rises from Rs 12,400/- to Rs 13,850/-, and nobody at the counter is asked for anything at all. At the second stop the request is sitting unanswered: both balances are exactly where they started and a PIN field is showing. At the third stop the request has been approved: the counter falls from Rs 12,400/- to Rs 10,950/- and the customer rises to Rs 9,450/-. The counter's balance moves in opposite directions at the first and third stops, by the same Rs 1,450/-, on screens that carry the same amount and the same note.

When is a payment PIN ever needed to receive money?

Never. Not once, on any route, in any application, for any amount. The rule needs no judgement at all, and it survives a busy moment intact.

The mechanism behind it is simple enough to hold. A payment PINThe number that authorises money to leave an account. It is entered by the person paying, never by the person being paid. is the proof a bank requires before it will take money out of an account. The number answers exactly one question. Is the person giving this instruction entitled to give it? Money arriving needs no such proof from the account holder. Nothing is leaving that account, and no bank needs permission to make a balance larger.

Entering a payment PIN always sends money out of the account and never brings money into it. The rule follows from the mechanism, it holds on every route above, and it does not depend on noticing anything subtle. If a screen is asking for a PIN while money is supposed to be arriving, the screen and the situation disagree with each other, and the screen is the one telling the truth about what is about to happen.

How to Recognise Digital Payment Fraud: which signals live in the payment itself?

Four signals live inside the payment mechanism itself. How somebody is approached, what story is told, and what happens afterwards are covered separately. The four in the mechanism can be checked without knowing anything about the person on the other side.

The first signal is an authorisation being asked for while money is meant to be arriving. The PIN rule above depends on nothing at all except the mechanism. Depending on nothing else is what makes it the strongest of the four. The second is the verb. A screen reporting money that has arrived uses a word like credited or received, in the past tense, about something already done. A screen asking for money uses pay, send or approve, about something not yet done. The third is a countdown or an expiry line. A request expires and a credit does not, and money that has already arrived has no reason to run out of time. The fourth is the direction line, the small one naming an account. On a credit it says from, and on a request it says to.

Everything a sender writes onto a payment screen can be made to read like anything at all, and the only parts of the screen the sender does not control are the direction and whether an authorisation is being asked for. The amount is chosen by whoever sent the request. The note is typed by whoever sent the request. The timing is chosen by whoever sent the request. The PIN field is not: it appears because money is about to leave, and it cannot be made to appear for money arriving.

None of these four is obvious in the moment, and none of them is a test of how carefully anybody reads. All four sit in the mechanism rather than in the story, so a check made calmly afterwards is as good as one made in the moment, and gives the same answer either way. The single most reliable version of all four, for a person who wants one thing to remember rather than four, is this: money that has genuinely arrived shows up in the account holder's own bank record of that account, and it needs nothing done for it.

Why does the first hour matter when a payment has gone somewhere it should not have?

Because what can still be done shrinks with every minute, and it shrinks for two mechanical reasons rather than for any reason to do with the person it happened to. The first is settlement: while a payment is still between the two events there are more places to intervene, and once it has settled there are fewer. The second is onward movement: money that arrives somewhere can be moved on again, and each further move puts it behind another account and another bank.

So the useful order is to report first and understand later. Tell the bank that holds the account the money left, using whatever reporting route that bank publishes, and use the reporting route the regulator publishes as well. Write down what is known while it is still fresh: the amount, the time, the reference number, and whatever the screen said. Writing it down is not investigation. Keeping the record from evaporating is worth doing before anything else, and everything afterwards asks for it.

Reporting immediately keeps routes open that close later, and nothing about reporting quickly requires anybody to have worked out yet what happened or how. The order is worth saying plainly, for a reason. The instinct after a payment goes wrong is to sit with it and try to understand it first, partly because it is confusing and partly because it feels like something that ought to be explained before it is reported. Understanding first costs the very thing that was still available. The explanation can wait. The hour cannot.

What do three payments at one counter actually do?

Ashok Bhosale's tailoring counter takes money three ways in a single afternoon, and the three behave completely differently once the difference is clear.

The first customer scans the code at the counter and sends Rs 1,450/- on an immediate route. The money is in the account within moments and it is not coming back without that customer's agreement. The second customer says the payment has been sent, and a screen appears on Ashok's phone for Rs 1,450/- with the note payment for order. The screen is a collect request. Approving it would take Rs 1,450/- out of the account rather than putting it in. The third customer pays Rs 900/- in cash. The cash settled at the instant the notes crossed the counter and left no record anywhere except in Ashok's own book.

Two of those three screens carried Rs 1,450/- and looked alike, and one of them would have moved the money in the opposite direction. One afternoon at one counter holds the whole practical difference between the routes.

Now widen it to the year. The counter took Rs 96,000/- across twelve months, in several hundred separate payments of a few hundred rupees each. The counter has no account of its own, so the takings are moved in one lump at the end of each month into the household's salary account, the same account Meghna Bhosale's pay from Sahyadri Freight Services Private Limited reaches on the 1st. The statement therefore carries twelve entries for the whole year. The first reads 30 April, counter takings Rs 7,200/-, and that entry took the salary account from minus Rs 3,170/- back up to Rs 4,030/-.

How does a counter like this actually use the difference between sent and settled?

At the counter the mechanism stops being theory. The customer's screen reports the instruction and nothing else, so Ashok Bhosale does not read it. He reads his own account, the only place the settlement shows up. The habit is small and it is the entire practical difference between the instruction and the settlement.

The second habit follows from the cash. Rs 900/- that crossed the counter left no trace anywhere, so the counter's own book is not a nice-to-have, it is the only record that will ever exist. And because the takings are moved across in one lump each month, the household statement cannot say what the counter earned in any given week. The statement can only say what was transferred at month end.

Anyone reading that statement from outside, including a lender assessing a household's income, sees Rs 96,000/- arriving in twelve transfers and cannot see the trade underneath it. The statement is evidence of the twelve transfers and of nothing more. If the counter ever needs to show what it actually earns, the day book and the counter's own records are the evidence, and the twelve transfer lines are not.

The Bhosale household, Meghna Bhosale, Ashok Bhosale, Ira Bhosale and Sahyadri Freight Services Private Limited are invented.
Educational material. Not advice on any investment, tax, budget or market position.