Online Payment Gateway Service Provider (OPGSP) in India: What It Was and What Replaced It

An Online Payment Gateway Service Provider (OPGSP) was the route Indian exporters once used to collect small international payments through an intermediary tied to an authorised bank. It is worth being clear from the start: OPGSP is now a legacy framework.

The Reserve Bank of India (RBI) replaced it with the Payment Aggregator - Cross Border (PA-CB) regime, so if you are setting up cross-border collections today, you are looking for a PA-CB-authorised provider, not an OPGSP. If you are new to the space, it helps to first understand how cross-border payments work in India before you compare providers.

This guide explains what OPGSP meant, how the model worked while it was in force, the limits and roles involved, and exactly how and why it was superseded, so you can read older contracts and circulars correctly and know what applies to your business now.

OPGSP stands for Online Payment Gateway Service Provider. It was a category of intermediary that let Indian exporters, especially freelancers and small services businesses selling to overseas clients, receive export proceeds without each of them holding a direct foreign-bank relationship. The provider collected the funds abroad, moved them through a designated account, and settled them into the exporter's Indian bank account in rupees.

The RBI introduced the framework in 2010 and set out the operating conditions in a circular dated 24 September 2015. An OPGSP did not itself need a separate RBI authorisation. Instead, it had to work with an Authorised Dealer Category-I (AD-I) bank and operate through a dedicated collection account, with the bank carrying much of the compliance responsibility. In practice this made OPGSPs close cousins of payment aggregators, but built specifically for the cross-border export use case rather than domestic card payments.

Three parties sat in every OPGSP transaction, and it helps to see how they fit together.

• The exporter raised an invoice on an overseas buyer for goods or, more often, software and services.
• The OPGSP collected the payment abroad and pooled it, then passed it to a nostro or collection account.
• The AD-I bank received the funds, ran the compliance checks, applied the foreign exchange conversion, and credited the exporter's Indian account.

The exporter never dealt directly with foreign banking rails. That was the appeal: onboarding was quick, and the paperwork that normally comes with a SWIFT wire was handled upstream. For a small business, being able to receive international payments in india bank account without a heavy banking setup removed a real barrier to selling abroad.

The exporter did still have to be set up correctly on the banking side. That meant registering an AD code check with the bank branch handling the remittances, so exports were reported against the right authorised dealer. Even under a light-touch route, the compliance trail behind each payment had to hold up.

The OPGSP route was deliberately built for low-value trade, and the limits reflected that. Under the framework, an OPGSP could facilitate export receipts of up to USD 10,000 per transaction. A separate, lower cap applied to import-side payments, and the facility was restricted to specific categories rather than open to all trade.

Beyond the ceiling, exporters still had to meet the RBI's documentation requirements, including correct purpose coding of each inward remittance. Choosing the right code from the RBI purpose codes list mattered then and still matters now, because it tells the bank and the regulator what the payment was for. The OPGSP handled the collection, but the underlying export-compliance obligations stayed with the exporter and the bank.

The OPGSP model fit a specific profile: independent professionals and small services exporters whose individual invoices were modest but frequent. A designer billing a US client, a developer on an overseas retainer, or a small IT firm invoicing in dollars could collect through an OPGSP without opening foreign accounts or negotiating bank wires for each payment.

That is still the core audience for cross-border payments for service exporters, which is why the OPGSP idea mattered even though the framework itself has moved on. The need did not disappear when the rules changed. The route to meeting it did.

It is worth being honest about what OPGSP was not built for. It was never meant for high-value trade, treasury flows, or businesses shipping physical goods at scale. A consultancy invoicing a single overseas client for a large project would hit the ceiling immediately and have to fall back on a direct bank wire.

The framework worked precisely because it stayed in its lane: many small receipts, standardised handling, and a bank carrying the regulatory weight. Understanding that original design makes it easier to see why the RBI eventually wanted a framework that could carry more volume and more scrutiny at the same time.

The framework had real constraints, and they are part of why it was eventually replaced.

• Low transaction ceiling: The USD 10,000 export cap suited freelancers but did not scale for growing businesses, which quickly outgrew the limit.
• Narrow scope: OPGSP covered specific categories of goods and services, leaving gaps for many legitimate exporters.
• Thin direct oversight: Because OPGSPs were not authorised entities themselves, the RBI regulated them indirectly through banks, which gave it less visibility than it wanted as volumes grew.
• Inconsistent experience: Service quality and fees varied between providers, and exporters had little standing if something went wrong.

As cross-border e-commerce and services exports grew, these limits started to look dated, and the RBI moved to bring the whole activity under direct supervision.

It helps to see the two frameworks side by side, because the difference is not just a name change. The regime moved from indirect, bank-mediated oversight to direct licensing of the entity that touches your money.

For platforms and marketplaces that settle to many sellers, this shift matters even more, which is why the design of global payment aggregators now has to build directly on a PA-CB authorisation rather than a bank tie-up.

On 31 October 2023 the RBI issued its circular on the Regulation of Payment Aggregator - Cross Border (PA-CB), and this is what replaced the OPGSP framework. The shift was structural, not cosmetic. Where OPGSPs operated under a bank's arrangement, PA-CB providers must obtain direct authorisation from the RBI to operate at all.

The transition came with a hard deadline: existing OPGSPs and non-bank entities carrying on this activity had to apply for PA-CB authorisation by 30 April 2024, or stop. The PA-CB framework also created three clear categories of licence, export-only, import-only, or both, so a provider's permissions match what it actually does. On the money side, the circular set a per-unit cap of ₹25 lakh per unit of goods or services, a different and generally more workable basis than the old flat per-transaction limit.

If you want the full detail of the current rules, including net-worth requirements and escrow mechanics, the pacb guidelines by rbi opgsp update 2024 cover them, and the distinction between a merchant of record model and a payment-aggregator model is worth understanding through mor vs pa cb before you choose a provider.

The practical takeaway is simple. You cannot onboard to an OPGSP today, because the category no longer exists in its old form. What you should look for is a provider that holds a valid PA-CB authorisation, which is the RBI's assurance that the entity moving your money is directly regulated and supervised.

This is where checking your provider's licence status pays off. The detail behind Xflow holds PACB license shows it as a final authorisation from the RBI for both exports and imports, as of February 2026, which means collections run under the current framework rather than a grandfathered arrangement.

For a business that wants to collect international payments in India cleanly, the licence is not a technicality. It is what keeps your inward remittances compliant and your settlements predictable. A set of receiving accounts under a PA-CB provider does the collection job the old OPGSP did, at higher limits and with direct oversight.

One point that reassures exporters moving off older arrangements: the framework that authorises your provider changed, but your downstream export-compliance workflow did not. You still need proof of remittance, correct purpose codes, and the right treatment under GST.

Your bank or provider still issues an eFIRA as evidence that the foreign payment came in, which you use for GST refunds and other filings. The realisation and repatriation of export proceeds rules under FEMA continue to apply, and the treatment of your export of services under GST as a zero-rated supply is unaffected by which regime authorises your payment provider. The plumbing changed. Your obligations did not.

OPGSP was a useful bridge for a decade, letting small Indian exporters collect low-value international payments without direct foreign-banking relationships. It has been replaced by the PA-CB regime, which brings the same activity under direct RBI authorisation, raises the workable limits, and defines clear export and import licence categories.

If you are choosing how to get paid from abroad now, the question is not whether a provider is an OPGSP, but whether it holds a current PA-CB licence and handles your compliance cleanly. Platforms built for IT-enabled services exporters are designed around exactly that, and comparing how reduce international payment fees works across providers is the natural next step once compliance is settled.