---
title: "Only two payment processors on Shopify can charge in the customer's currency"
description: "Showing a price in euros and charging euros are two different Shopify features, and the second one belongs to your payment processor. What breaks when the processor changes, and the four ways out."
author: "Luboš Zápotočný"
published: "2026-07-13"
language: "en"
canonical: "https://zapolu.com/blog/shopify-local-currency-processor/"
---

# Only two payment processors on Shopify can charge in the customer's currency

A Shopify store can show its prices in any currency you like. Charging
in that currency is a separate feature, and it does not belong to the
store. It belongs to the payment processor.

Exactly two processors have it. Shopify's documentation on local
currencies, checked on July 13, 2026, is explicit: ["To process
payments in multiple currencies, your store must use Shopify Payments
or Adyen as its payment processor. If you use a different provider,
then customers in all markets pay in your store's default
currency."](https://help.shopify.com/en/manual/markets/customizations/local-currencies)
The [guidelines for selling in local
currencies](https://help.shopify.com/en/manual/international/pricing/limitations)
state the same rule from the other side: orders placed through other
third-party payment providers are processed in the store's default
currency, and reports are available only in the store currency.

So the product page can show euros to a customer in Bratislava, the
cart can show euros, and the checkout will charge that customer in the
store's default currency anyway.

You can display any price you like. You can only charge the one your
payment processor supports.

## Why it surprises people

Nobody switches multi-currency on as a payment feature. You open
Markets, add a market, watch the prices convert, and it reads as a
storefront setting. The dependency runs the other way, and the admin
does not say so anywhere you would think to look.

It becomes visible on the day the payment processor changes: a new
legal entity behind the store, a move to a local gateway, a Shopify
Payments account that has to be verified again. Local-currency pricing
leaves with it. Nothing in the admin connects the two events, so what
the shop sees is that the euro prices stopped working on a day when
nobody touched the euro prices.

## The four routes

**Set up Shopify Payments.** This restores the feature exactly, and in
engineering terms it is the cheapest of the four, because there is no
engineering in it. The cost is paperwork, and the paperwork has its own
section below.

**Adyen as the primary gateway.** The only other processor Shopify
documents for this. It is worth raising when Shopify Payments is
genuinely unavailable rather than merely unwelcome. It is a commercial
contract with a payment provider, so it is a decision rather than a
setting.

**A second store with the euro as its default currency.** This works,
with no tricks in it, and it is the honest answer when the euro market
is really a different business: different assortment, different
pricing, sometimes a different legal entity. What people cost is the
second subscription, which is the small number. The large number is the
second copy of the catalog, the theme, the apps and every integration,
plus an inventory sync between the two stores that runs for as long as
both exist.

**Compute the prices yourself and display them.** Currency apps do
this, and so does storing your own converted prices in metafields. It
is the route that gets proposed once the other three are unwelcome, and
it needs the most care, so it gets its own section too.

## What a self-computed price can reach, and what it cannot

Prices you compute yourself can reach every surface you control. The
storefront, a draft order, an internal tool, a PDF quote: each of these
renders numbers you supply, and each will render euros correctly.

The checkout is not a surface you control. With a third-party provider
Shopify processes the order in the store's default currency, whatever
the product page said, and the reports come out in the store currency
too. The euro price is therefore correct everywhere except at the point
where the money is taken.

That makes this route conditional on one question about the business:
does any customer ever pay you in euros through Shopify's checkout? If
a customer can put a euro price in the cart and pay by card, the price
on the product page is not the price that gets charged. If the euro
path instead ends in a draft order, an invoice and a bank transfer,
then the checkout never handles a euro, no one is charged in the wrong
currency, and computing the prices yourself is not a workaround at all.
It is where the pricing has to live.

Before building any of it, check one thing. Shopify [documents a
currency override on draft
orders](https://help.shopify.com/en/manual/fulfillment/managing-orders/create-orders/international-drafts)
once Markets is set up, with the exchange rate fixed at the moment the
draft order is created. Collecting payment on such an order is
restricted: Shopify's stated limitation is that with deferred payment
terms in a non-default currency you can collect only by credit card or
by marking the order as paid. That may cover the quoting case without
any metafields, or it may fail to survive contact with your invoicing.
Test it on the actual store before writing code that assumes either
answer.

## The paperwork, and why the owner cannot argue with it

The objection to Shopify Payments is rarely technical. Setting it up
means identifying the people behind the company: a photo ID, a date of
birth, the company's beneficial owners, the registration number, the VAT
number and a SEPA bank account. Shopify publishes the exact list per
country, so it varies by a document here and there, and on the Czech and
the Polish pages a beneficial owner is anyone holding 25 percent of the
business or more. Owners resist all of this, and they resist hardest
when they read it as Shopify prying into a business that is none of its
concern.

Every one of those country pages gives the same reason, in the same
sentence, with only the country's name changed. Here is the page for
Czechia, checked on July 13, 2026: ["Shopify and its banking partners
are required to collect and verify information about you and your
business, in order to comply with regulations in Czechia that are
designed to prevent financial
crimes."](https://help.shopify.com/en/manual/payments/shopify-payments/supported-countries/czechia/requirements)

Every card processor collects the same information, because every card
processor answers to the same anti-money-laundering rules. An owner who
declines to identify the company's beneficial owners is declining to
accept card payments anywhere, and the next provider asks for the same
documents.

## If the company is Slovak, the first route does not exist

Shopify Payments runs in a fixed list of countries. The
[supported-countries
list](https://help.shopify.com/en/manual/payments/shopify-payments/supported-countries),
checked on July 13, 2026, includes Czechia, Germany and Poland. It does
not include Slovakia.

For a Slovak entity, then, the first route is unavailable rather than
merely difficult, and no amount of persuading the owner to complete the
verification will change that. The choice narrows to Adyen, a second
store, or self-computed prices. Establish this early, before somebody
spends a week preparing an application that cannot be submitted.

## The question that decides it

The decision turns on who pays you in euros. If customers pay in euros,
the currency belongs to the payment processor, and Shopify gives you
two processors to choose between. If customers are quoted in euros and
settle against an invoice, the checkout never handles the currency, and
you are free to put the price wherever it is most useful.

Answer that first. Every option above is cheap or expensive depending
only on the answer, and it is a question for the business rather than
for the developer. The work that follows either answer is on our
[Shopify page](/services/shopify/).