You tap “Pay Now.”
Within a few seconds, you see:
Payment Successful ✅
It feels almost instantaneous.
But behind that single tap, a surprisingly complex chain of systems starts communicating with each other — your browser or mobile app, the merchant's backend, a payment gateway, banks, card networks or UPI infrastructure, fraud detection systems, authentication services, and databases.
So what actually happens when you make an online payment?
Let's go behind the scenes and understand the complete journey.
1. The Payment Starts With a Simple Click
Imagine you're purchasing a ₹2,000 product from an e-commerce website.
You add the product to your cart and click:
Pay ₹2,000
Your frontend application sends the payment information to the backend.
A simplified request might look like:
POST /api/create-payment
{
"orderId": "ORD12345",
"amount": 2000,
"currency": "INR"
}
The frontend should generally not be trusted to determine the final amount.
The backend verifies the order and calculates the amount using its own database.
Why?
Because a malicious user could modify frontend JavaScript and attempt to change:
₹2,000 → ₹20
The server must independently verify the transaction.
2. Your Request Travels Over the Internet
Your application needs to communicate with the merchant's server.
For example:
Mobile App
↓
Internet
↓
Merchant Backend
The connection is normally protected using HTTPS.
HTTPS uses TLS (Transport Layer Security) to encrypt communication between the client and server.
This helps prevent attackers on the network from simply reading sensitive information being transmitted.
The important idea is:
Client
│
│ Encrypted HTTPS
▼
Merchant Server
3. The Merchant Creates an Order
The merchant's backend typically creates an internal order record.
For example:
Order ID: ORD12345
User ID: 7842
Amount: ₹2,000
Status: CREATED
At this stage, the payment has not necessarily succeeded.
The system is simply tracking the transaction.
A typical payment lifecycle might look like:
CREATED
↓
PAYMENT_PENDING
↓
PROCESSING
↓
SUCCESS
Or:
PROCESSING
↓
FAILED
Keeping payment states is extremely important because payment systems are distributed systems where failures and delays can happen.
4. The Payment Gateway Enters the Picture
The merchant usually doesn't communicate directly with every bank and payment network.
Instead, it can integrate with a payment gateway/payment service provider.
The architecture can look like:
Customer
↓
Merchant Website
↓
Merchant Backend
↓
Payment Gateway
↓
Payment Network / Bank
The gateway provides APIs and infrastructure for processing payments.
It can handle things such as:
- Payment initiation
- Payment method selection
- Authentication flows
- Payment status
- Webhooks
- Refunds
- Transaction verification
5. You Choose a Payment Method
You might see options such as:
UPI
Credit Card
Debit Card
Net Banking
Wallet
Different payment methods can involve different processing flows.
For example:
Card Payment
Customer
↓
Merchant
↓
Payment Gateway
↓
Card Network
↓
Issuing Bank
While a UPI transaction follows a different ecosystem and routing process.
The important point is that there isn't one universal payment path.
The systems involved depend on the payment method.
6. What Happens During a Card Payment?
Suppose you choose a credit card.
The payment information is securely submitted through the payment infrastructure.
The transaction eventually needs to reach the institution that issued the card.
Conceptually:
Merchant
↓
Payment Gateway
↓
Card Network
↓
Issuing Bank
The issuing bank is the bank that provided your card.
The bank then evaluates the transaction.
It may check things such as:
- Is the card valid?
- Is it expired?
- Is the account active?
- Is there sufficient available credit?
- Does the transaction appear suspicious?
- Is additional authentication required?
7. Authentication Can Be Required
Sometimes the payment requires additional authentication.
For example, you might be asked for:
OTP
or another authentication mechanism depending on the payment method and applicable rules.
This creates another interaction:
Payment
↓
Authentication Required
↓
Customer Authenticates
↓
Payment Continues
This helps establish that the person initiating the transaction is authorized to make it.
Authentication and authorization are related but different concepts.
Authentication asks:
Who are you?
Authorization asks:
Are you allowed to perform this transaction?
8. Fraud Detection Happens Behind the Scenes
Payment systems don't simply ask:
"Does the customer have money?"
They may also evaluate whether the transaction appears suspicious.
A fraud detection system may consider signals such as:
Transaction amount
Payment history
Device information
Location signals
Merchant information
Transaction frequency
Risk patterns
For example, imagine a customer normally makes small transactions and suddenly attempts several extremely large transactions from a new device.
That transaction could receive a higher risk score.
Conceptually:
Transaction
↓
Risk Engine
↓
┌───────────────┐
│ Risk Analysis │
└───────────────┘
↓
Approve / Review / Decline
Modern payment systems can use rules, statistical models, and machine-learning systems for fraud detection.
9. Authorization Happens
Now the bank or relevant payment system determines whether the transaction can proceed.
A simplified flow is:
Payment Request
↓
Validate
↓
Authenticate
↓
Fraud Check
↓
Check Funds / Credit
↓
Authorize
If everything is acceptable:
AUTHORIZED ✅
Otherwise:
DECLINED ❌
But there is an important distinction:
Authorization does not necessarily mean the entire payment lifecycle is finished.
10. Authorization vs Settlement
This is one of the most important concepts in payment systems.
Authorization
Authorization essentially means:
The transaction has been approved for processing.
Settlement
Settlement is the process through which funds are ultimately transferred between the relevant financial institutions.
So conceptually:
Authorization
↓
Transaction Approved
↓
Clearing
↓
Settlement
↓
Funds Reconciled
The user might see:
Payment Successful
before all the underlying financial settlement processes have completely finished.
11. What Is Clearing?
Clearing involves exchanging and reconciling transaction information between the institutions involved.
Imagine thousands or millions of transactions happening throughout the day.
The payment ecosystem needs to determine:
Who owes whom?
How much?
For which transactions?
The payment information is processed and reconciled so that the appropriate parties can ultimately settle the funds.
This becomes particularly important at large scale.
12. What Is Settlement?
Settlement is where the financial obligations are ultimately settled between participating institutions.
A simplified example:
Customer Bank
↓
Payment Network
↓
Merchant's Payment Provider
↓
Merchant's Bank
The actual infrastructure can be considerably more complicated depending on the payment method, country, banks, networks, and intermediaries involved.
But the fundamental idea is:
The transaction information eventually results in the appropriate movement and reconciliation of funds.
13. Your Merchant Backend Still Needs Confirmation
Now comes a very important backend concept.
Suppose the payment provider tells the merchant:
Payment successful
How does the merchant know that this message is genuine?
Payment providers commonly use webhooks or APIs to communicate transaction events.
For example:
POST /webhooks/payment
{
"event": "payment.success",
"paymentId": "PAY12345",
"orderId": "ORD12345",
"status": "success"
}
The merchant backend receives this event and updates its database.
For example:
Order
-------------------------
ORD12345
Amount: ₹2,000
Status: PAID
Payment ID: PAY12345
14. Why Webhooks Are So Important
Imagine the customer's internet connection disappears immediately after payment.
The payment may still succeed.
But the browser might never receive the final response.
Without a reliable server-to-server notification mechanism, the merchant could incorrectly think:
Payment failed.
while the customer's bank actually processed it successfully.
This is why payment systems often use webhooks and server-side verification.
The architecture becomes:
Customer
↓
Payment Provider
↓
Merchant Backend
↓
Database
The backend can receive the final payment event independently of the customer's browser.
15. Idempotency Prevents Duplicate Payments
Now imagine the customer clicks:
Pay Now
The request reaches the server, but the network times out.
The customer doesn't know whether the payment happened.
They click again.
Without proper safeguards, the system might create two payments.
This is where idempotency becomes extremely important.
The client or backend can provide a unique idempotency key:
Idempotency-Key:
abc123xyz
If the same operation is submitted again, the payment system can recognize that it has already processed that request.
Conceptually:
Request 1
↓
Payment Created
Request 2
↓
Same Idempotency Key
↓
Existing Result Returned
This helps prevent duplicate processing.
16. Distributed Systems Make Payments Difficult
Payment systems are a classic example of distributed systems.
There are multiple independent components:
Frontend
↓
Merchant Backend
↓
Payment Gateway
↓
Payment Network
↓
Bank
↓
Database
Any component can experience:
- Network timeout
- Server failure
- Delayed response
- Duplicate request
- Partial failure
- Temporary unavailability
For example:
Merchant → Gateway → Bank
↑
Timeout
A timeout doesn't necessarily mean the payment failed.
The bank might have processed the transaction but the response may not have reached the merchant.
This is why payment systems require careful state management and reconciliation.
17. Payment Status Isn't Always Just Success or Failure
Real payment systems often need more states.
For example:
CREATED
PENDING
PROCESSING
AUTHORIZED
SUCCESS
FAILED
CANCELLED
REFUNDED
PARTIALLY_REFUNDED
Why?
Because distributed systems don't always know the final state immediately.
For example:
Payment → PROCESSING
↓
Bank response delayed
↓
Merchant temporarily doesn't know
the final result
Instead of incorrectly marking the payment as failed, the system can keep it as:
PENDING
and later reconcile the final state.
18. What Happens If the Payment Fails?
Suppose the bank declines the transaction.
The flow could look like:
Customer
↓
Merchant
↓
Payment Gateway
↓
Bank
↓
DECLINED
The gateway sends the status back.
The merchant backend updates:
Payment Status = FAILED
The frontend then displays something like:
Payment failed. Please try again.
The important part is that the backend should rely on verified payment status, rather than simply trusting what the frontend says.
19. What Happens If You Close the Browser?
This is an interesting scenario.
Suppose:
Payment initiated
↓
Bank processes payment
↓
Customer closes browser
The payment may still succeed.
That's why the merchant cannot rely entirely on the browser's response.
Instead, the backend can receive the payment provider's webhook and update the order.
Later, when the customer opens the application again:
GET /orders/ORD12345
The backend can return:
{
"orderId": "ORD12345",
"paymentStatus": "SUCCESS"
}
The customer then sees:
Order confirmed ✅
20. What Happens After Payment Success?
Once the merchant verifies the successful payment, it can perform business operations.
For example:
Payment Successful
↓
Update Order
↓
Generate Invoice
↓
Reduce Inventory
↓
Confirm Order
↓
Send Email/SMS
↓
Start Delivery Process
For a digital product, it might instead be:
Payment Successful
↓
Activate Subscription
↓
Update User Account
↓
Grant Access
21. Why Payment APIs Should Be Secure
Payment systems handle highly sensitive operations.
Security therefore becomes critical.
Some common practices include:
HTTPS
Encrypt communication between systems.
Authentication
Verify that requests come from authorized systems.
Authorization
Ensure users and services can perform only permitted operations.
Signature Verification
Webhook payloads can be cryptographically verified to ensure they came from the expected payment provider and weren't modified in transit.
Tokenization
Sensitive payment credentials can be replaced with tokens in systems that support tokenization.
Instead of repeatedly handling raw sensitive information:
Sensitive Credential
↓
Token
↓
Payment Processing
This can reduce exposure of sensitive payment data.
22. Never Trust the Frontend for Payment Verification
Consider this dangerous implementation:
if (paymentStatus === "success") {
activatePremium();
}
If the frontend controls the decision, a malicious user may attempt to manipulate the application.
A safer architecture is:
Frontend
↓
Merchant Backend
↓
Payment Provider
↓
Verified Payment Status
↓
Database
↓
Premium Activated
The backend should verify the transaction using the payment provider's supported verification mechanisms before fulfilling the order.
23. What Happens During a Refund?
The payment journey doesn't necessarily end with a successful purchase.
Suppose you return the product.
The merchant initiates:
Refund Request
↓
Payment Provider
↓
Financial Institution / Payment Network
↓
Customer Account
The refund itself may have its own lifecycle:
REFUND_REQUESTED
↓
PROCESSING
↓
REFUNDED
Again, the merchant may receive asynchronous updates about the refund.
24. Reconciliation: The Unsung Hero of Payments
Imagine a merchant processed:
10,000 transactions
Its internal database says:
Successful = 9,850
Failed = 100
Pending = 50
But the payment provider's records may temporarily differ.
The merchant needs a process to compare:
Merchant Records
↕
Payment Provider Records
↕
Bank/Settlement Records
This process is called reconciliation.
It helps identify:
- Missing transactions
- Duplicate transactions
- Incorrect statuses
- Failed updates
- Refund mismatches
- Settlement discrepancies
For financial systems, reconciliation is extremely important.
25. The Complete Payment Flow
Putting everything together:
CUSTOMER
│
▼
Mobile App / Browser
│
HTTPS
│
▼
Merchant Backend
│
Create Order
│
▼
Payment Gateway
│
▼
Payment Network / Rail
│
▼
Bank / PSP
│
┌─────────┴─────────┐
│ │
Authentication Fraud Check
│ │
└─────────┬─────────┘
│
▼
Authorization
│
▼
Response
│
▼
Payment Provider
│
Webhook
│
▼
Merchant Backend
│
▼
Database
│
▼
Order Confirmed
│
▼
Customer
And separately:
Transaction
↓
Clearing
↓
Settlement
↓
Reconciliation
26. The Role of Databases
Behind the payment system, databases maintain important transaction information.
A simplified payment table could look like:
payments
--------------------------------
id
order_id
user_id
amount
currency
status
provider_payment_id
created_at
updated_at
The system might also maintain an event or transaction history:
payment_events
--------------------------------
id
payment_id
event_type
event_data
created_at
This can help with debugging, auditing, reconciliation, and tracking the lifecycle of a payment.
27. Why Payment Systems Need Strong Consistency
Imagine the payment succeeds but the order remains:
UNPAID
The customer may have paid but not receive the product.
Or imagine the order becomes:
PAID
when the payment actually failed.
That could result in the merchant providing goods without receiving payment.
Therefore, payment systems need carefully designed transaction processing, state transitions, verification, retries, and reconciliation.
The challenge isn't simply:
"How do we process a payment?"
It's:
"How do we reliably determine and maintain the correct payment state despite failures?"
28. Payments Are a Distributed Systems Problem
This is perhaps the biggest takeaway.
A payment isn't simply:
Click → Money Transferred
It's closer to:
Client
↓
API
↓
Order Service
↓
Payment Service
↓
Gateway
↓
Bank / Payment Network
↓
Authentication
↓
Fraud Detection
↓
Authorization
↓
Webhook
↓
Database
↓
Settlement
↓
Reconciliation
And all of these systems need to work together reliably.
29. A ₹2,000 Payment in a Few Seconds
So the next time you pay ₹2,000 for something online, remember what is happening behind that Pay Now button.
Your request travels through multiple services.
Your payment is authenticated.
Risk systems evaluate the transaction.
The relevant financial infrastructure processes it.
The merchant receives and verifies the result.
The database records the transaction.
The order is updated.
And later, financial systems reconcile and settle the transaction.
All of this happens behind an interface that simply says:
Payment Successful ✅
30. Final Takeaway
Online payments are one of the best real-world examples of backend engineering + networking + security + distributed systems + databases working together.
A simple payment involves much more than moving money.
It requires answering several difficult questions:
- Is this request authentic?
- Is the transaction authorized?
- Is it fraudulent?
- Did the bank actually process it?
- What happens if the network times out?
- What if the user retries?
- What if the webhook arrives twice?
- What if the merchant's server goes down?
- How do we reconcile different systems?
- How do we guarantee that the order reflects the correct payment state?
That is what makes payment infrastructure such an interesting backend engineering problem.
One tap for the user.
Dozens of systems behind the scenes.
Millions of transactions at scale.
And that's what really happens when you make an online payment. 🚀
Top comments (0)