Skip to content

Selling From India

Selling From India is the payment and compliance problem of collecting money from foreign customers into an Indian entity through a legally valid rail. The choice is not just checkout UX: it depends on the provider’s authorisation, the RBI/FEMA purpose code used for the receipt, and the bank or provider certificate proving export proceeds.

The hard part is that a successful foreign payment is not automatically usable export revenue in India. A card authorisation, PayPal sale, SWIFT credit, or marketplace payout may move money, but banks and regulators still need to know why the money entered India and whether the collection path was permitted. If the rail, purpose code, and evidence do not line up, the business can have revenue in its ledger but weak proof for export, tax, or compliance workflows.

Concretely, the seller picks a collection model: international card acquiring, a merchant-of-record provider, SWIFT bank transfer, or an RBI-regulated Payment Aggregator-Cross Border flow. The receipt is tagged with an export purpose code, such as P0802 for software consultancy or implementation services, and the bank or provider issues an FIRC, e-FIRC, or FIRA showing the remitter, beneficiary, amount, currency, and purpose code. That document is what connects the payment to the export.

The trade-off is control versus compliance surface. Direct card acquiring gives the merchant more ownership of checkout and customer relationship, but may create PCI DSS scope if cardholder data touches its systems. Merchant-of-record models can simplify collection, but the buyer may legally contract with the provider, not the Indian seller. SWIFT can be simple for invoices but slower operationally. The honest answer is rail-dependent, entity-dependent, and evidence-dependent.

Engineers meet this when enabling international payments in Razorpay, Cashfree, Stripe, Adyen, PayPal, Paddle, or bank transfer flows for an Indian company. The practical checklist is not only whether the API can charge a foreign card. Confirm international or PA-CB support, avoid handling PAN or CVV unless you can satisfy PCI DSS, store the purpose code, reconcile fees, and make sure finance can obtain the matching FIRC, e-FIRC, or FIRA.

Common questions

Is UPI enough for an Indian business selling to overseas customers?
Usually no. UPI is an Indian payment system operated through NPCI and is not the same as open-ended international card acquiring. A foreign buyer paying with Visa or Mastercard uses card scheme and acquiring rails. For an Indian exporter, the important question is whether the chosen provider is allowed to collect cross-border money and issue usable evidence.
What is the common mistake with purpose codes?
Teams often treat the purpose code as a bank formality and choose whatever seems close. It is actually the regulatory label for why the money came into India. If software, consulting, goods, or information services are coded incorrectly, the payment can be hard to prove as the right export even though the amount arrived.
Does using PayPal or Paddle mean the Indian seller received the foreign customer payment directly?
Not necessarily. In a merchant-of-record flow, the foreign customer may buy from the provider, while the Indian company receives a later payout from that provider. That changes the money trail. The seller should reconcile the payout and obtain the evidence available for that model, rather than expecting customer-level export proof for the original charge.
When does PCI DSS matter in this setup?
PCI DSS matters when the Indian merchant stores, processes, or transmits cardholder data. A custom form that sends PAN or CVV through the merchant server increases scope and certification burden. Hosted checkout from a payment provider can reduce that exposure because sensitive card data goes directly to the provider rather than through the merchant’s infrastructure.