01.03 · Concept
Cards, UPI, Wallets & Bank Transfers
Explain the difference between a payment you pull and a payment the customer pushes, and say why a UPI collect request is not a card authorization and never becomes one.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Payments lesson by lesson; 26 of 35 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Pull payments let the merchant start a debit or card authorisation; push payments move only after the payer instructs their bank or wallet. A UPI collect is a request for payer approval, not a card hold, so treating it as capturable authorisation creates unpaid fulfilment, bad reconciliation and refund errors.
What this lesson answers
- pull versus push payment difference
- is UPI collect a card authorisation
- when should UPI orders be fulfilled
Notes
Pull vs Push Payments — Pull payments exist so a merchant can request funds through an authorization-and-capture rail, while push payments exist so the payer’s bank or wallet sends funds by payer instruction; treating a UPI collect as a Visa-style authorization breaks because no issuer places a card hold and no later card capture can occur.
Key Concepts: - On Visa and Mastercard cards, a merchant-initiated pull starts with an authorization for a fixed amount such as 4999 cents, followed by capture/clearing; the issuer may approve the authorization before money is finally settled.
References
Common questions
- Why is a UPI collect not the same as a card authorisation?
- A card authorisation asks the issuer to approve a charge and may create a hold that can later be captured. A UPI collect only asks the customer to approve a debit in their UPI app. Until that approval succeeds, no money has moved and there is no authorisation hold to capture.
- Can I mark an order paid when a UPI collect is created?
- No. Creating the collect only means a payment request has been sent. The customer can ignore it, reject it, or fail approval. The order should become payable only when the payment provider or UPI status confirms that the payer-approved debit succeeded for the expected amount.
- How should payment state differ between cards and UPI?
- Model each rail with its own money states. Cards can have authorisation, capture, clearing and settlement semantics. UPI should be driven by request, approval, debit success and failure states. Do not reuse card capture or reversal logic unless the provider explicitly exposes those states for that payment method.