// payments · tax · peru
Charging international customers as a Peruvian company
The conversation almost always starts the same way: “we have clients abroad, let’s add Stripe”. And it stalls right there, because Stripe does not accept Peruvian merchants. Peru is not among its supported countries and the platform does not operate in soles. That does not close the door —there are ways out— but it changes the question: charging from abroad is not about picking a gateway, it is about choosing a structure. And it brings a tax layer that is almost always discovered late.
No
Stripe does not allow sign-up from Peru
0% VAT
exported services are not subject to VAT
Registry
you must enroll with SUNAT; it is not automatic
4 conditions
for it to qualify as an export
Surprise 1: Stripe is not a direct option
A Peruvian company cannot register with Stripe: Peru is not among the accepted countries, and the platform does not support charging in soles either. Any guide saying “just create your account” was written for a different country.
It is worth stating bluntly because it is the number one source of product plans that collapse halfway. Stripe’s global availability list is the authority, and it is worth checking before promising anything: these lists change, and the day Peru is added, this section of this article becomes outdated.
The real ways out
There are three paths: charge through a gateway that does operate from Peru and accepts international cards; use a provider that bridges you to the global market; or incorporate an entity abroad —typically a US LLC or corporation— and run Stripe from there.
The first is the simplest and the one fewest people consider: local gateways process cards issued outside Peru. If your international customers pay by card and your volume is not enormous, you may already have the problem solved with the infrastructure you already use.
The third —opening a US entity— is the one most recommended online and the least analyzed. Yes, it unlocks Stripe. It also brings accounting in two countries, reporting obligations, annual maintenance costs and far-from-trivial questions about where the income is actually taxed. It is a corporate and tax decision, not an integration decision, and it deserves an accountant and a lawyer before an engineer.
The layer technical teams ignore
Selling a service to a client abroad may qualify as an export of services, which is not subject to Peruvian VAT. But it is not enough for the client to be foreign: there are conditions, and one of them is a filing nobody remembers.
| Condition | What it means |
|---|---|
| Be registered | The exporter must appear in SUNAT’s Registry of Service Exporters. It is not automatic: you have to enroll. |
| Be domiciled in Peru | The service provider must be domiciled in the country. |
| Non-domiciled client | The user or beneficiary of the service must be a person not domiciled in Peru. |
| Used abroad | The use, exploitation or benefit of the service must take place outside Peru. |
The first one surprises people the most: there is a Registry of Service Exporters maintained by SUNAT, and you have to be enrolled in it. It does not activate simply by invoicing abroad. It is a cheap, quick filing compared with what it costs to discover you have been invoicing incorrectly for a year.
Where this becomes code
If a sale abroad carries no VAT and a domestic one does, then your invoicing system needs to distinguish domiciled from non-domiciled clients. That stops being the accountant’s topic and becomes a branch in your code.
This is the point that rarely appears in tax guides or integration guides, because it lives exactly in between. In practice it means your customer model needs the tax-domicile field, your issuing logic has to pick the right document type, and electronic invoicing has to issue without VAT where applicable. And if you invoice from an ERP, that same distinction travels all the way into SAP.
Add currency to it. Charging in dollars while keeping books in soles forces you to decide which exchange rate records each operation and what happens to the difference when the money finally lands. Left undefined at the start, it ends up resolved by hand every month-end — the same silent cost we covered when calculating what charging really costs.
Common mistakes
Nearly all of them come from treating a structural problem as if it were an integration one.
do it like this
- Check the provider’s availability for Peru before committing the product plan.
- First check whether your current gateway already processes the international cards you need.
- If you evaluate a foreign entity, do it with an accountant and a lawyer: it is not a technical decision.
- Enroll in the Registry of Service Exporters before invoicing abroad.
- Store the client’s tax domicile in your model: whether the invoice carries VAT depends on it.
avoid this
- Designing the product assuming Stripe will be available from Peru.
- Opening an LLC just to get Stripe, without costing its obligations.
- Assuming a foreign client is enough to skip VAT.
- Leaving currency and exchange rate undefined until the first month-end.
- Treating the domiciled / non-domiciled distinction as purely an accounting matter.
How we do it
We build systems that charge and invoice correctly on both sides of the border: the right gateway, the tax distinction in the model and reconciliation solved in the appropriate currency.
We have integrated Culqi and Niubiz in production and connected the result to invoicing. If your product is starting to sell outside Peru and you want the system to support that decision rather than obstruct it, let’s talk.
In summary
Charging international customers as a Peruvian company is not solved by picking a gateway. Stripe does not accept Peruvian merchants, so the real options are three: use the local gateway that already processes international cards, lean on a bridging provider, or incorporate an entity abroad — which unlocks Stripe and brings a full corporate and tax structure with it. On top of that sits the layer that decides whether you invoice correctly: exported services are not subject to VAT, but that requires being enrolled in SUNAT’s registry and meeting specific conditions. And that lands in your code as a branch: domiciled client or not, with VAT or without.
An honest note: this is guidance for designing the system, not tax advice. The authorities are the Peruvian VAT Law and your accountant — who also knows your specific case, which no article can.
Is your product starting to sell outside Peru?
We build charging and invoicing for both sides of the border, with reconciliation solved. You talk with an engineer, not a salesperson.