You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 4: International Payments — FEMA, FIRC, Wise vs Stripe Atlas #

This is the module that decides whether you can scale your studio to USD-denominated revenue without compliance becoming a part-time job. It is also the module where the most expensive temptation in Indian founder ops shows up — Stripe Atlas — and I want to be honest about it before the curriculum is, because the curriculum has to be balanced and I don't.

Here is the temptation, stated plainly. You are an Indian founder. You read every other US-context startup blog. Stripe Atlas appears in your feed every six weeks with a clean landing page and a promise: incorporate a Delaware C-Corp in fifteen minutes, get a US bank account, accept Stripe payments globally, look like a real US company to your US clients. The vibe is modern, frictionless, internationally legitimate. The aesthetic is the future, vs. the dusty MCA portal. The implicit pitch is that you can sidestep Indian compliance — the GSTR-3Bs, the LUTs, the FEMA paperwork — by routing everything through a US entity. I have read enough founder Twitter to know this temptation is genuine and persistent. I want to name what is actually happening when you take it.

Stripe Atlas does not subtract Indian compliance. It adds US compliance on top. You now have: an Indian OPC (which still exists, still has annual filings, still has GST), a US Delaware C-Corp (which has annual franchise tax, federal corporate tax filings on Form 1120, state filings, registered agent fees, a US bookkeeping requirement, and ESOP/equity complexity if you ever issue stock), and the transactions between them — which trigger transfer pricing rules, FEMA outbound investment reporting (LRS or ODI, depending on structure), and the most expensive form of cross-border tax complexity. The pitch was "skip Indian compliance." The reality is "Indian compliance plus US compliance plus inter-entity reconciliation." For most Indian software founders selling under $200K USD/year, this is a strictly worse setup than receiving USD directly into the Indian OPC's bank account. It looks sexier. It costs more. It is harder to unwind.

The honest decision tree for your situation, stated bluntly: direct bank wire to your Indian OPC current account, with LUT filed for export of services, with FIRCs collected from the bank for each inflow, is the cleanest path under <span class="katex-inline" data-formula="500K USD/year of international revenue. Wise (formerly TransferWise) is a reasonable alternative for smaller invoices (">1K-10K range) where bank wires feel disproportionate — Wise is faster, has lower fees, and the FIRC issuance has been mostly reliable for the last few years (it had hiccups historically, hence the lingering reputation). Stripe Atlas only makes sense if you are raising US venture capital that requires a Delaware entity, or selling SaaS to Stripe-only US enterprises that won't wire to India, or specifically planning to sell the company to a US acquirer. If none of those are your situation right now, they might be later. You can always incorporate Stripe Atlas later. You cannot easily un-incorporate it.

A truth the formal curriculum cannot say plainly: the FIRC paperwork is not optional, and most Indian banks do it badly. The bank issues an FIRC (or e-FIRA on the new system) for each inward USD remittance, with a "purpose code" — P0802 for software services export, P0803 for IT-enabled services, P0805 for consultancy services. The purpose code links your USD inflow to your GST treatment (zero-rated under LUT) and your IT treatment (foreign source income, declared as export turnover). If the bank uses the wrong purpose code, the linkage breaks. The mismatch surfaces months later when GST notice asks why your zero-rated export turnover doesn't match your bank's purpose-code-tagged inflows. You have to check the FIRC every time it is issued. The bank will not catch its own mistakes. Your CA will catch them at year-end, three FIRCs deep, when the fix is harder. Catch them at month-end. This sounds like overkill until the first time you find a wrong purpose code, which will happen within twelve months of your first export invoice — I am willing to make that prediction.

About SWIFT instructions specifically: you will give your US client your bank's SWIFT details so they can wire payment. The first wire will probably go through. The second will probably arrive at a slightly wrong amount because of intermediary bank fees nobody mentioned. The third will get held by the bank for additional KYC documentation because the amount crossed some threshold. None of this is your fault, all of it is normal, and all of it teaches you to (a) include a "bank fees on payer" clause in your SOW, (b) keep a folder with the bank's complete SWIFT instructions ready to copy-paste, and (c) have a single point of contact at the bank who knows your account and can resolve held wires within a day instead of a week. The named-banker move is underrated. Every Indian founder I have read about who scaled USD revenue cleanly had a named banker. Most who didn't have one lost a week per year on stuck wires.

Specifically about timing — you will probably have your first non-trivial USD invoice within 6-12 months of getting serious (a US consulting client, or a first international subscriber to a product, or both). The setup work for that first invoice — LUT filed, bank account configured for forex, SWIFT instructions documented, FIRC flow confirmed with bank, Zoho Books configured for USD — is all doable in a focused weekend. Doing it pre-invoice is calm. Doing it the week the invoice is due is panic. You know which one this path is going to recommend.

A note on payment aggregators — Razorpay International, Cashfree, PayPal — that the curriculum should not skip too quickly. These add a 1-3% fee layer on top of bank charges in exchange for operational simplicity — your client pays via card or local-payment-method, the aggregator handles forex conversion and FIRC issuance, the money lands in your INR account net of fees. For B2C SaaS subscribers (small amounts, many transactions, varied countries), an aggregator is structurally correct because bank wires don't scale to many small transactions. For B2B consulting (large amounts, few transactions, named clients), a direct bank wire is structurally correct because the percentage fees on a $10K invoice are real money. Match the rail to the transaction shape. Some founders use aggregators for everything (overpaying on B2B); others use bank wires for everything (impractical for small B2C). The hybrid is correct: aggregators for SaaS subscribers, bank wires for consulting clients.

About PayPal specifically — many US clients will offer PayPal as the default and you will be tempted because PayPal is famous and fast. PayPal-to-India for business has its own friction (currency conversion at unfavorable rates, withdrawal fees, FIRC complications historically). For invoices over 1K, PayPal's overhead is the lesser cost. Most US clients accept "I prefer wire for invoices over a threshold" without friction; they only default to PayPal because they assumed convenience.

Conclusion #

International payments is not a single decision; it is a structural decision (which payment route) plus an operational discipline (FIRC checking, purpose-code reconciliation, LUT compliance). Get the structural decision right once — direct bank wire for most cases, Wise for small invoices, Stripe Atlas only with a specific reason — and the operational discipline becomes mechanical. Get it wrong and every USD inflow generates compliance friction that compounds. The temptation to over-engineer the structure (US LLC, Stripe Atlas, payment aggregators) almost always costs more than it saves at a one-person studio's scale.

Predictions #

  • You will be tempted by Stripe Atlas at least once in the next 12 months, probably after reading a US founder thread. Re-read this file before signing up. If the reasons in this file don't apply to your situation, your reasons are probably aesthetic.
  • The first FIRC you receive will have something slightly wrong on it. Either purpose code, or amount, or counterparty name. Notice it. Fix it. Establish the precedent with your bank that you read FIRCs.
  • You will under-estimate intermediary bank fees on the first wire by ~$30-60. Add a "bank fees on payer" clause to your SOW template (Module 5) before the second wire.
  • Wise will tempt you with the lower fees and faster transfer. For invoices under 10K, the bank wire's FIRC reliability is worth the slightly higher cost.
  • Within 18 months you will have a named banker at your forex bank — not because you planned for one, but because resolving a stuck wire required one and the relationship persisted. Use the relationship. Send the banker a Diwali gift. The relationship is part of the infrastructure.
  • The "compare three routes" exercise in the checkpoint will probably show direct bank wire winning at a one-person studio's scale by 2-4K/year over Stripe Atlas. Build the spreadsheet anyway — the exercise is the learning.
  • Your first RBI/FEMA-flavored question (probably from your CA) will arrive within 9 months of your first USD invoice. Having read this module will make you a competent participant in the conversation instead of a passenger.