Why should you care?

Swiggy payment plus order status update must both succeed or neither — PostgresVerse uses transactions so money is not captured without an order row.

See it live — copy this example

Run in pgAdmin or psql.

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE account_id = 10;
UPDATE accounts SET balance = balance + 500 WHERE account_id = 20;
INSERT INTO transfers (from_acct, to_acct, amount) VALUES (10, 20, 500);
COMMIT;

What happened?

• Debit, credit, and audit insert share one transaction.
• If INSERT fails, ROLLBACK reverses both balance updates — no partial transfer.

Practice next

1. Create accounts and transfers tables with sample balances.
2. Run BEGIN ... COMMIT successfully.
3. Repeat with intentional error before COMMIT and ROLLBACK.
4. Use START TRANSACTION READ ONLY for reporting snapshot.
5. Wrap multi-table order insert in one transaction in psql script.

Remember

ACID atomicity = all or nothing. Explicit BEGIN gives control over commit timing. Keep transactions short in web apps.

PostgresVerse UPI transfer

API service uses transaction block for debit/credit/ledger insert on payment success.

Outcome: Reconciliation finds zero orphan debits after gateway timeout retries.