Payment Gateway India: UPI Eligibility and Launch Checks

This guide is for payment, product and finance leads at global gaming, content, subscription and digital-goods businesses. It focuses on accepting payments from Indian customers. Start with the legal entity and business model, then evaluate Unified Payments Interface (UPI) acceptance, device behaviour and the complete money flow.

Commercial disclosure: HaiPay publishes this guide and may receive related commercial enquiries. It combines public documentation with an original evaluation framework. The test matrix is a proposed acceptance protocol; it does not report completed payment tests. This is general information, not legal, tax or investment advice.

Start with merchant eligibility and the direction of trade

An Indian business selling abroad and an overseas business selling to Indian customers need different assessments. Describe your transaction before asking which gateway to use.

Prepare a one-page merchant profile:

• The legal entity selling the product and the country where it is incorporated.
• The website or app, what customers buy, and when you deliver it.
• Whether payments are individual purchases, renewals initiated by customers, or automatic recurring charges.
• Expected order amounts in Indian rupees (INR), volumes and refund patterns.
• The intended bank account and its currency.

Ask the provider to identify the regulatory arrangement applicable to the proposed transaction and the legal entity operating it. Have the responsible reviewer confirm the applicable Reserve Bank of India (RBI) requirements. A regulatory framework or provider logo does not establish authorisation for a particular provider or merchant.
Source: Original merchant-eligibility review checklist. This paragraph requests a scoped regulatory assessment; it does not give a legal conclusion or establish provider authorisation.

Ask the provider to identify the contracting entity and explain the permitted transaction flow in writing. For games or digital content, describe the actual product rather than relying on an industry label. A subscription business should confirm automatic charging separately from one-off UPI collection.

Use the international payment gateway guide for wider provider selection, then apply the India-specific checks below.

HaiPay India commercial snapshot: supported methods, currencies, settlement, and fees

Before diving into route-by-route due diligence, use the table below to benchmark HaiPay's published India payment methods, currency handling, settlement cadence, and fee structure against the items that must be confirmed in your merchant agreement:

Evaluate HaiPay for India checkout: Review published method coverage on APAC Local Payment Coverage and the India UPI Payment Gateway Hub, check starting rates on HaiPay Pricing, model your transaction mix with the Credit Card Processing Fee Calculator, or contact HaiPay for a written India quote.

UPI and payer applications occupy different layers

UPI is the payment system. PhonePe and Paytm provide applications through which customers can use it. Their official UPI terms describe participation as third-party application providers (TPAPs), working through payment service provider (PSP) banks.

For merchant evaluation, separate the customer's app from the gateway's enabled payment route. A familiar app logo does not establish a separate wallet integration or prove compatibility with your checkout.
Source: the two named application publishers, “UPI application terms”, and “UPI Terms and Conditions”, accessed 20 October 2026; application and PSP roles.

India Payment Acceptance Layer Map

Read this map as a set of questions, not as a transaction sequence. The funding source belongs on the payer side of the payment.

Payment Gateway India — review table 1

Source: Original editorial evaluation map informed by the first application’s terms, the second application’s terms and merchant configuration reference, accessed 20 October 2026. Requested evidence does not establish account capabilities.

UPI funding is not limited universally to money held in a bank deposit account. For example, Google Pay documents eligible RuPay credit card payments to merchants, with restrictions. That example establishes a funding possibility, not acceptance through every gateway.
Source: the named application’s help centre, “Eligible credit-card UPI payments”, accessed 20 October 2026; application-specific card-linked use and restrictions.

Evaluate mobile handoff and desktop QR separately

PayU's Intent guide describes a deeplink that triggers a UPI application. In a QR flow, the customer scans a quick response (QR) code. Treat mobile app, mobile browser and desktop journeys as separate test cases.
Source: the cited integration provider, “UPI Intent Integration” (provider-specific deeplink example; no cross-provider or device acceptance guarantee); this guide’s publisher, “India” (documented QR/deepLink response), accessed 20 October 2026 UTC.

Choose a UPI flow from your provider’s current, written integration guidance. For a new build, ask whether Intent, QR or another approved flow applies to each device. If someone proposes Collect, require the provider to identify the applicable scope, current availability and any permitted exemption before engineering depends on it.

The same integration provider’s Collect notice supports a provider-specific flow review, not cross-provider authorisation or a compatibility guarantee. Record the version and approval your integration will follow.
Source: the cited integration provider, “UPI Collect Disablement Information”, accessed 20 October 2026. The earlier article cited 7 September 2026; confirm current applicability with the provider.

Mobile Intent vs Desktop QR Test Matrix

Use the following protocol with an approved test account. Record the device, operating system, browser, payer-app version and environment for every run.

Payment Gateway India — review table 2

Source: Original test protocol informed by the integration provider's flow guidance and the guide publisher’s end-to-end testing guide, accessed 20 October 2026. These are acceptance criteria, not measured compatibility results.

Repeat applicable cases with each payer application relevant to your customers. Do not mark a cell successful merely because a payment link opened.

• Simulated application behaviour: the testing guide describes changing order status and sending test notifications. Use this to exercise delayed success and repeated-notification handling. It does not demonstrate a bank debit, payer-app handoff or successful transaction.
• Observed payment behaviour: use an approved end-to-end payment to establish the payer journey, collected amount and matching records. Do not copy a simulation result into this column.

Keep global cards separate from India-local acquiring

If cards are part of your checkout, assess them as a separate product scope. Card acquiring means the merchant-side arrangement for accepting and processing card transactions. Confirm the acquiring location, merchant entity and contract before calling it local.
Source: European Central Bank, “Payments and markets glossary” (point-of-sale card-acquirer role); Visa, “Network Integrity” (card-network acquirer–merchant relationship), accessed 20 October 2026 UTC. These role definitions do not establish India-local acquiring or the account’s availability.

Review the public pricing page and the India collection reference as separate documents. A global card price or logo does not establish an India-local acquiring arrangement. Request the acquiring location, contracting entity and account scope when local card acquiring is a requirement.
Source: this guide’s publisher, India application programming interface (API) documentation, accessed 20 October 2026; documented collection scope. The procurement questions are original guidance.

For this evaluation, the local-payment route under discussion is UPI. Global card acceptance needs its own eligibility, currency, authentication and commercial review. A business requiring India-local card acquiring should obtain an explicit answer before shortlisting the arrangement.

Map INR checkout, USD routes and bank receipt

A route name containing US dollars (USD) is not a complete explanation of the money flow. The India documentation lists an INR UPI route and a USD-labelled route, IN_UPI_USD. Confirm what each currency means for your account.

The route label alone does not establish what the payer sees or what reaches the merchant bank. Obtain records from the same approved India transaction before describing that currency flow.
Source: this guide’s publisher, the publisher’s India reference, payment-method table, accessed 20 October 2026. The currency-verification procedure is original guidance.

Have finance and engineering complete this worksheet together:

Payment Gateway India — review table 3

Source: Original currency-verification worksheet. No exchange rate, currency outcome or payout availability is assumed.

For example, a USD-labelled order alone cannot answer whether the shopper sees rupees, whether conversion occurs, or whether the bank receives USD. Match records from the same payment. If conversion applies, request the currency pair, direction, rate timestamp, rate source, markup and fee basis.

The India reference and global collection list checked for this revision both show the same public INR UPI range. The minimum-value conflict noted in the previous article is no longer present in these snapshots. Still obtain the application-specific configuration: a matching public range does not prove the limits enabled for a merchant.
Source: HaiPay, “India”, “Collection Payment Methods List”, and “Get Merchant Payment Config”, accessed 20 October 2026; matching public INR UPI range and the documented configuration model.

Compare the complete UPI quote

Request a written India quote before comparing cost. Distinguish card processing from the proposed local-method route, and ask which entity, currency and transaction profile each price covers. A global starting price is insufficient evidence of an India UPI quote.
Source: Original quote-comparison checklist. Use the provider’s current account-specific proposal for the commercial values.

Use the same order profile for each provider:

Payment Gateway India — review table 4

This is a comparison worksheet. Its rows are questions, not a statement that every listed charge applies.

For small digital purchases, compare total fees across the same order basket. Record the fixed fee, percentage fee and currency for every row, then calculate net receipts using the quoted conversion and refund rules. A headline percentage does not show the economics of small orders. The downloadable worksheet below leaves fee cells blank until you have an account-specific quote.

Compare costs on the same basket of orders and in a common currency. Include conversion only when the actual flow requires it. Do not infer free merchant processing from the customer-facing UPI experience.

Confirm payments before delivering digital goods

A customer return page is insufficient evidence for delivering an item or activating an entitlement. Design fulfilment around authenticated server evidence and a verified order state.

The India reference directs merchants to query an order after asynchronous notification for the relevant non-bank-transfer flow. The Common API reference describes signed callbacks and order identifiers. These are documented controls, not proof that a particular integration implements them correctly.
Source: HaiPay, “India” and “Common API”, accessed 20 October 2026; query confirmation and callback verification.

Use this proposed acceptance sequence:

1. Create an order with a unique merchant reference.
2. Associate the provider reference with that order.
3. Validate server notifications using the current approved signature procedure.
4. Query and reconcile the order when the integration contract requires it.
5. Match the successful payment to the intended order, amount and currency before fulfilment.
6. Apply idempotent fulfilment: processing the same payment again must not deliver the item twice.
7. Keep unresolved cases in a reviewable state with a defined customer-support path.

For a game-item purchase, test a notification arriving after the player closes checkout. Then replay the test event. The acceptance criterion is one entitlement, with an audit record explaining the payment state. This is a proposed scenario, not a reported customer result.

Finance should be able to connect the order, payment, deductions and bank receipt. Reconciliation means matching those records. Ask for a redacted sample using stable identifiers, including an unsuccessful or delayed case as well as a successful one.

Distinguish customer confirmation from settlement

Use a separate timeline for the customer payment and the merchant's access to funds.

Payment Gateway India — review table 5

The table is a recordkeeping model. Your contract determines which stages apply and their timing.

Ask whether the quoted period uses calendar days or working days, what event starts it, and what happens around holidays. Request payout frequency and receiving-bank transit assumptions separately. Avoid turning a successful consumer payment into a promise about merchant bank receipt.

Keep customer payment confirmation, contractual settlement and final bank receipt in separate records. Ask the provider and finance owner to identify the applicable terms and evidence for each event.
Source: Original payment-to-bank reconciliation framework. No India settlement duration or bank-receipt promise is asserted.

Decide whether this provider fits your India scope

Use the local-payment product and APAC coverage as discovery material, then request a written India-specific response. Neither a country page nor this guide establishes approval for your merchant.

A potential fit is a business seeking individual UPI collections that can obtain written eligibility, a clear currency map and verified operating evidence. Treat these as prerequisites to establish, not capabilities already proved for your business.

Pause the evaluation if your requirement is:

• India-local card acquiring without a separately confirmed arrangement.
• Automatic subscription charging inferred solely from UPI collection.
• Guaranteed support for every payer app or funding source.
• A particular INR limit or USD bank payout inferred from a route label.
• A launch date before payment confirmation and reconciliation have been tested.

Send the merchant profile, device priorities and currency worksheet with your India capability and quote request. Ask for a response covering eligibility, enabled collection route, effective limits, fees, currencies, supported flows and the evidence needed for launch.

Assign one owner from product, engineering and finance to review that response. Proceed only when each can connect the commercial answer to the configuration and observed payment records.

Download an India gateway evidence pack

Evaluate providers against the same merchant profile. Otherwise a proposal for a domestic seller, a foreign entity and a different settlement account can look comparable while describing different arrangements. The worksheet below helps the payment owner join the commercial answer to engineering and finance evidence.

Original evaluation method. It does not establish regulatory approval, supported payment methods or a completed live transaction.

Download the India collection evidence worksheet. Fill the entity, transaction direction and bank-account fields before asking providers to quote. For each answer, save the source or ticket, date, environment and next owner.

Keep account approval separate from checkout success

A demonstration can show a customer flow without answering which entity contracts with the merchant. A commercial proposal can describe a permitted scope without proving the implementation behaves correctly. Keep both records. Add the configuration response and test record rather than expecting one artifact to answer every question.

For a digital-goods merchant, use a proposed test order that has a clearly defined entitlement. Describe the success condition before the test: which verified payment state allows delivery, how the order and amount match, and what happens when confirmation arrives late. Use approved test credentials and redact customer information in the evidence pack.

Give unresolved outcomes an owner

Payment Gateway India — review table 6

Source: Original cross-border merchant acceptance protocol, produced October 19, 2026. The cases are proposed checks, not reported failures at a named provider.

End the review with a method-specific scope. List what is approved, what was tested, what finance reconciled, and which questions remain unanswered. A provider conversation can continue while a particular route stays outside the launch scope.

Prepare one India payment-route review record

Fill the payment-route documentation checklist manually before provider review. It connects the merchant entity, application, currency map and specific checkout flow. It does not approve a merchant or establish eligibility from a visitor's location, bank account or personal status.

1. Attach four controlled references. Identify the entity and trade-scope review, application configuration, currency map and exact route description. Use labels rather than account identifiers or secrets. A method listed in a country document does not prove your application has it enabled.
2. Name the provider-described flow. Record application handoff, QR, Collect or another documented route, with the device and return-path review. Where Collect is proposed, add the relevant provider notice and its applicability review, including any documented exception.
3. Separate return from payment confirmation. Reference the supported server-side status/notification checks and duplicate-event procedure for the matching order. Record missing verification as unresolved rather than treating a browser return as payment.
4. Assign the financial handoff. Add the configured refund scope, financial-record mapping and responsible reviewers. Keep incompatible currency, capability or environment statements visible for the provider to resolve.

Source: this guide's publisher, MerchantPaymentConfig (application-specific configuration), India and CommonApi (scoped request/status and notifications); the cited integration provider, UPI Collect disablement information (provider-specific scope and exceptions). Accessed 19–20 October 2026; linked documents and individual dates are in Sources. The checklist is original editorial guidance, not an eligibility decision.

Distinguish completeness from an unresolved payment question

Source: Original editorial fictional documentation examples, prepared 20 October 2026. These are not merchant cases, transaction tests or confirmation of route eligibility.

Mark missing material separately from conflicting declarations. For example, a refund-capability promise needs review if the cited configuration does not support it; correcting that statement does not determine consumer rights. Give the same pack to the provider, engineering and finance reviewers and retain the environment, date and actual decision for each item.

What published India merchant cases can—and cannot—prove

Public merchant cases help identify a useful operating pattern. They cannot approve another business or establish its payment outcome. Cashfree Payments published the following accounts about its India customers. They are provider-reported examples, not tests conducted for this guide or independent performance audits.

Zepto: an actual mobile UPI Intent integration

The provider's customer story dated 8 December 2022 says the merchant integrated the payment gateway API into its mobile application and used UPI Intent. The described flow lets shoppers choose an installed payer application before completing payment there. This is a merchant checkout implementation, rather than evidence drawn from a consumer's personal transfer instructions.
Source: the case-study publisher, mobile-checkout customer story (India merchant deployment reported by its provider), published 8 December 2022; accessed 20 October 2026.

Its age and scope matter. The story does not certify today's device coverage, every installed app or another merchant's eligibility. Use it to identify the journey your team needs to examine, then follow the current integration contract for your account.
Source: the case-study publisher, mobile-checkout customer story, published 8 December 2022; accessed 20 October 2026. Scope limitations are editorial analysis.

Shesha Ayurveda: checkout also needs a refund-operations record

A separate case dated 3 April 2026 describes the beauty merchant preparing its India business for increased demand. Beyond checkout, the account identifies refund tracking and daily refund reports as part of its operations. That is a concrete reporting practice to request during evaluation; it is not proof that your refunds will complete at the same speed.
Source: the case-study publisher, beauty-merchant customer story (provider-reported operations, including cash on delivery (COD) refunds), published 3 April 2026; accessed 20 October 2026.

Translate those examples into three merchant records

Source: the case-study publisher, Account Activation, Hosted Web Checkout and Get All Refunds for an Order (the same provider’s specific workflows), accessed 20 October 2026. The review-record column is original guidance.

Follow a return, a payment result and a refund separately

In an approved test environment, exercise the mobile return path and a delayed confirmation. Record the expected outcome first. A proposed test is not a completed merchant case.

1. After the shopper returns: retrieve the matching order on the backend. Keep the customer page provisional until the documented payment check is satisfied; a closed browser or missing redirect must not decide the financial result.
2. Before delivery: match the verified result to the intended order, amount and currency. Apply your duplicate-fulfilment control to repeated notifications. Record that control as your application's responsibility, not as a result established by either customer story.
3. When reviewing a refund: inspect the refund record separately. PENDING or PENDING_APPROVAL is not SUCCESS. Match the payment reference, refund reference, amount and currency before explaining its status to support or finance.

Source: the case-study publisher, Hosted Web Checkout (server verification and redirect limits) and Get All Refunds for an Order (separate refund fields and statuses), accessed 20 October 2026. Test design and duplicate-fulfilment review are original recommendations.

Finally, keep an overseas merchant's approval question open until its own provider answers it. Neither an Indian customer's successful deployment nor the activation checklist establishes that a foreign entity, different business category or nominated settlement account qualifies. Ask for the entity-specific acceptance decision before planning a production launch.
Source: the case-study publisher, Account Activation (entity-specific verification, not a universal eligibility grant), accessed 20 October 2026.

Sources

1. HaiPay documentation, accessed 20 October 2026:
   • Common API: scoped notification signatures and order references.
   • India API: collection request/status and documented currency routes.
   • MerchantPaymentConfig: application-specific configuration; not activation proof.
   • Collection Payment Methods List: public route ranges, not merchant limits.
   • End-to-end testing guide: simulated status and notifications, not observed bank payments.
   Publication dates not shown. These contracts establish neither account approval nor bank receipt.
2. PayU documentation, publication dates not shown; accessed 20 October 2026: UPI Intent Integration covers a provider-specific deep link and separate verification; UPI Collect Disablement Information requires a flow/applicability review. Neither grants device compatibility or authorizes another provider’s route. The earlier notice citation was dated 7 September 2026.
3. PhonePe: UPI application terms; Paytm: UPI terms. Application and PSP-bank roles, not wallet activation or merchant compatibility. Publication dates not shown; both accessed 20 October 2026.
4. Google Pay Help: Eligible credit-card UPI payments. Application-specific funding conditions and restrictions, not gateway-wide acceptance. Publication date not shown; accessed 20 October 2026.
5. European Central Bank: Payments and markets glossary — acquirer, point-of-sale role definition; Visa: Network Integrity, acquirer–merchant relationship. Publication dates not shown; accessed 20 October 2026. Neither establishes India-local acquiring or merchant approval.
6. Cashfree Payments:
   • Mobile-checkout customer story, published 8 December 2022: reported merchant mobile Intent integration, not current all-device compatibility.
   • Beauty-merchant customer story, published 3 April 2026: reported refund tracking and daily reports, including cash on delivery. No refund-speed benchmark is adopted.
   • Account Activation: entity-specific verification and sandbox scope, not blanket foreign-merchant eligibility.
   • Hosted Web Checkout: separate server verification, documented PAID state and redirect limits.
   • Get All Refunds for an Order: separate refund references, states, amount/currency and processing timestamps.
   All accessed 20 October 2026; documentation publication dates not shown. Customer stories are provider-reported, not independently audited or our implementations. Documentation examples are not executed payments, refunds or bank receipts.