The short answer: To charge an international customer every month, you take one payment where the customer is present and approves it. You save their card safely. After that, you charge the saved card yourself, on schedule, without asking them again. The customer is abroad, so their bank's rules apply to the approval, not India's. But the money lands in India, so India's paperwork rules apply to every single charge.

Three businesses, one problem

New Jersey to Pune: a son buying cover for his parents
He buys a health policy for his parents in India. The premium is due every year, sometimes every month. He is not going to re-enter his card each time. If one payment fails and nobody catches it, the policy lapses. His parents lose cover and nobody finds out until they need it.

Rishikesh to California: a yoga teacher with eight students
She teaches over video. Each student pays $60 a month. That is her income. If two payments quietly fail in March, she has lost a quarter of that month, and she may not even know why.

Bengaluru to Dubai and London: a fitness trainer running monthly plans
Every client is on a monthly programme. Getting the first sale is hard work. Losing the client in month four because a card expired is worse, because he never got the chance to keep them.

None of these three are big companies. All three depend on the same thing: a payment that has to work again next month, from someone in another country, without anyone doing anything.

That is what a subscription really is. Not a payment. A payment that has to keep happening.

Why this works differently from an Indian subscription

Ask an Indian team how to build this and the first thing they mention is the e-mandate. Standing instruction, OTP at setup, the 24-hour warning message, the ₹15,000 limit. Everyone who has built recurring payments for the Indian market knows these rules by heart.

Those rules are the right starting point for an Indian card. The picture changes when your customer is abroad.

Your customer is in New Jersey and their card was issued by a bank in the US. That bank is the one that approves each charge, notifies your customer and handles any opt-out, and it does so under the card networks' rules and the requirements of its own country. So the mechanics that decide whether your monthly charge goes through sit with Visa and Mastercard, and with whatever applies where your customer lives.

How it actually works

Three steps. Get any one wrong and the monthly charge starts failing.

Step 1: The first payment, with the customer watching

The customer enters their card and approves the payment. Right at that moment, you have to do two things, not one.

You take the payment. And you record that the customer has agreed to be charged again later.

That second part has to happen right then. You cannot take an ordinary one-time payment today and decide next month that it was a subscription. The permission has to be captured at the start, or every later charge is built on nothing.

For customers in Europe there is an extra step here. Their rules require them to authenticate this first payment properly. That happens once, at the start, and not again.

Step 2: The card becomes a token

You do not keep the card number. Visa or Mastercard give you a token instead. It is a stand-in for the card that only works for your business.

The token survives a new card. When your customer's card expires or gets replaced, the token can be pointed at the new card automatically. The customer does nothing. The subscription keeps running.

The token is useless to a thief. Even if someone steals it, it will not work anywhere except your business.

Step 3: Every later charge carries proof

Now you charge the token every month, on your own, without the customer present. Each of those charges has to carry a reference back to that first approved payment. Think of it as showing the bank a receipt: this customer agreed to this, on this date, with me.

That reference is the single most important detail in the whole setup. This is the most common technical reason international subscriptions fail, and most businesses never find out it is happening.

Making sure it keeps working

We launched subscription payments for international customers in 2022, the first Indian company to do so. Four years later:

That first number is the one that matters most, and it is worth explaining why.

A one-time payment that fails costs you one sale. A monthly payment that fails can cost you the customer forever. The yoga teacher does not lose $60. She loses a student who never comes back, and every month that student would have paid after that.

So a few percentage points of success rate is not a small difference. Over a year, on a book of monthly payments, it is the difference between a business that grows and one that quietly leaks.

PolicyBazaar runs premium renewals on this infrastructure. So do Indian software companies billing customers across the US, Europe, the Middle East and Southeast Asia. Very different businesses, same underlying need: the charge has to go through next month.

Why monthly payments fail, and how to stop it

Most subscription revenue is not lost to customers cancelling. It is lost to payments that quietly do not go through. Nobody complains. The money just stops arriving.

1. The card changed. Cards expire. They get replaced after fraud. Customers switch banks. Visa and Mastercard both run services that automatically update a saved card when the real one changes. The catch is timing. Your provider has to check before charging, not after the charge has already failed.

2. The proof was missing. The monthly charge did not carry the reference back to the original approved payment. The bank sees an unknown foreign charge and blocks it. This is fixable in code and it is worth checking today if you already run subscriptions.

3. There was only one road. If your payment can only travel one path to the customer's bank, and that path is having a bad day, the payment simply fails. Sending it down a different path instead turns a lost payment into a successful one.

4. The retry was thoughtless. Charging again ten minutes later, for the same amount, on a card that had no money in it, mostly just fails again. Worse, it makes the bank trust you less. Retries should be timed based on why the payment failed, and should stop completely when the answer is a firm no.

Fixing these four is usually worth more than changing your price.

Keeping the card safe

A subscription saves a card and reuses it for years. That is a heavier responsibility than taking a payment once and forgetting it.

Here is the part most people do not know. When you see the padlock in the browser, that padlock protects the card number while it travels from the browser to the server. It does nothing while the number is still sitting in the browser.

That gap is real. Attackers do not break the padlock. They plant a small piece of code on the checkout page and read the card number before it ever starts travelling. The padlock is still there. The card is already gone.

PayGlocal encrypts the card number inside the customer's browser, the moment they type it, before it starts travelling. It leaves as scrambled text. It is not readable by the checkout page, by anything else running on that page, or by anything in between.

Among Indian payment providers this is not standard. Most protect the card only once it starts moving.

For subscriptions it matters more than usual. A saved card is not one payment. It is years of payments. If it is exposed, the damage is not one transaction, it is the whole book.

Where India's rules come in

If your customer holds an Indian card

Some businesses have a mixed set of customers. Some abroad on foreign cards, some Indians paying in foreign currency, some NRIs who still hold an Indian card. For that last group, India's e-mandate rules apply fully.

Those rules were rewritten recently. On 21 April 2026 the RBI issued the Digital Payments E-mandate Framework, 2026, which replaced eight older circulars going back to 2019. In short: the customer sets up the mandate once with an OTP, can change or cancel it whenever they want, gets a warning at least 24 hours before each charge, gets a message after each charge, and can opt out of any single payment. Charges up to ₹15,000 go through without an OTP each time. For insurance premiums, mutual fund payments and credit card bills, that limit is ₹1,00,000.

The framework covers cross-border recurring transactions as well, and it places a clear responsibility on your payment provider to keep the merchants it onboards compliant. What changes with a card issued outside India is who carries out each step, since the approval and the customer notifications are handled by that customer's own bank under its own rules. The flow you build looks different, even though the responsibilities on your side remain.

The paperwork, always

This one applies no matter where the card came from, because the money arrives in India. Every monthly charge is a separate export payment. Not one a year. Twelve a year, per customer.

A FIRA for each one. Every incoming payment needs its own proof of receipt. If your provider issues these in batches or only when you ask, a subscription business builds a paperwork backlog that grows every single month.

Volume changes everything. Thousands of small monthly payments are much harder to keep straight than a few large invoices. What one person can manage by hand at ten charges a month is a different job entirely at ten thousand.

The answer is a provider that generates the FIRA automatically for every transaction. At subscription volumes there is no other workable way to do it.

Who needs international subscriptions

One pattern worth noticing

Look down that list. A large part of India's international subscription money is not Indian businesses selling to foreigners. It is Indian businesses serving Indians who live abroad.

A policy paid for from Dubai. Tutoring paid for from New Jersey. A trainer in Bengaluru with clients in London.

That customer feels Indian and pays like a foreigner. Very few payment setups are built for exactly that, and it is one of the biggest recurring segments in the country.

What to ask a provider

• What is your success rate on international subscription payments, measured over a full month?
• Do you carry the reference to the original approved payment on every monthly charge?
• Do you use network tokens, so subscriptions survive a customer getting a new card?
• Do you check for updated cards before charging, or only after a failure?
• Can a failed payment be retried on a different path?
• Do your retries depend on why the payment failed?
• Do I get a FIRA automatically for every single charge?
• How many currencies can I bill in?
• Where is the card number encrypted, and at what point?
• Is my customer data stored in India?

The short version

A subscription is not a payment. It is a promise that a payment will keep happening.

For a son in New Jersey paying for his parents' cover, a yoga teacher in Rishikesh, or a trainer in Bengaluru, the hard part was never taking the first payment. It is the twelfth one, and the twenty-fourth, going through without anybody thinking about it.

We built this in 2022 because Indian businesses selling to the world had no way to do that. Four years and 18 lakh customers later, at 95 to 96% success, the question is not whether international subscriptions are possible.

It is whether yours are actually going through.

PayGlocal is authorised by the Reserve Bank of India as a Payment Aggregator - Cross Border (PA-CB-I&O) and a Payment Aggregator (PA-O), and is part of the ICICI Bank Group.