Getting paid in USD as an Indian developer: the part nobody explains
Search "accept international payments India" and you'll get a list of gateways. Razorpay, Cashfree, Stripe, PayU. Problem solved, right?
Not quite. Stripe does operate in India. The gateway question was never the hard part for Indian developers. The hard part is one step later: can you prove to a bank and to the tax department that this money is an export of services?
Get that wrong and you don't lose a sale. You lose the ability to claim back input tax credits, and you spend months in paperwork. So this post is about the part that actually trips people up.
Stripe India works, but it settles in rupees
Stripe India requires an Indian business entity and settles to an Indian bank account in INR. That's fine if your goal is "money arrives." It's a different thing from "I hold USD," and it's a different thing again from "my export paperwork is clean."
Three distinct problems. Most guides collapse them into one.
The real question: is this an export of services?
If you're selling software or SaaS to customers outside India, you're exporting services. India treats export of services as zero-rated under GST — meaning you shouldn't be paying GST on that revenue — but zero-rated is not the same as automatic.
To get the benefit, a few things have to be in place:
1. GST registration. If you're above the turnover threshold for services, you need to be registered. Below it you may not need to register at all — which is simpler, but limits your ability to claim refunds on input costs.
2. An LUT (Letter of Undertaking). This is the document that lets you export services without paying IGST upfront and then chasing a refund. Without an LUT, you pay the tax first and reclaim later. With it, you skip that entire cash-flow hole. File it — it's the single highest-leverage piece of paperwork here.
3. FIRC / FIRA. This is the certificate your bank issues when foreign currency lands in your account. It's your proof that payment actually came from abroad. When you file for a refund, this is the evidence. If your money arrives through a payment aggregator that doesn't produce a clean FIRC/FIRA per transaction, your refund claim gets messy.
That last point is where the gateway choice actually matters — not fees.
Where Merchant of Record platforms fit
A Merchant of Record (MoR) — Polar, Creem, Dodo Payments, Paddle, FastSpring — becomes the legal seller of your product. The customer's invoice is from them. They handle sales tax/VAT in the customer's country, fraud, chargebacks, and refunds.
For an Indian developer selling globally, that removes a large compliance surface on the customer side. It also means your customer relationship is one hop removed, which some buyers dislike.
But here's the part people miss: an MoR does not take over your Indian export obligations. Your income is still export of services. You still need the documentation chain on your side. The MoR simplifies the foreign tax question, not the domestic one.
So decide early: do you want maximum simplicity on the customer's side (MoR), or maximum control and lower fees (your own payment account + your own paperwork)? Both are legitimate. Pick one and build the paperwork around it.
Getting the USD to actually land
Whichever route you take, you eventually need a receiving account that accepts USD. Options Indian developers commonly use:
- Your bank's USD account — cleanest for FIRC purposes, more paperwork to open, and correspondent bank fees apply.
- Payoneer — gives you a US receiving account that platforms can pay into via ACH, then you withdraw to your Indian bank.
- Wise — receiving accounts in multiple currencies.
The trade-off is always the same: the cleaner the paper trail, the more friction to set up. If you plan to claim GST refunds, favour the route that produces proper certificates over the route that's easiest.
The order that saves you weeks
- Decide: MoR, or your own payment account.
- Decide: do you need GST registration (i.e. are you above the threshold)?
- If yes — file the LUT before your first export invoice.
- Set up the receiving account so the money arrives with a paper trail.
- Build an export invoice template with the right details on it.
- Then pick a gateway, and only among the ones compatible with the above.
Most people do this in reverse: pick the gateway, integrate it, sell for six months, then discover they can't cleanly claim the refund.
The caveat that matters more than anything above
I'm not a chartered accountant, and Indian tax rules change. Talk to a CA who has done export-of-services filings before your first significant payout. The cost of one consultation is trivial compared to the cost of a refund claim that fails on documentation.
Treat this post as a map of which questions to ask, not as a filing guide.
I keep the full platform comparison — 50 platforms, filterable by country, entity type and product type — here:
- Interactive version: https://workspace-zeta-dun.vercel.app
- GitHub (corrections welcome): https://github.com/chenningdev/pay-usd-from-anywhere
Stuck on getting paid from outside the US?
I've mapped 50 platforms and helped developers in India, Nigeria, Pakistan and Bangladesh figure out which one will actually onboard them and how to get the money out.
Book a 30-minute paid consultation — $49, paid via Payoneer.
Email me: 3133371715@qq.com
If you've done export-of-services filings from India and hit something that isn't covered here, say so in the comments — especially anything about FIRC handling through aggregators. That's the detail I most want to get right.
Top comments (1)
The reverse-order section is the sharpest thing here. Picking the gateway first is the default move because it is the only step with a signup button, and then the FIRC question shows up at reconciliation when the money is already in and the paper trail is missing. One detail worth adding: the LUT renews every financial year, and an export invoice booked against a lapsed LUT turns into an IGST-with-refund situation, which is exactly the months-of-waiting outcome this post warns about. The CA disclaimer is the right closing note; this is an area where blog-level accuracy is fine for framing questions and dangerous for filing.