PhonePe payment system design: Pay to Payment successful

The interview question goes like this. You tap Pay on PhonePe, the network drops, and you don't know if the money left your account. How does the system cope?

One note first. This is the standard interview design for a UPI payment, not PhonePe's own internal system. Treat it as a way to answer the question, not a description of their stack.

Why the obvious answer fails

The obvious design has the app talk straight to the bank. That works until the network breaks mid-request. Then the app has no idea whether the bank debited you or not, and it has nowhere else to look.

The fix is to put a few well-defined steps between the app and the bank, and to give every payment an identity.

The flow, step by step

Here is the path a payment takes.

PhonePe app. Before anything else, the app gives each payment a unique transaction ID. Everything downstream hangs off that ID.

Payment server. It checks the ID and forwards the request. If an ID it has already seen comes in again, the payment doesn't run a second time. That one check is what makes retries safe later.

NPCI UPI. NPCI is the central body that runs UPI and connects banks to each other. It routes the request between them.

Banks. NPCI tells your bank to debit, meaning take the money out. It tells the receiver's bank to credit, meaning add the money in.

Ledger. The bank's reply is written to a ledger, like an account book, saved by transaction ID.

Notification. Your phone gets a message saying the payment succeeded or failed.

What happens when the network drops

This is where the ledger earns its place. The bank's answer is recorded against the ID, so the status doesn't live only in a connection that just died. If the network breaks, the system can look up that ID in the ledger and read the status from there.

So the question "did the money go?" turns into a lookup. You don't guess. You read the record for that transaction ID.

Retry and double debit

Now the harder case. At peak load the bank is slow and the status comes back pending. You get impatient and hit retry.

In a naive system, that could debit you twice. Here, the retry carries the same ID. The payment server has seen that ID, so the debit isn't repeated. Same ID in, same payment, no second charge.

That is the whole trick. The ID names the payment, the server refuses to run a known ID again, and the ledger holds the truth.

What to say in the interview

Keep the answer short and in this order. Unique ID per payment. Every step recorded in the ledger. Retry sends the same ID. Together these avoid double debit.

Next time you're asked a payments design question, start by asking what identifies the request. If you can answer that, the retry and failure cases mostly follow from it.