PhonePe Merchant Guide: UPI Collection and Auto-Debit

PhonePe Merchant Guide: UPI Collection and Auto-Debit

Treating Indian payment integration as one more card rail is the most common starting point for these projects and the most likely to require rework. Indian payment volume concentrates heavily on UPI, the Unified Payments Interface, and UPI is technically almost nothing like a card. There is no card number, no expiry, no CVV, and collection relies on a virtual payment address. Most of the form, validation and retry logic you built for cards does not apply here.

This guide follows PhonePe as its main thread and sets out the integration trade-offs of UPI collection and auto-debit. PhonePe is a UPI-based payment platform in India that also provides merchant acquiring. For the wider Indian structure start with the India Payment Guide.

1. Positioning: A UPI-Based Payment Platform and Acquirer, Not a Card Rail

1.1 No Card Number, the Collection Identifier Is a Virtual Payment Address

The collection identifier in UPI is a virtual payment address, a VPA, an alias bound to a phone number or account. Buyers paying do not type a card number but scan a code, enter a VPA, or select the payee inside a payment app. What the merchant receives is not a card number but an identifier usable to raise a collection request. Any logic that depends on storing card numbers, reading card BINs or judging card type has to be rewritten.

Another property of the VPA is that it is bound more directly to user identity, and one user may hold several VPAs mapped to different bank accounts. During reconciliation you cannot assume the same user pays with the same identifier every time, and that directly affects user attribution and refund targeting.

For engineering teams the mindset shift that matters most is this: UPI success does not depend on the return of a single request but on the buyer confirming inside their payment app. That action may happen immediately, may be delayed, and may be abandoned.

1.2 What It Is Not

First, it is not a card rail. There is no card number and no two-stage authorisation and capture, and the concepts of chargeback and evidence do not apply.

Second, it is not a synchronous payment. Except in a few scenarios, the UPI result requires the buyer to confirm inside their payment app, and the result arrives through callbacks and queries.

Third, it is not one uniform user experience. Different payment apps, including PhonePe and other UPI apps, differ in interface and interaction detail, and the merchant cannot fully control what the buyer sees at the confirmation step.

Fourth, it cannot design your subscriptions. Subscriptions rely on e-mandate authorisation, a completely different mechanism from card-on-file debits.

2. Onboarding and Entity Requirements

2.1 Merchant Entity, Virtual Payment Address and Business Description

UPI acquiring onboarding centres on the merchant entity and the collection identifier configuration. The merchant integrates under its own entity, binds the account used for collection, and submits merchant details and a business description on the payment platform. On the identifier side the merchant obtains a VPA or merchant identifier for collection, and buyers pay against it.

In material preparation a business description matters no less than entity documents. The reviewer has to judge what you sell, to whom and whether the refund policy is clear. Because users in UPI confirm inside their payment app, the clarity of the merchant page description directly affects whether they continue to pay.

Another easily missed point is the relationship between the collection account and the settlement account. Which account receives collection, which receives settlement and whether they must match has to be confirmed before integration, and account changes must go through process rather than a direct configuration edit.

2.2 Settlement, Tax and Compliance

Indian settlement and compliance follow their own cadence and requirements. Merchants need to watch the settlement cycle, the settlement report fields, and tax and invoicing obligations. UPI transaction evidence differs from cards, so reconciliation must follow the transaction records and settlement reports the payment platform provides.

For cross-border teams there is also the question of entity and cross-border money movement. Where funds go after collection, whether cross-border transfer is possible and what documents are required depend on your entity structure and local rules, and must follow current official requirements and the contract. For the wider framework see the Payment Compliance and Licence Filing Guide.

3. Integration Options and Account Structure

3.1 The Intent Flow and the Collect Flow

UPI collection has two typical flows. The intent flow is buyer-initiated: the buyer scans a code or enters the merchant VPA, confirms the amount inside their payment app and completes payment. The collect flow is merchant-initiated: the merchant raises a collection request to the buyer VPA, and the buyer sees the request inside their payment app and confirms.

The difference is not only direction. In the intent flow the buyer mindset is that they want to pay this merchant, so the initiative sits with the buyer. In the collect flow the mindset is that someone is requesting money, so the buyer has to judge whether the request is trustworthy. That directly affects conversion and failure rates, and it affects how you guide the buyer on the page.

In implementation, the collect flow requires you to have the buyer VPA first, which usually happens after the buyer fills it in or authorises it. The intent flow only needs the merchant collection identifier displayed. Which flow to choose depends on whether your scenario is web checkout, in-app payment or offline scanning.

3.2 Callbacks, the State Machine and the Two Timeout Semantics

What the server must get right is the state machine. A UPI result may arrive by callback or may require an active query. A timeout in the intent flow usually means the buyer did not confirm, so the order should move to failed or retryable. The collect flow timeout semantics differ: the buyer may never have seen the request, or may have seen it without acting, so marking the order failed outright is wrong and you need to distinguish not delivered from delivered but unconfirmed.

The state machine should therefore distinguish at least created, delivered, awaiting buyer confirmation, success, failed, timed out and cancelled. Collapsing those into one processing state makes support, retries and reconciliation unmanageable later. For the overall flow see the Payment Transaction Flow Basics.

4. Core Capabilities and Market Coverage

4.1 Interaction, Timeout Semantics and Fit of the Two UPI Flows

Putting the two flows side by side in one table is the most effective starting point for an integration design. The difference shows in interaction shape, timeout and failure semantics, and fit.

Use the table by deciding first whether your scenario is active payment or passive collection, then deciding which states the state machine needs. Do not use one flow for every scenario. For regional differences see the Local Payment Methods by Region Guide.

4.2 Subscriptions and e-Mandate Auto-Debit

Subscriptions in the UPI ecosystem rely on e-mandate, an authorisation from the user for the merchant to debit automatically under agreed rules in future. Its core is one authorisation followed by rule-based debits, differing from card-on-file debits in the authorisation target, the trigger and user visibility.

That means a subscription system cannot simply change a parameter from the card version. You have to handle mandate creation, mandate state, notification and user visibility before each debit, and the retry strategy after a failed debit. Handling a revoked mandate or insufficient limit must also be designed separately from card subscriptions. For interface design see the Subscription Billing API Integration Guide, and for recovery strategy the Subscription Dunning and Recovery Guide.

5. Fee Structure and Real Cost

5.1 Fee Components

Current rates and conditions belong to the official quote and current regulatory rules. Any percentage in an article goes stale, and budgeting from old numbers is the easiest error to make.

5.2 Real Cost and How It Couples With Success Rate

In a UPI context real cost couples more tightly with success rate than in a card context. Because the buyer confirmation happens inside a payment app, any poor guidance turns directly into a failure, and the cost of a failure is not just the fee but also support cost, lost orders and extra calls from retries.

The optimisation order should therefore be success rate first and rate second. Common levers on the success side are showing the payee and amount clearly on checkout, giving explicit confirmation guidance for collect requests, and offering a sensible retry path after a timeout. For the wider method see the Payment Success Rate Optimisation Guide.

6. How It Divides Work With Other Options

6.1 Against Indian Acquiring Platforms

In India many teams choose an acquiring platform rather than integrating a single payment app, because the platform aggregates several UPI apps and card rails and reduces the number of integrations. For the platform view of UPI compare Razorpay with the Razorpay Guide, and also consider Paytm, which started from wallets and UPI.

The deciding factor is control versus cost. Integrating a payment app directly gives finer channel data and more direct communication, while an acquiring platform covers more channels with fewer interfaces at the cost of an extra layer. Do not enable two overlapping solutions for one scenario, because reconciliation becomes a burden immediately.

6.2 Against Card Acquiring and Subscription Billing Options

Cards still matter in India, especially for cross-border, business purchasing and some high-value scenarios. Global acquirers are more mature on card rails and interface consistency, such as Adyen and Stripe. Their UPI depth usually depends on partner channels, so the method list may suffice while the detail experience may not match a local platform.

Subscription businesses need separate assessment: UPI e-mandate and card-on-file debits are two mechanisms, and if your subscription system was built around cards, adding UPI subscriptions means building another authorisation and debit flow. The more realistic approach is to abstract the subscription layer behind a unified interface and adapt each authorisation mechanism underneath.

7. Who It Fits and Who It Does Not

7.1 Good Fit

First: teams where India is a primary market, buyers are mostly local consumers and order frequency is high. UPI coverage is close to reach itself.

Second: teams with subscription or repeat-purchase business that are willing to invest in the e-mandate authorisation system, since Indian subscriptions cannot avoid UPI mandates.

Third: teams willing to rewrite the payment front end. The card form logic is largely obsolete for UPI, and the front end has to be redesigned around VPA and QR codes.

7.2 Weak Fit

First: teams treating India as a test market with very low volume and most buyers abroad. Direct integration cannot be amortised, so an aggregating option is more sensible for a while.

Second: teams hoping to port a card-based payment system as is. UPI differs so much from cards that the rework is usually badly underestimated.

Third: teams treating subscriptions as a parameter change. Mandate creation, notification and failed-debit handling all need separate design.

Fourth: teams with no server-side engineering capacity that expect configuration alone to work. The two UPI flows and the state machine cannot be avoided.

8. Rollout Notes and Common Misreadings

8.1 Rollout Notes

8.2 Common Misreadings

The first misreading is treating UPI collection as scan and settle. The collect flow has an explicit timeout and a buyer-side confirmation step, so nothing succeeds unless the buyer confirms.

The second misreading is assuming subscriptions can copy the card-on-file model. An e-mandate is an authorisation system that differs from card-on-file debits in authorisation target, trigger and user visibility, and it needs a new design.

The third misreading is treating the VPA as the user unique key. One user may hold several VPAs, and keying on it breaks attribution and refund targeting.

The fourth misreading is using card reconciliation evidence for UPI. The evidence, fields and granularity differ, and reconciliation must follow the transaction and settlement records the platform provides.

If you are working on Indian payment integration, use this guide as a checklist: decide whether your scenario uses intent or collect, decide which states the state machine needs, then design the subscription authorisation and refund flows separately. For the wider regional judgement, continue from the Payment category page.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.