Stripe does not issue your FIRC. So what do you give the bank?

Does Stripe India issue a FIRC or not?

No. Stripe does not issue a FIRC, and it does not issue a FIRA either. This is stated plainly in Stripe's own support documentation on FIRC for international transactions in India, which says that Stripe does not provide these certificates and that what it provides instead is a Standard Chartered payment advice evidencing that the export payments originated outside India (support.stripe.com). That single sentence is the whole reason this guide exists.

It is worth being precise about what the difference means, because "we give you a document instead" sounds like a substitution and it is not one. A FIRC, or a FIRA in the form most payment rails issue it today, is a certificate from an authorised dealer bank confirming that a specified sum of foreign currency was received by a named beneficiary on a named date for a stated purpose. It is a realisation document. It is what your GST refund officer expects to see against an export of services, what your AD bank works from when it closes an export bill, and what sits underneath the inward remittance record that eventually lets you certify an eBRC.

A payment advice is a different animal. It is a bank telling you what it did with a batch of money. It evidences origin: these funds came from outside India. It does not certify realisation against your export, it is not issued in your name by your own AD bank, and it does not carry the purpose-coded structure a FIRC carries. It is also issued per payout , not per invoice. If a single international payout sweeps up forty charges against twelve commercial invoices and nine shipping bills, you receive one advice covering the payout, and the work of getting from that one document down to nine bills is yours.

Read that table as a map of where the work sits. On four of the five rails, the realisation document is a by-product of the settlement: the money lands and the certificate appears, without anybody at your end doing anything. On Stripe, the document is something you have to go and manufacture, at your own bank, with your own paperwork, on every payout, for as long as you keep selling. That is not a fee difference. It is a difference in who owns the compliance work.

What exactly is the Standard Chartered payment advice?

Standard Chartered Bank is Stripe India's settlement and reporting partner for export transactions. Per Stripe's India exports documentation, SCB emails a payment advice, also called a payee advice, to the email address registered on your Stripe account, on the same day the export payout is processed, listing the export charges included in that payout (docs.stripe.com/india-exports). That is the mechanism in full. There is no portal step, no request flow, no approval.

Which sounds convenient until you look at the operational consequences, and there are three that bite.

First, it goes to the account email. Not to a finance alias, not to a shared compliance inbox, not to a document vault. It goes wherever the Stripe account was originally opened, which in a large number of small exporters is a founder's personal address or an ops person who has since left. The document that your AD bank will one day want, on every payout you ever took, is arriving in an inbox nobody treats as a system of record. Fix this on day one: make the registered account email a distribution address that lands in the finance inbox and in an archive, before you take your first international charge.

Second, there is no documented dashboard re-download. Stripe's documentation describes the advice as emailed. It does not describe a place in the Dashboard where you can go and pull the advice for payout number forty-seven from eleven months ago. Treat every advice email as the only copy. File it against the payout ID the day it arrives, in a folder structure your bank can be walked through, because reconstructing a year of missing advices from a support ticket is not a plan.

Third, Stripe does not name an OPGSP or PA-CB framework in its India exports documentation. Rails that operate as cross-border payment aggregators typically say so, because saying so is what tells your bank which regulatory box the money arrived through and what the bank is therefore entitled to rely on. Stripe's documentation describes a settlement partner and a payment advice, and stops there. That silence is not an allegation of anything, but it does change how you should behave: you cannot walk into your bank and say " this came through the standard aggregator channel, you know the drill." You have to explain the arrangement, and you should expect to explain it more than once.

How do you turn that advice into a FIRC at your own bank?

The route is simple to describe and tedious to run. You take the Standard Chartered advice to your own authorised dealer bank, you ask that bank to raise the inward remittance message against your PAN, and you ask it to issue the FIRC. Stripe does not do any of these three things for you and does not claim to. Your AD bank becomes the issuer of your realisation document, which is precisely the role Stripe has declined.

What the bank will typically want alongside the advice is the ordinary export documentation set: the commercial invoice for the underlying sale, the shipping bill if you are exporting goods, and (the part people forget) an explicit mapping showing which charges inside that payout correspond to which invoices and which bills. The bank is being asked to certify a realisation against specific export documents. It cannot do that from a batch total. If you hand it a batch total and a shrug, it will hand the file back.

Advice to FIRC, in order

1. :

On cost: Stripe publishes no charge for the advice itself, because the advice is a by-product of settlement rather than a product. What this route costs you is therefore whatever your own bank charges to issue a FIRC, multiplied by the number of payouts you take, for as long as you use the rail. Banks price this differently and often quietly, so ask your relationship manager for the schedule in writing before you assume it is trivial. A fee that looks negligible on one payout looks different at fifty-two payouts a year.

Why does an INR payout break EDPMS matching?

This is the part that catches even careful exporters, because nothing appears to go wrong. Stripe pays out in INR. Domestic and international payouts are paid separately, and the international ones are labelled in the Dashboard (docs.stripe.com/india-exports). Money arrives. The bank statement shows a clean rupee credit. Everything looks settled.

But from your AD bank's point of view, what arrived was a rupee credit from a domestic counterparty. It is not a foreign currency inward remittance hitting a nostro account and dropping into the inward remittance queue. So the bank does not create an inward remittance message. And because no IRM exists against your PAN, the DGFT eBRC IRM repository has nothing to show you, which means you cannot self-certify an eBRC, which means the export looks unrealised for as long as you leave it alone.

The shipping bill, meanwhile, has been sitting in EDPMS as an open export bill from the moment customs granted let export order. Your export is on the clock. Proceeds have to be realised and repatriated within the FEMA period running from the LEO date, and the mechanics of that clock are covered separately in the FEMA repatriation guide . The uncomfortable position an INR-payout rail puts you in is this: you have actually been paid, on time, in full, and the regulatory record still says you have not.

And the ceiling is much higher than compounding. In an adjudication order dated 16 February 2026, M/s PPK Newsclick Studio Pvt. Ltd. And its director were held liable for a total FEMA penalty of Rs 184 crore, on inward remittances of Rs 82.63 crore that were treated as export of services without the mandatory SOFTEX and reporting filings (enforcementdirectorate.gov.in). The money in that case genuinely came in. What was missing was the reporting that ties the receipt to the export. That is the same category of failure an unreported Stripe payout sits in, at a different scale.

The sequence that closes the loop

• Separate the international payouts. Stripe labels them in the Dashboard. Pull them out of the domestic stream before anything else, because only these are export receipts.
• Take the SCB advice to the AD bank. With the charge report, the commercial invoices and the shipping bills for the charges in that payout.
• Get the IRM raised. This is the step that does not happen by itself. Until the bank creates the inward remittance message, nothing downstream can move.
• Confirm the IRM against your PAN. Check the DGFT eBRC IRM repository rather than assuming the bank's confirmation means it landed.
• Self-certify the eBRC. Map the IRM to the shipping bill and certify. Full process in the eBRC filing guide .

Can one Stripe account carry more than one purpose code?

No. One Stripe account carries one purpose code. It is selected from a fixed dropdown when you apply for the account, and it can be changed afterwards in your dashboard settings at dashboard.stripe.com/settings/update, but changing it replaces the code for the account rather than adding a second one (docs.stripe.com/india-exports). There is no per-charge purpose code, no per-product mapping, and no way to route some receipts one way and some another inside a single account.

For a seller who does one thing, this is a non-issue. For a seller who does two, it is a structural constraint that has to be resolved before onboarding rather than after. If you ship physical goods and also bill a design retainer or a SaaS subscription to overseas customers, those two revenue lines belong under different purpose code families (goods under P0102 and P0103, services under the P08, P10 and P11 ranges) and a single Stripe account cannot carry both. Your options are a second Stripe account under the same entity for the second revenue line, or a second rail entirely.

What you should not do is pick whichever code covers the larger share of revenue and let the smaller line ride along under it. The purpose code is how the receipt is reported to the banking system. Reporting a goods realisation under a services code, or the reverse, misdescribes the transaction at the point where it enters the regulatory record, and it is the manner-of-receipt question in a different costume. The same question that produced the the communications equipment exporter compounding under Regulation 10.

What does Stripe actually cost on an export charge?

The number that circulates is 3%. The number you actually pay is built from several layers, and the headline is only the first one. Per Stripe's India pricing page, international Visa and Mastercard charges are priced at 3%, American Express cards issued outside India at 3.5%, and international cards presented in a currency other than INR at 4.3%. On top of that sits a 2% currency conversion fee, and on top of the whole fee stack sits 18% GST (stripe.com/in/pricing).

Worked example (illustrative). One USD 5,000 export receipt on Stripe

• Gross export receipt: USD 5,000.00
• International Visa/Mastercard fee at 3%: USD 150.00
• Currency conversion fee at 2%: USD 100.00
• Fee subtotal before tax: 150.00 + 100.00 = USD 250.00
• GST at 18% on fees: 250.00 × 0.18 = USD 45.00
• Total deduction: 250.00 + 45.00 = USD 295.00. An effective 5.90%
• Net realised: 5,000.00 − 295.00 = USD 4,705.00 , paid to you in INR
• Plus: your own AD bank's FIRC charge on this payout, and the internal time to assemble the bundle. Neither is published by Stripe because neither is Stripe's.

Figures above are an illustrative calculation from Stripe's published India rates. They assume an international Visa or Mastercard charge with currency conversion, and no Amex or non-INR presentment premium.

Now put that alongside the rails that hand you a realisation document for free. The comparison below runs the same USD 5,000 receipt across five options using each provider's published pricing. It is deliberately not a ranking (the right rail depends on your ticket size, card mix and customer expectations) but it does make the shape of the trade-off visible.

Two things fall out of that table. The first is that the rails are not comparable products. A card checkout that converts a browsing customer is worth paying more for than a bank transfer a known B2B buyer initiates, and nobody switches a storefront to Skydo. The second is that on the rails where the fee is lowest, the realisation document is also free and automatic, which means the document gap is not a compensating advantage that Stripe buys you elsewhere. It is a cost on top: your own bank's FIRC charge, per payout, forever, plus the hours spent assembling each bundle.

What are Stripe India's export transaction limits?

Stripe India exports is invite-only. Within the programme, Stripe support documents a maximum of Rs 25 lakh per transaction for sole proprietorships, LLPs and companies, and states that international transactions are not facilitated for individual structures (support.stripe.com). Read the second half of that sentence carefully if you have not incorporated: an individual seller is not being offered a lower ceiling, they are being told the rail does not carry their international transactions at all.

A per-transaction ceiling is a different constraint from an annual one, and it bites in a specific place: high-value B2B orders. A consolidated container order, an annual enterprise contract, a single large machine. These are exactly the transactions where one invoice, one shipping bill and one payment are supposed to line up cleanly, and exactly the transactions a per-charge ceiling forces you to break apart.

Which brings up the thing worth saying plainly: splitting an invoice to fit a rail is itself a compliance question, not a workaround. Your shipping bill states a value. Your commercial invoice states a value. If your remittance record shows that value arriving as two unrelated charges on two dates because a payment processor capped you, you have introduced a discrepancy into precisely the documents a bank reconciles and a FEMA review reads. If the contract genuinely has two milestones or two shipments, invoice them as two and let the charges follow the invoices. If it does not, take the payment on a rail that can carry the full value in one receipt.

Two honest gaps are worth flagging. Stripe does not publish an annual cap for India exports, so you should not assume the per-transaction ceiling is the only volume constraint that exists. Ask during onboarding. And Stripe does not publish an India export payout timing, so you cannot plan your working capital or your realisation timeline against a documented payout schedule the way you can on rails that state one. Both are questions to put to your account contact in writing before you build a cash flow model on top of the rail.

Stripe export documentation checklist

Everything above collapses into a routine. Run it per payout and the rail is workable. Skip it and you are accumulating unrealised exports on a clock you cannot see.

Per payout

• Confirm the payout is labelled International in the Stripe Dashboard. Domestic and international payouts are paid separately, and only the international ones are export receipts
• Capture the Standard Chartered payment advice email the same day it arrives and file it against the payout ID. Treat it as the only copy
• Export the Stripe charge-level report for that payout so you have the individual charges behind the batch total
• Match each charge to its commercial invoice and, for goods, to its shipping bill. One row per charge, no gaps
• Submit the advice, the invoice and the shipping bill to your AD bank to raise the inward remittance message and issue the FIRC
• Confirm the IRM appears in the DGFT eBRC IRM repository against your PAN. Check the repository, do not rely on the bank saying it is done
• Self-certify the eBRC against that IRM and the relevant shipping bill

Annually

• Verify the purpose code on file still matches what you actually sell. Revenue mixes drift, and the code does not drift with them
• Confirm no charge has approached the Rs 25 lakh per-transaction ceiling, and that nobody has quietly started splitting invoices to stay under it
• Re-confirm the registered Stripe account email still routes to a monitored finance inbox and an archive
• Reconcile the count of international payouts against the count of FIRCs issued and eBRCs certified. The three numbers should agree

What else do exporters ask about Stripe and FIRC?

Stripe says it cannot give me a FIRC. Will my bank accept the Standard Chartered advice instead?

Usually yes, but not automatically and not as a substitute. Stripe's support documentation states that it does not issue FIRC or FIRA and instead provides an SCB payment advice evidencing that the export payment originated outside India. That advice is evidence of foreign origin, not a realisation certificate. Your AD bank will normally accept it as the supporting document to raise the inward remittance message and then issue its own FIRC, but it will want the commercial invoice and shipping bill alongside it, and it will want the mapping between the payout and the bills it covers. Approach the trade finance or forex desk, not the branch counter, and agree the format before your first payout rather than after twenty of them.

My Stripe payout came in INR, so why is nothing showing in my DGFT IRM repository?

Because an INR payout from a domestic partner bank is not, on its face, an inward remittance. Stripe pays out in INR, with domestic and international payouts paid separately and international payouts labelled in the Dashboard. Your bank sees a rupee credit from a domestic counterparty, so it has no reason to create an inward remittance message against your PAN, and with no IRM there is nothing for the DGFT eBRC repository to show. The fix is manual: separate the international payouts, take the SCB advice plus invoices and shipping bills to your AD bank, ask it to raise the IRM, then self-certify the eBRC against that IRM once it appears.

I sell both physical products and services. Can I use one Stripe account for both purpose codes?

No. Stripe's India exports documentation is explicit that one Stripe account carries one purpose code, chosen from a fixed list at account application and changeable later in dashboard settings. Goods use P0102 for realisation of export bills and P0103 for advance receipts against export contracts. Services use the P08, P10 and P11 families. Changing the code changes it going forward for the whole account; it does not split the account into two streams. If you genuinely sell both, you need a second Stripe account under the same entity or a second rail for the other revenue line. Running goods receipts under a services code is a misreporting problem, not a paperwork preference.

How do I tell which part of my Stripe payout was export and which was domestic?

Stripe pays domestic and international payouts separately and labels the international ones in the Dashboard, so the split is done for you at payout level rather than left for you to reconstruct. Work from the payout, not the bank statement: pull the charge-level report for each international payout, confirm the label, and file the SCB advice for that payout against its payout ID. If you find a single payout mixing both, that is a signal something is misconfigured and worth raising with Stripe support before you build a reconciliation on top of it.

My invoice is above Rs 25 lakh. Can I split it across two Stripe charges?

Technically you can, and that is exactly why you should think hard first. Stripe India exports carries a maximum of Rs 25 lakh per transaction for sole proprietorships, LLPs and companies. Splitting a single commercial invoice into two charges purely to fit under a rail's ceiling creates a mismatch between your invoice, your shipping bill and your remittance record, and that mismatch is what your AD bank and later any FEMA review will look at. If the underlying contract genuinely has two milestones or two shipments, invoice them separately and let the charges follow the invoices. If it does not, use a rail that can take the full value in one receipt.

Update history

• 2026-08-13 First published.