UPI for International Merchants
UPI for International Merchants: How to Reach India’s Account-to-Account Payment Users An Indian customer reaches an international merchant's checkout. They have enough money. They have a bank account. Their phone already has an app capable of making UPI payments. What they may h
UPI for International Merchants: How to Reach India’s Account-to-Account Payment Users
An Indian customer reaches an international merchant's checkout.
They have enough money.
They have a bank account.
Their phone already has an app capable of making UPI payments.
What they may have no particular reason to do is take out a card and type a card number into an unfamiliar international checkout.
The merchant does not have a payment-intent problem.
It has a payment-access problem.
That distinction matters because UPI is no longer well described as a niche alternative sitting beside India's conventional payment infrastructure. RBI's Annual Report for FY2025–26 says UPI accounted for nearly 86% of total retail-payment transaction volume in India during the financial year. UPI processed approximately 241.6 billion transactions worth ₹314.2 lakh crore in FY2025–26.
NPCI's monthly data provide another view of the scale: in June 2026, UPI processed about 22.7 billion transactions across 731 banks reported live on the system.
Scale alone does not prove ecommerce relevance for every merchant. But RBI's nationwide digital-payments survey strengthens the customer-access case: the survey covered more than 30,000 users and 10,000 merchants, and RBI reported UPI as the predominant digital-payment mode for both usage and merchant acceptance.
For merchants entering India, that changes the starting question.
Do not ask only:
Should we add another alternative payment method?
Ask:
Are we asking a large population of Indian customers to abandon the account-to-account payment behavior they already use and revert to a card-centric checkout designed for another market?
That does not mean every international merchant should immediately switch UPI on.
It means UPI deserves to be evaluated as core Indian customer payment infrastructure.
And the next question is harder:
Can this particular international merchant actually accept it?
What UPI is
The Unified Payments Interface is an interoperable payment system developed and operated by the National Payments Corporation of India.
NPCI describes UPI as enabling immediate transfer between accounts through mobile applications and supporting both person-to-person and merchant payments. A customer can use a UPI-enabled app to access multiple eligible accounts and make payments without exposing ordinary bank-account details to the merchant checkout. UPI supports identifiers and initiation mechanisms including virtual payment addresses, QR codes, and intent-based payments.
That description contains several distinct layers that merchants should keep separate:
UPI
The interoperable payment system.
UPI-enabled app
The software interface through which the customer interacts with UPI.
Customer financial account
The eligible bank or other supported account from which payment value is sourced.
UPI ID / Virtual Payment Address
An identifier that can be used to address a payment without requiring the customer to enter conventional bank-account details at checkout.
QR or intent
Different ways of initiating or handing the transaction into the customer's UPI environment.
Merchant acquirer / payment provider
The entity or entities that connect the merchant to UPI, handle onboarding, transaction messages, payment status, and potentially settlement.
Calling all of this “a wallet” collapses the very distinctions an international merchant needs to understand.
UPI is not a UPI app
Customers experience UPI through apps.
That makes it easy to confuse the interface with the system underneath.
BHIM, for example, is a UPI application. Other banks and payment-service providers also offer UPI-enabled applications. NPCI's architecture explicitly identifies distinct participants including UPI apps, payer PSPs, remitter banks, payee PSPs, beneficiary banks, users, and merchants.
The merchant therefore does not normally “integrate the customer's UPI app.”
It integrates a merchant-payment capability that can hand the customer into eligible UPI applications or otherwise initiate a UPI transaction.
This distinction matters operationally because:
app availability can differ from merchant connectivity;
different customer apps may participate in the same underlying payment system;
merchant acceptance depends on acquiring/provider arrangements;
the merchant should not build reporting around one consumer app brand when the payment method is UPI itself.
A useful mental model is:
UPI = infrastructure and scheme
UPI app = customer interface
Merchant provider = acceptance layer
UPI is not simply a wallet
The word “wallet” can imply that the customer is paying from value stored inside a particular application.
That is not a reliable description of UPI.
UPI is fundamentally built around interoperable account-based payment initiation. NPCI's current UPI materials also support additional eligible account types and products, so merchants should avoid an equally rigid claim that every UPI transaction is always funded by one conventional current or savings bank account.
The merchant-level distinction is more useful:
A wallet may be a proprietary payment account or credential environment.
UPI is an interoperable payment system through which participating applications and financial institutions initiate account-based payments.
That is why accepting one UPI app is not conceptually equivalent to accepting UPI.
UPI is not a card transaction
The customer does not generally authorize a UPI payment by giving the merchant a PAN, expiry date, and card security code.
The payment moves through UPI's participating financial institutions rather than through a card-network authorization flow.
That changes:
customer initiation;
authentication;
payment identifiers;
confirmation states;
dispute mechanics;
merchant reconciliation;
potential recurring-payment architecture.
It also means a merchant should not assume that UPI performance can be analyzed using exactly the same funnel as cards.
A card authorization rate and a UPI completion rate are not interchangeable metrics.
UPI IDs, intent, QR, and ecommerce initiation
There is no single universal UPI checkout screen.
NPCI documents multiple merchant integration modes, including:
QR;
intent;
application-based flows;
collect/payment-request flows.
The appropriate experience depends on device, provider implementation, and current scheme requirements.
UPI ID / Virtual Payment Address
A UPI ID—often described as a virtual payment address or VPA—provides an addressable identifier for a customer's UPI account relationship.
In a classic collect-style ecommerce flow, a merchant may request a UPI ID and create a payment request that appears inside the customer's UPI environment for authorization. NPCI's public merchant FAQ describes this type of online merchant payment flow.
Merchants should verify whether this exact flow remains recommended or enabled in their current provider implementation rather than preserving older UPI-ID collection UX by default.
Intent
Intent-based initiation is particularly relevant to mobile ecommerce.
The merchant or payment application hands the payment request into a UPI-capable application on the customer's device, where the customer selects or confirms the account and authenticates.
Intent can reduce the need to type a UPI ID manually.
But “supports UPI” does not automatically mean a provider supports every intent-based experience across:
native app;
mobile web;
in-app browser;
Android;
iOS.
Test the actual customer device mix.
QR
QR is another UPI initiation mechanism.
A merchant can create a transaction-linked QR experience that the customer's UPI application reads.
For ecommerce, this may be especially useful in desktop-to-mobile or cross-device flows.
But the existence of QR within UPI does not mean:
UPI = QR payment.
QR is one initiation interface into the underlying system.
The device distinction
A useful implementation rule is:
Mobile checkout: test intent/app handoff first.
Desktop checkout: test QR or another cross-device path.
Fallback: verify what the provider offers when an app cannot be launched.
The best UPI implementation is not the one with the largest number of initiation modes.
It is the one that gives the merchant's actual Indian customer/device cohorts a reliable path to completion.
Authentication happens inside the customer's UPI environment
The merchant should not authenticate the customer's UPI transaction itself.
In the conventional UPI model, the customer authorizes the transaction using their UPI PIN through the relevant UPI/bank environment. NPCI defines the UPI PIN as a 4- or 6-digit passcode used to authorize UPI transactions.
But even the statement “UPI always uses a PIN” is becoming too rigid.
NPCI introduced optional on-device biometric authentication as an alternative authorization mechanism for eligible UPI transactions in 2025. Effective August 7, 2026, NPCI increased the applicable per-transaction ceiling for that on-device biometric option to ₹10,000, subject to participating app/bank support and the applicable scheme conditions. UPI PIN remains an available authentication route.
For merchants, the technical point is not whether the customer taps a fingerprint sensor or enters a PIN.
It is the control boundary:
The customer's bank/UPI environment authenticates and authorizes the payment. The merchant receives payment state through its acquiring or provider integration.
Authentication completed is therefore not the same event as:
merchant order safely fulfilled.
How does an international merchant get access to UPI?
This is the point at which consumer ubiquity stops being sufficient evidence.
NPCI's merchant guidance describes domestic merchant acceptance through an acquiring-bank relationship. The acquiring bank performs merchant compliance and risk checks and provides UPI merchant infrastructure.
An overseas ecommerce merchant, however, introduces a cross-border payments layer.
RBI's framework for cross-border payment aggregators allows qualifying payment aggregators to facilitate collection for imports into India, including arrangements in which the aggregator onboards overseas merchants or contracts with foreign ecommerce/payment entities. Customer funds can move through regulated collection structures before onward settlement to the foreign merchant.
RBI subsequently consolidated online, physical, and cross-border payment-aggregator regulation under its 2025 framework.
The practical merchant architecture can therefore look like:
Indian customer
→ UPI app / bank
→ UPI
→ merchant acquirer / regulated payment aggregator
→ cross-border collection and settlement structure
→ international merchant
The merchant usually does not gain international UPI acceptance simply because it opens a UPI account or adds a QR image to checkout.
It needs an eligible acceptance path.
International-merchant questions to answer first
Before development begins, establish:
Who is the acquiring/payment-aggregation entity?
Is it currently authorized for the required model?
Can it onboard the merchant's country and legal entity?
Is the merchant's product or MCC/category allowed?
Is the transaction classified and processed correctly for cross-border ecommerce?
What currencies can customers pay in?
What currency does the merchant receive?
Who performs merchant KYB and risk approval?
Who owns UPI payment status?
Who processes refunds?
Who reconciles transactions?
Who settles the merchant?
If those questions are unanswered, “UPI integration” has not yet been scoped.
International UPI acceptance is not one single concept
UPI now has several international dimensions, and merchants should not collapse them.
RBI reports that QR-based UPI merchant acceptance for Indian users is operational in multiple overseas jurisdictions, including countries such as Bhutan, France, Mauritius, Nepal, Qatar, Singapore, Sri Lanka, and the UAE.
That means an Indian traveler may be able to use UPI with participating physical merchants abroad.
But this is not automatically the same thing as:
an international ecommerce merchant accepting UPI from an Indian customer online.
The important distinction is:
UPI abroad for an Indian traveler
versus:
UPI online for an Indian customer paying a foreign ecommerce merchant
versus:
UPI for a domestic Indian merchant
These can involve different acquiring, regulatory, settlement, and provider models.
Never use evidence for one to prove merchant access to another.
The customer journey
A simplified international ecommerce journey can look like this:
Customer reaches merchant checkout
The merchant determines that UPI is a relevant and available method for the session.
Customer selects UPI
The merchant/provider creates the relevant payment request.
Customer moves into a UPI-capable experience
Depending on the implementation, this may occur through:
app intent;
UPI ID/payment request;
QR;
provider-hosted flow.
Customer reviews payment
The UPI app/bank environment identifies the merchant/payment request and amount.
Customer authenticates and authorizes
This normally occurs within the UPI environment using UPI PIN or another currently supported authentication mechanism.
The UPI transaction is processed
The customer's participating bank and beneficiary/acquiring side exchange payment messages through UPI.
Provider receives payment state
The merchant's acquiring/payment provider determines whether the payment has reached the required authoritative state.
Merchant links payment to order
The merchant matches provider payment ID, its own order/payment identifier, amount, customer/session information, and transaction state.
Merchant fulfills
Only after the required authoritative payment state is obtained should the merchant treat the order as paid.
Merchant is settled according to its provider arrangement
For an international merchant, payout may occur separately from the underlying customer payment and may involve cross-border collection accounts, FX, settlement cycles, or provider batching.
That final distinction is essential:
Real-time UPI payment processing does not mean real-time payout to an overseas merchant.
Payment confirmation: what state should the merchant trust?
A customer can see a positive result while the merchant still needs to determine what to do with the order.
NPCI's UPI support framework recognizes successful, pending, and failed transaction outcomes rather than treating every initiated transaction as complete.
Merchant systems should therefore distinguish at least:
Created
Payment request exists.
Customer action required
Customer has not yet authorized.
Processing / pending
The payment is not yet in the state required for fulfillment.
Successful / completed
The provider has received an authoritative success state appropriate for the merchant implementation.
Failed / expired
The payment should not create a paid order.
Actual status names vary by provider.
The engineering rule is more important than the vocabulary:
Do not infer payment success from method selection, app launch, customer return, or a frontend success screen. Fulfill from the authoritative payment-status event defined by the provider's UPI implementation.
For higher-value, digital-delivery, gaming, travel, or fraud-sensitive goods, this boundary becomes especially important.
Confirmation is not settlement
UPI is described and operated as a real-time payment system.
But several different times exist inside the merchant lifecycle:
Customer authorization time
UPI processing time
Provider confirmation time
Merchant order-confirmation time
Scheme/participant settlement
PSP payout time
Cross-border merchant settlement
These are not synonymous.
NPCI's operating model includes multiple UPI settlement cycles between scheme participants, while RBI's cross-border payment-aggregator framework separately governs collection and onward settlement structures for foreign merchants.
Therefore a marketing statement such as:
“UPI settles instantly”
is too imprecise for an international merchant guide.
A safer formulation is:
UPI can provide real-time or near-real-time customer-payment processing and merchant payment confirmation, while actual merchant payout depends on the acquiring/payment-provider and cross-border settlement arrangement.
Refunds: do not infer them from the payment rail
A completed UPI payment and a merchant refund are separate processes.
Merchants should verify:
whether refunds can be initiated by API;
full refunds;
partial refunds;
multiple partial refunds;
refund time limits;
whether the original transaction reference is required;
expected customer-visible timing;
what happens if the refund cannot be completed;
how refunds appear in settlement and reconciliation.
The exact implementation may vary by provider.
A merchant should therefore test the actual refund path supplied by its provider rather than assuming:
“UPI went directly to a bank account, so refunds automatically reverse through the same path.”
Refunds are not failed-transaction reversals
A second distinction matters.
India's payment framework contains rules and processes for failed digital-payment transactions, including prescribed turnaround times and automatic reversal/compensation in relevant scenarios.
That is different from:
Merchant refund
The merchant intentionally returns money after a valid completed purchase.
Failed-payment reversal
A payment did not complete correctly and funds are reversed under the payment-system process.
Customer dispute or complaint
The customer challenges a payment or service outcome through an applicable complaint/dispute route.
Those operational queues should not be merged in merchant reporting.
UPI does not eliminate fraud or disputes
UPI's bank-side customer authentication can reduce some forms of credential-entry risk.
It does not make the method fraud-free.
RBI specifically identifies authorised push-payment fraud as an ongoing digital-payment challenge.
Relevant risks can include:
account takeover;
social engineering;
customer deception;
merchant impersonation;
manipulated payment requests;
fraudulent refund requests;
false screenshots or customer claims of payment;
mule accounts.
Merchants should also avoid the generic claim that UPI is “chargeback-free.”
That again demonstrates why provider-specific merchant operations matter.
The correct risk question is not:
Does UPI have card chargebacks?
It is:
Which fraud, dispute, reversal, complaint, and liability processes apply to this merchant's UPI acceptance model?
UPI AutoPay: recurring UPI exists, but it is not automatically available to the merchant
One-time UPI acceptance does not establish recurring-payment capability.
NPCI operates UPI AutoPay for recurring e-mandates. Its documented use cases include subscriptions, utility payments, insurance, EMIs, and other recurring obligations. Customers can create, pause, modify, or revoke eligible mandates through supported UPI experiences.
RBI's Digital Payments – E-mandate Framework, 2026 applies to recurring transactions using instruments including UPI. It requires an appropriate mandate and authentication framework and defines current rules around registration, pre-debit notification, additional-factor authentication, and applicable transaction thresholds.
This makes UPI potentially relevant for some subscription models.
But the merchant still has to establish:
Does our provider expose UPI AutoPay?
Can our merchant entity use it?
Does it work cross-border in our specific acceptance model?
Which customer accounts/apps are eligible?
How are failed recurring debits handled?
How are mandates cancelled or expired?
Can our billing system consume the required mandate and payment states?
That is a valuable merchant lesson:
The UPI ecosystem supports recurring payment products. Your provider's UPI integration may not.
Never use scheme-level capability to promise provider-level functionality.
Reconciliation: the payment has to become an order
One of the least glamorous pieces of UPI integration is also one of the most commercially important.
A merchant needs to connect:
Checkout session
→ merchant payment/order ID
→ provider payment ID
→ UPI transaction/reference information
→ authoritative status
→ settlement record
→ refund or dispute if one occurs
Without this chain, finance and customer support eventually encounter cases such as:
customer says UPI succeeded but no order exists;
merchant has a payment but cannot match it to checkout;
duplicate attempts exist;
payment remains pending;
customer paid an unexpected amount;
refund exists but finance cannot link it to original payment;
provider payout aggregates multiple transactions.
The merchant therefore needs more than a successful UPI button.
It needs a reconciliation model.
Core reconciliation controls
Unique merchant payment identifier
Every attempt should map to a deterministic merchant-side payment record.
Provider payment identifier
Store the provider's canonical transaction ID.
UPI/scheme reference where provided
Retain scheme/reference information required for support and reconciliation.
Status history
Do not overwrite all states with one final boolean.
Amount and currency
Validate against the merchant order.
Settlement linkage
Finance should be able to link individual transactions to provider payout/reconciliation records.
Refund linkage
Refund records should reference the original transaction.
Duplicate detection
A customer retry should not automatically create duplicate fulfillment.
Cross-border settlement deserves its own check
A customer's UPI payment can be denominated and processed within the Indian payment environment while the international merchant ultimately requires settlement into another legal entity, bank account, or currency.
RBI's cross-border aggregator framework separates the customer collection process from onward transfer to foreign merchants.
An international merchant should therefore document:
customer payment currency;
merchant settlement currency;
who performs FX;
applied FX basis or markup;
settlement frequency;
settlement account;
reserves or holds if any;
payment-to-payout reconciliation;
refunds after currency conversion;
tax/accounting data;
cross-border reporting requirements.
This belongs to the merchant settlement layer.
It should not be inferred from UPI's customer-facing speed.
The UPI International Merchant Readiness Checklist
Use the checklist as eleven gates from customer relevance to commercial proof.
Readiness dimension
Merchant question
Evidence required
Failure implication
Indian customer share
Do we have enough commercially meaningful India demand to justify UPI?
India checkout sessions, revenue, failed payments, customer research
Weak demand = lower priority
Merchant category
Is our product/category acceptable for the proposed UPI/cross-border model?
Provider/acquirer confirmation, MCC/category review
Potential launch blocker
Provider access
Does our PSP/PA/acquirer support UPI for this exact merchant model?
Current production documentation and contractual confirmation
Launch blocker
Merchant eligibility
Can our legal entity and country be onboarded?
KYB/underwriting outcome, current provider rules
Launch blocker
Checkout flow
Which UPI flow fits mobile and desktop customers?
Intent, QR, UPI-ID/hosted flow testing
Poor completion risk
Customer app handoff
Can eligible customers reach and return from their UPI app reliably?
Device/app/browser tests
Major mobile failure risk
Confirmation
What authoritative event marks the payment safe for fulfillment?
API/webhook/status specification, pending-state tests
Launch blocker
Refunds
Can expected full/partial refunds be processed and reconciled?
Provider API tests and finance workflow
Operational risk
Recurring requirements
Does the merchant need AutoPay or another recurring model, and is it supported?
Provider capability + mandate lifecycle
Hard gate for subscription use cases
Reconciliation / settlement
Can finance match every payment, refund, and payout?
Transaction/reference mapping, payout files, FX/settlement terms
Significant operating risk
Performance measurement
Does UPI create incremental completed orders or valuable customer access?
Segmented merchant data / controlled rollout
Determines long-term priority
Readiness classification
Use:
Green — verified and production-ready
Amber — available in principle but dependent on provider, contract, testing, or current scheme rules
Red — unavailable, unsupported, or incompatible
Do not average away a red result.
Provider access, merchant eligibility, and authoritative payment confirmation are hard gates.
For subscriptions, recurring support becomes another hard gate.
Which merchants should prioritize UPI?
Consumer ecommerce serving material India traffic
Priority hypothesis: High
The scale and prevalence of UPI make it a strong early investigation candidate for a merchant with substantial Indian consumer traffic. RBI's current data demonstrate that UPI is central to India's retail-payment environment rather than a peripheral method.
That still does not prove that UPI is incremental for the individual merchant.
Measure it.
Gaming and digital goods
Priority hypothesis: High for one-time mobile purchases
Gaming and digital services can align well with UPI's mobile-account payment behavior because customers can approve a payment in an existing UPI environment rather than provide card credentials.
But these merchants should test:
app handoff;
authorization completion;
immediate entitlement;
duplicate prevention;
low-ticket economics;
fraud;
refund operations.
If virtual goods are delivered immediately, authoritative payment confirmation is particularly important.
SaaS and subscriptions
Priority hypothesis: Conditional
UPI's overall customer relevance may be strong.
The actual subscription decision depends on UPI AutoPay and, more importantly, whether the merchant's provider exposes the necessary mandate functionality for the merchant's cross-border model.
A provider offering one-time UPI but no recurring UPI can still be valuable for:
prepaid subscription terms;
one-time upgrades;
credits;
annual manual renewal.
But it may not solve automated recurring billing.
Do not force a one-time payment method into a recurring business model.
Travel
Priority hypothesis: Potentially high, operationally demanding
Travel merchants can benefit from giving Indian customers a familiar account-based payment route, particularly where card usage or card limits otherwise create payment friction.
But the merchant must test:
high transaction values;
confirmation;
delayed fulfillment;
cancellations;
partial refunds;
cross-border settlement;
fraud/dispute handling.
A successful booking payment is only half the lifecycle.
B2B and education
Priority hypothesis: Use-case specific
Account-based payment access can be attractive for larger transactions.
But UPI suitability should be tested against:
current transaction rules and limits;
invoice/reconciliation requirements;
payer type;
provider support;
bank transfer alternatives;
cross-border settlement needs.
High transaction value alone does not make UPI the correct method.
These details are useful because they illustrate the difference between:
UPI scheme capability
and:
For example:
UPI ecosystem: AutoPay exists.
The safe merchant message is:
A global payments provider can potentially abstract the acquiring, UPI connectivity, transaction-state, refund, and cross-border settlement work required for acceptance—but merchants must verify that the provider's current UPI product supports their exact entity, country, category, flow, and billing model.
Measure UPI through completed orders, not UPI clicks
The UPI funnel should be measured explicitly:
Relevant India checkout session
→ UPI available
→ UPI visible
→ UPI selected
→ UPI flow initiated
→ app/QR/VPA step completed
→ customer authentication completed
→ authoritative UPI payment success
→ payment linked to order
→ order completed
A merchant can have high UPI selection and weak UPI performance.
For example:
app handoff can fail;
customer may abandon authentication;
pending status may be mishandled;
successful payment may fail to create the order;
reconciliation can break;
method volume may simply move from cards.
UPI payment completion rate
Successful UPI payments
÷ eligible UPI payment initiations
× 100
Define “successful” using the provider's authoritative completion state.
App-handoff completion rate
Customers reaching the required UPI authorization stage
÷ UPI flows that attempted app/QR/other handoff
× 100
Segment heavily by:
operating system;
mobile web versus native app;
browser;
UPI initiation flow.
Authentication completion rate
UPI authorizations completed
÷ customers reaching the UPI authentication step
× 100
Do not confuse authentication success with final order completion.
Order-linkage success
Successful UPI payments automatically linked to a valid merchant order
÷ successful UPI payments
× 100
For digital goods, this should be extremely close to complete.
Anything less represents an operational problem even if the payment rail itself works perfectly.
Unmatched payment rate
UPI payments that cannot be automatically linked to the correct merchant payment record
÷ received successful UPI payments
× 100
This is one of the best reconciliation-health metrics.
Confirmation latency
Measure elapsed time from a precisely defined customer authorization point to the provider's authoritative merchant success state.
Do not label merchant payout latency as UPI confirmation latency.
UPI completed-order contribution
Orders paid with UPI
÷ eligible completed orders
This measures contribution.
It does not measure incrementality.
The UPI incrementality test
The strongest merchant hypothesis is:
Offering UPI to relevant Indian customers will increase completed orders or unlock commercially important customer access beyond what the existing portfolio provides.
Test that hypothesis using an eligible India cohort.
Compare:
UPI available versus unavailable where experimental design permits;
mobile versus desktop;
new versus returning customers;
customer acquisition channels;
transaction-value bands;
one-time versus recurring use cases;
existing card success;
provider/flow variants.
Measure:
total completed-order rate;
UPI completion;
payment failure;
checkout abandonment;
customer support;
refund rate;
fraud/dispute loss;
transaction and operating cost.
What would disprove the hypothesis?
If UPI gains significant payment share but:
total completed orders do not improve;
nearly all users were already successful card customers;
app/authentication failures materially increase;
reconciliation becomes problematic;
cost or support burden outweighs customer value,
the merchant should not claim UPI generated conversion uplift.
It may still provide customer preference, retention, or strategic local relevance.
Those are separate benefits.
Merchant-readiness questions
Is UPI a wallet?
No. UPI is an interoperable payment system operated by NPCI. Customers interact with it through UPI-enabled apps, but those apps are interfaces to UPI rather than the UPI system itself.
Can a foreign ecommerce merchant accept UPI?
Potentially, through an eligible acquiring/payment-aggregation or other approved cross-border acceptance arrangement. RBI's cross-border payment-aggregator framework allows regulated intermediaries to collect Indian payments for qualifying overseas merchants, subject to the applicable merchant, transaction, compliance, and settlement requirements.
The merchant must verify its own eligibility with the provider.
Does the merchant need to integrate every UPI app separately?
Generally no. UPI is interoperable, and the merchant acceptance layer connects into UPI rather than requiring a separate commercial integration with every consumer UPI application. The exact app coverage and flow should still be verified with the merchant's provider.
What is a VPA or UPI ID?
It is an address used within the UPI ecosystem to identify the customer's payment relationship without requiring ordinary bank-account details to be entered into the merchant checkout.
Is UPI always QR based?
No. NPCI documents QR, intent, application, and payment-request/collect-style merchant flows. QR is one initiation mechanism rather than the definition of UPI.
Does every UPI transaction require a UPI PIN?
UPI PIN remains a standard customer authorization mechanism, but NPCI now permits optional on-device biometric authentication for eligible transactions and participating implementations. Effective August 7, 2026, NPCI raised the relevant biometric per-transaction ceiling to ₹10,000.
Is UPI payment confirmation the same as settlement to an international merchant?
No. UPI can provide real-time transaction processing, while an international merchant's settlement follows the acquiring/payment-provider and cross-border payout arrangement.
Can UPI support subscriptions?
The UPI ecosystem supports recurring e-mandates through UPI AutoPay, and RBI's current e-mandate framework covers UPI. Provider and merchant implementations vary, however.
Are UPI payments chargeback-free?
Final recommendation
UPI's importance to international merchants does not come from the fact that it is “another payment method.”
It comes from the way it reorganizes the customer's starting point.
For a large population of Indian customers, the natural digital-payment environment begins with:
bank or eligible financial account
→ mobile device
→ UPI-enabled app
→ UPI authorization
not:
card
→ PAN
→ expiry date
→ security code
RBI's current evidence makes the scale of that behavior difficult to dismiss: UPI represented nearly 86% of India's retail-payment transaction volume in FY2025–26, and the central bank's nationwide survey identified it as the predominant digital mode among both users and accepting merchants.
But consumer scale is only the first half of the international-merchant decision.
The merchant must still prove:
Can our entity accept UPI?
Which regulated/provider path enables it?
Does our customer-device flow work?
Which status is authoritative for fulfillment?
Can we issue the refunds our business requires?
Can we support AutoPay if recurring billing matters?
Can finance reconcile UPI payments to cross-border settlement?
Does UPI add completed orders or meaningful customer access rather than merely moving existing card customers?
For international merchants with material India demand, UPI should usually be researched early.
It should be launched only when the complete chain works:
Customer access → eligible merchant → reliable UPI initiation → authoritative confirmation → order reconciliation → workable refunds/recurring model → settlement → measurable commercial contribution.
That is what turns UPI from an impressive Indian payment statistic into a functioning international merchant payment method.
The strongest differentiator in this version is the explicit separation of UPI → UPI app → initiation flow → merchant acquiring/provider → cross-border settlement. That prevents the article from repeating either a generic UPI explainer or the broader A2A/real-time-payment articles.
Original practical asset: UPI Customer-to-Merchant Flow
Supporting visual
Design a left-to-right infrastructure diagram with five distinct layers.
Layer 1 — Customer
Indian customer
Funds/account available
↓
UPI-enabled app
Examples should be labeled generically rather than making one consumer app look like the UPI system.
Layer 2 — Initiation
Branch into:
Intent / app handoff
UPI ID / VPA
Dynamic or transaction QR
Then converge into:
Customer reviews transaction
↓
UPI PIN or supported authentication
Layer 3 — UPI ecosystem
Payer PSP / bank
↓
UPI / NPCI
↓
Payee/acquiring participant
Layer 4 — International merchant access
Payment aggregator / acquiring provider
↓
Authoritative payment status
↓
Cross-border collection / merchant settlement
Layer 5 — Merchant
Payment record
↓
Order match
↓
Fulfillment
↓
Refund / reconciliation / reporting
Across the bottom place three warning bars:
UPI app ≠ UPI system
Payment confirmation ≠ merchant payout
Consumer UPI availability ≠ foreign merchant eligibility
Image alt text
“UPI international merchant payment flow showing an Indian customer using a UPI app through intent, UPI ID, or QR, authentication through the UPI ecosystem, payment-provider confirmation, cross-border settlement, and merchant order reconciliation.”
Compact rail-versus-interface map
Layer
Example function
Merchant implication
Customer account
Source of funds/value
Customer already has payment access
UPI app
Customer interface and initiation
Do not treat one app as UPI itself
UPI ID / intent / QR
Initiation/addressing mechanism
Choose flow based on device/provider
UPI
Interoperable payment system
Moves payment messages between participants
Bank / PSP participants
Customer authorization and transaction execution
Merchant does not control bank authentication
Acquirer / PA / PSP
Merchant access, payment status, potentially refunds and settlement
Critical international merchant dependency
Cross-border settlement layer
Collection/FX/onward merchant payout
Separate from UPI payment speed
Merchant platform
Order state, fulfillment, reconciliation
Merchant remains responsible for payment-to-order integrity
UPI for International Merchants — Editorial & Publication Package
Editorial interpretation
Editorial decision
Direction
Bank-payment decision this article owns
Whether and how an international merchant should give Indian customers access to UPI, including the provider, merchant-eligibility, customer-flow, confirmation, refund, recurring, reconciliation, and settlement requirements behind acceptance.
Customer who cannot adequately pay without this capability
An Indian customer with funds in an eligible financial account and a UPI-enabled app who expects to authorize payment through UPI rather than enter card credentials.
Payment rail / system
UPI is an interoperable real-time payment system operated by NPCI.
Customer initiation layer
A UPI-enabled app can initiate through mechanisms including UPI IDs/virtual payment addresses, app intent, and QR-based experiences.
Merchant-facing product
The merchant normally receives UPI through an acquiring bank, payment aggregator, PSP, or cross-border payment-provider arrangement rather than treating a consumer UPI app as the merchant integration.
Unique evidence anchor
UPI represented nearly 86% of India's retail-payment transaction volume in FY2025–26, and RBI's nationwide survey found UPI predominant among both digital-payment users and accepting merchants. This supports treating UPI as core Indian payment infrastructure rather than merely another wallet option.
Editorial position
Merchants with material Indian customer demand should investigate UPI early, but customer ubiquity must not be confused with international merchant eligibility or production access.
Common assumption challenged
“UPI is just one more wallet.”
Most important technical distinction
UPI is the payment system; a UPI app is an initiation interface. Payment confirmation, merchant settlement, and international merchant access are separate layers again.
Selected format
Infrastructure-to-merchant-readiness guide.
Merchant decision
For an international consumer merchant with meaningful India demand, UPI should generally enter the first tier of payment-method investigation.
It becomes a strong launch candidate when:
the merchant serves a material Indian customer population;
its legal entity and merchant category can be onboarded through an eligible provider;
the selected provider supports the necessary UPI checkout flow;
payment confirmation can be mapped reliably to orders;
required refunds are operable;
recurring functionality is available if the business model needs it;
cross-border settlement and reconciliation are acceptable;
testing shows incremental completed-order or customer-access value.
UPI should not be declared “launch ready” simply because Indian consumers use it at enormous scale.
Proposed architecture
The customer already has the payment account they want to use
What UPI actually is
UPI versus UPI apps, wallets, and cards
UPI IDs, intent, QR, and online initiation
How international merchants get access
The customer journey
Authentication and authoritative payment confirmation
Refunds, failed transactions, fraud, and disputes
UPI AutoPay and recurring payments
Reconciliation and settlement
UPI International Merchant Readiness Checklist
Which merchants should prioritize UPI
How to measure whether UPI creates incremental value
Merchant-readiness questions
Final recommendation
SEO metadata
UPI for International Merchants: India Payment Guide
H1:
UPI for International Merchants: How to Reach India’s Account-to-Account Payment Users
Meta description:
Learn how international merchants can evaluate UPI for India, including UPI apps, VPA, intent and QR flows, merchant eligibility, payment confirmation, refunds, AutoPay, reconciliation, and settlement.
URL slug:
/bank-based-payments/upi-for-international-merchants/
UPI for international merchants
Secondary keywords:
accept UPI internationally
UPI merchant payments
UPI ecommerce
UPI international merchant
UPI integration
UPI online payments
India UPI merchant
accept UPI payments
Related entities:
NPCI
RBI
Unified Payments Interface
UPI ID
Virtual Payment Address
UPI PIN
UPI intent
UPI QR
UPI AutoPay
Payment Aggregator
PA-CB
account-to-account payments
real-time payments
BHIM
Article excerpt:
UPI is not just another wallet button for India. It is core account-based payment infrastructure used through interoperable apps and bank relationships. International merchants should evaluate UPI early for meaningful Indian demand—but only after confirming merchant eligibility, provider access, customer initiation, payment confirmation, refunds, recurring requirements, reconciliation, and cross-border settlement.
Suggested structured data:
Article
BreadcrumbList
FAQPage should be considered only if the merchant-readiness questions remain visibly published and current search-engine guidance supports the markup.
Internal-link plan
Internal article
Context
India Payment Guide
Link when readers need India's complete cards, wallets, bank payments, cash, regulation, and broader method portfolio
Real-Time Payments Explained
Link when explaining what “real time” means at rail, confirmation, settlement, and payout layers
Account-to-Account Payments
Link from UPI's account-based payment model
Digital Wallets / Wallet Acceptance
Link when explaining why a UPI app should not automatically be treated as a stored-value wallet
Payment Methods by Country
Link when moving from UPI itself to full India method prioritization
Payment Localization
Link for method placement and localized checkout presentation rather than duplicating those topics here
Authoritative source recommendations
NPCI — UPI product documentation
Use for:
UPI architecture;
participants;
VPA / UPI IDs;
intent and QR;
merchant initiation modes;
customer authentication;
current operating features.
NPCI — UPI Product Statistics
Use for current monthly transaction volume, value, and participating-bank figures. June 2026 data report approximately 22.7 billion transactions.
RBI Annual Report 2025–26
Use for:
UPI's share of retail-payment transaction volume;
FY2025–26 volume/value growth;
current digital-payment survey results;
payment-aggregator regulatory developments;
cross-border UPI expansion;
current fraud context.
RBI payment-aggregator / cross-border framework
Use for:
PA-CB model;
overseas merchant onboarding;
import collection structure;
onward settlement to foreign merchants.
NPCI UPI AutoPay
Use for UPI recurring mandate functionality and customer mandate controls.
RBI Digital Payments — E-mandate Framework, 2026
Use for current recurring-payment authentication, mandate, notification, and applicable threshold requirements.
NPCI authentication circulars
Use for current UPI PIN and optional biometric-authentication capability. The latest material should be rechecked immediately before publication because NPCI changed the biometric threshold effective August 7, 2026.
UPI product availability;
processing currency;
confirmation;
refunds;
chargebacks;
recurring support;
onboarding model.
Proposed author and reviewers
Proposed author
Do not assign a person's name until they have actually accepted authorship.
Proposed reviewers
India payments specialist
Review:
current UPI market behavior;
merchant acceptance;
India terminology;
provider/regulatory context.
UPI product or payment engineer
Review:
intent;
QR;
UPI ID;
authentication;
authoritative status;
transaction IDs;
integration behavior.
Payment operations / treasury reviewer
Review:
refunds;
failed transactions;
reconciliation;
disputes;
cross-border settlement.
Compliance/regulatory reviewer
Review any specific interpretation of RBI payment-aggregator or cross-border requirements.
Do not claim reviews have occurred until they actually have.
Pre-publication fact-check matrix
Rail / scheme facts
Immediately verify:
current NPCI UPI transaction data;
bank/participant count;
current UPI product terminology;
current VPA/UPI ID rules;
intent availability;
QR specifications;
collect/payment-request rules;
transaction limits where material;
authentication requirements;
optional biometric rules;
any new UPI Circle, credit-line, PPI, or related feature that materially changes the article.
Country facts
Verify:
UPI's latest share of Indian retail-payment volume;
current ecommerce/merchant evidence;
RBI payment-aggregator rules;
international UPI acceptance jurisdictions;
India cross-border payments requirements.
Do not convert UPI's national transaction share directly into ecommerce market share.
Merchant-eligibility facts
merchant domicile;
legal entity;
MCC/category;
restricted/prohibited goods;
India customer eligibility;
PA/acquirer relationship;
cross-border authorization;
KYB requirements;
onboarding route.
Confirmation / reconciliation facts
Verify:
current provider status names;
webhook/callback behavior;
polling/status-query fallback;
authoritative fulfillment state;
transaction/reference fields;
duplicate handling;
expiry;
pending transactions;
settlement-file identifiers.
Refund facts
Verify:
full refund;
partial refund;
multiple refunds;
API/manual;
refund window;
refund status;
failed refund;
customer-visible timing;
FX implications.
Recurring facts
Verify:
UPI AutoPay support by provider;
international merchant eligibility;
mandate registration;
fixed/variable payments;
authentication;
pre-debit notification;
retry behavior;
cancellation/revocation;
failed collection;
current amount thresholds.
Do not infer provider AutoPay support from NPCI's existence of AutoPay.
Regulatory facts
Verify:
current RBI Payment Aggregator Directions;
PA-CB requirements;
customer due diligence;
merchant due diligence;
import/export classification if applicable;
transaction caps where applicable;
cross-border settlement requirements;
permitted currency structures.
Disclaimer
This article provides general information and does not constitute legal, regulatory, banking, tax, security, or compliance advice. Merchants should verify applicable requirements with qualified advisers, relevant payment providers, banks, scheme operators, and authorities.
Amber-flag claims
Claim
Why it must be reverified
UPI monthly transaction volume
Changes every month
UPI share of Indian retail-payment transactions
Changes by financial year
Number of banks live on UPI
Changes frequently
Customer/merchant survey adoption
Period-specific survey evidence
UPI international merchant-access models
Regulatory/provider dependent
Overseas QR acceptance countries
Expanding internationally
UPI ID/VPA requirements
NPCI rules can change
Intent/collect flow availability
Product/provider rules evolve
UPI biometric-authentication threshold
Changed as recently as August 7, 2026
UPI transaction limits
Product/category/use-case dependent
UPI AutoPay rules
Scheme and RBI rules evolve
E-mandate AFA thresholds
Regulation can change
Refund capability
Provider specific
Refund window
Provider specific
Dispute / chargeback treatment
Provider and transaction-model specific
Merchant category eligibility
Provider/acquirer/risk dependent
Cross-border merchant countries
Provider/product dependent
Settlement timing
Contract specific
FX and payout currencies
Provider specific
Current page says no; product can change
Commercially consequential and should be internally confirmed
Before publication, obtain internal confirmation of:
Which merchant domiciles are eligible?
Are U.S. and U.K. ecommerce merchants currently enabled under the previously announced NIPL partnership?
Which additional foreign merchant countries are supported?
Which merchant categories/MCCs are eligible?
Which categories are prohibited or subject to additional approval?
Is customer currency INR only?
Which settlement currencies are supported?
Who performs FX?
Which customer flows are currently supported: intent, UPI ID, QR, hosted redirect?
Mobile-web support.
Native-app support.
Desktop support.
Authoritative payment-success event.
Webhooks/callbacks.
Pending-state handling.
Full refunds.
Partial refunds.
Current refund window.
Chargeback/dispute workflow.
UPI AutoPay or other recurring capability.
Reconciliation identifiers.
Settlement frequency.
Reserves/holds where applicable.
Transaction fees.
Minimum/maximum transaction amounts.
Production activation timeline.
Current first-party UPI performance data, if any.
Approved merchant examples, if any.
Until those points are confirmed, do not claim:
universal foreign-merchant UPI access;
particular settlement currencies;
guaranteed instant merchant payout;
guaranteed conversion improvement.
Provider-specific verification template
Capability
Required answer
Provider / acquirer
Which regulated participant gives the merchant UPI access?
Merchant country
Is this entity domicile supported?
Merchant category
Approved?
Customer location
India only or other use cases?
Processing currency
INR / other?
Settlement currency
Which currency reaches merchant?
UPI flow
Intent / QR / VPA / hosted / other
Authentication
UPI PIN / supported alternatives
Authoritative confirmation
Exact API/status event
Pending handling
How resolved?
Refunds
Full / partial / period / API
Recurring
AutoPay? Exact model?
Disputes
Actual applicable process
Fraud controls
Merchant/provider responsibilities
Transaction limits
Per product/category
Reconciliation
Payment and settlement identifiers
Settlement
Timing, account, batching
FX
Party and commercial model
Activation
KYB, approvals, credentials, testing
Production status
Confirmed current capability
Measurement plan
Track at minimum:
Metric
Recommended denominator
UPI availability rate
Relevant Indian checkout sessions
UPI selection rate
Sessions where UPI was available and visible
UPI initiation rate
Sessions selecting UPI
Handoff success
UPI initiation attempts
Authentication completion
Customers reaching UPI authentication
UPI payment completion
Eligible initiated UPI payments
Order-linkage success
Successful UPI payments
Unmatched payment rate
Successful received UPI payments
Completed-order rate
Relevant Indian checkout sessions
Refund success rate
UPI refunds initiated
Support-contact rate
Completed/attempted UPI transactions, defined consistently
Incremental completed orders
Comparable eligible India customer cohort
Cost per completed order
Payment + operational cost / completed UPI orders
Segment by:
mobile versus desktop;
browser/app context;
transaction value;
new versus returning customer;
merchant vertical;
payment flow;
provider;
one-time versus recurring.
Cluster sameness-audit fields
Field
UPI article
Title
UPI for International Merchants: How to Reach India’s Account-to-Account Payment Users
First-two-sentence concept
Customer already has funds, an account, and a UPI app; the missing element is merchant access
Opening device
Payment-access contradiction rather than generic “UPI is huge” introduction
Primary country
India
Payment rail/system
UPI
Merchant-facing method
UPI merchant acceptance through eligible acquiring/payment-provider infrastructure
Primary format
Infrastructure-to-merchant-readiness guide
Unique evidence anchor
UPI is core customer payment behavior, not merely another wallet
Editorial position
Material India merchants should evaluate UPI early, while verifying cross-border merchant eligibility
Merchant decision
Evidence-gated early-launch candidate
Original framework
UPI International Merchant Readiness Checklist
Primary technical distinction
UPI system ≠ UPI app; payment confirmation ≠ settlement
Primary metric
Incremental completed orders among relevant India customers
Conclusion
UPI becomes a merchant capability only when customer access is connected through an eligible provider to reliable payment state, operations, and settlement
CTA concept
Verify merchant/provider eligibility, then test UPI on Indian customer/device cohorts
Closing element
Merchant-readiness questions
Adjacent territory intentionally excluded
Full India payment-method mix, generic real-time-payment theory, generic A2A, open banking, complete bank-payment cost comparison
Publication-level conclusion
UPI deserves early attention from international merchants serving India because it is core account-based payment infrastructure used at enormous scale—not because it is another wallet to add to a global logo grid. Its value becomes real only when the merchant can connect that customer behavior through an eligible provider to a reliable initiation flow, authoritative payment confirmation, workable refunds and recurring capability, accurate reconciliation, cross-border settlement, and measurable incremental completed orders.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗