Viele Haendler verstehen Internationalisierung in PrestaShop an einer entscheidenden Stelle falsch: Sie glauben, "multi-currency" bedeute nur, eine andere Zahl mit einem anderen Symbol anzuzeigen. Das stimmt nicht. Eine Waehrung in PrestaShop ist ein kleines Objekt mit eigenem Wechselkurs, eigenem Rundungsverhalten, eigener Symbolposition und - wenn Sie es so wollen - eigenen bewusst gesetzten Preisen, die nichts mit dem Live-Wechselkurs zu tun haben. Wenn diese Mechanik stimmt, sieht ein deutscher Kunde saubere €49,00 und ein britischer Kunde ordentliche £42.00, beide korrekt abgerechnet, beide mit Vertrauen in die Zahl. Wenn sie nicht stimmt, liefern Sie Preise wie £41.73 aus, die "automatisch umgerechnet" schreien und Sie still den Verkauf kosten. In diesem Leitfaden geht es gezielt um die Waehrungsebene - den Teil des internationalen Verkaufs, der in International → Localization lebt oder stirbt.

Der Fokus ist bewusst eng. Steuern, VAT und das groessere Thema "Verkauf in Europa" haben ihren eigenen Leitfaden (Verkauf in Europa: Sprachen, Waehrungen und Steuern); die Uebersetzung Ihres Katalogs ist ein Multi-Language-Setup; und das kleine Flaggen- und Dropdown-Element, mit dem Kunden wechseln, ist ein eigenes Front-Office-Detail. Hier bleiben wir beim Geld.

Was eine "Waehrung" in PrestaShop wirklich ist

Jede Waehrung, die Sie hinzufuegen, ist eine Zeile in der Tabelle currency, geladen als Currency-Objekt (Klasse Currency in classes/Currency.php). Die Felder, die im Alltag zaehlen, sind der ISO-Code (EUR, GBP, USD - er steuert das Symbol und haengt an PrestaShops CLDR-Formatierung), der conversion rate relativ zu Ihrer Standardwaehrung sowie precision- und rounding-Einstellungen. Ihre Standardwaehrung hat immer exakt den Wechselkurs 1; jede andere Waehrung wird als Multiplikator davon ausgedrueckt. Wenn Ihre Standardwaehrung also EUR ist und Sie GBP mit einem Kurs von 0.85 hinzufuegen, nimmt PrestaShop den EUR-Preis und multipliziert ihn mit 0.85, um Pfund anzuzeigen.

Dieser eine Satz ist die Quelle der meisten Multi-Currency-Verwirrung, deshalb muss man es klar sagen: Preise in PrestaShop werden einmal gespeichert, in der Standardwaehrung, und fuer alle anderen live umgerechnet. Ein Produkt mit Preis 100 im Back Office ist "100 von dem, was Ihre Standardwaehrung ist". Wenn Sie die Standardwaehrung aendern, nachdem Preise eingetragen sind, haben Sie nichts neu bepreist - Sie haben nur jede Zahl im Katalog neu beschriftet. Das ist der teuerste Fehler, den wir sehen: Waehlen Sie die Standardwaehrung zuerst, bevor Sie einen einzigen Produktpreis eintragen, und aendern Sie sie nie in einem Live-Shop mit bestehenden Bestellungen.

Eine Waehrung richtig hinzufuegen

Gehen Sie zu International → Localization → Currencies und klicken Sie auf Add new currency. Ab PrestaShop 1.7.6 wird das Formular von CLDR-Locale-Daten gespeist. Wenn Sie den ISO-Code auswaehlen, werden Symbol, Dezimalpraezision und Formatmuster automatisch gefuellt - Sie muessen selten manuell bearbeiten, wie eine Zahl angezeigt wird. Die Felder, ueber die Sie wirklich entscheiden:

  • Currency - der ISO-4217-Code. Das ist der Hauptschluessel; er setzt Symbol (€, £, $) und Formatmuster. Nutzen Sie den echten Code, kein eigenes Label, sonst verhalten sich CLDR-Formatierung und Zahlungsanbieter, die die Waehrung lesen, falsch.
  • Exchange rate - der Multiplikator gegen Ihre Standardwaehrung. Geben Sie ihn als "wie viele Einheiten dieser Waehrung entsprechen einer Einheit meiner Standardwaehrung" ein. Dieses Feld wird oft umgedreht; wenn Ihr mit €100 bepreistes Produkt als £117 statt £85 erscheint, steht der Kurs auf dem Kopf.
  • Status - aktivieren/deaktivieren. Deaktivieren Sie eine Waehrung, statt sie zu loeschen, sobald Bestellungen existieren, damit historische Bestellungen ihren Waehrungskontext behalten.

Dezimalstellen und Rundung sind in neueren Versionen aus der Waehrungsmaske herausgewandert - CLDR liefert Standardformatierung und Symboldaten, trotzdem sollten Sie Praezision und Dezimaleinstellungen in der Waehrungskonfiguration pruefen. Der Rundungsmodus liegt global unter Shop Parameters → General → Set rounding method for prices (die Konfigurationswerte PS_PRICE_ROUND_MODE und PS_ROUND_TYPE). Das ist wichtiger, als es klingt, und darum geht es im naechsten Abschnitt.

Rundung: die unscheinbare Einstellung, die Marge und Buchhaltung schuetzt

PrestaShops Rundungsmodus entscheidet, ob 49.005 zu 49.00 oder 49.01 wird - und bei Tausenden umgerechneten Positionen ist der Unterschied echtes Geld und, schlimmer, eine Quelle fuer abweichende Summen, die Buchhaltung und Kunden verunsichern. Zwei Einstellungen greifen ineinander:

  • Rounding mode (Shop Parameters → General): PrestaShop bietet sechs Modi - "Round up away from zero" (kaufmaennisches Half-up, Standard), "Round down towards zero" (Half-down), "Round to the nearest even value" und "Round to the nearest odd value" (Banker's-Rounding-Varianten) sowie einfach "Round up to the nearest value" (ceil) und "Round down to the nearest value" (floor). Fuer einen Shop ist der Standard Half-up die berechenbare Wahl - das erwarten Kunden und Finanzbehoerden.
  • Round type: runden auf jedem Artikel, auf jeder Zeile oder auf der Gesamtsumme. Rundung pro Zeile und anschliessendes Summieren kann einen Warenkorb erzeugen, der um einen Cent von der Summe abweicht, die ein Kunde per Hand addiert. Rundung auf Gesamtsumme vermeidet die Support-Mail "Ihre Rechnung stimmt nicht", kann aber einzelne Zeilenpreise leicht inkonsistent wirken lassen. Entscheiden Sie sich fuer eine Variante und dokumentieren Sie sie; aendern Sie sie nicht mehr, sobald Rechnungen im Umlauf sind.

Und was heisst das? Wenn das einmal richtig sitzt, wirken umgerechnete Preise bewusst gesetzt und Ihre Rechnungen lassen sich abstimmen. Wenn es falsch ist, wird jede Bestellung in umgerechneter Waehrung zu einer kleinen Rundungsdiskussion, multipliziert mit jeder Bestellung in dieser Waehrung.

Wechselkurse aktuell halten, ohne sie staendig zu betreuen

Ein fest eingetragener Wechselkurs ist ein langsames Leck. Setzen Sie GBP im Januar auf 0.85, lassen Sie es so, und im Fruehling berechnen Sie entweder zu wenig oder schrecken Kunden mit einem Preis ab, der nicht mehr zur Realitaet passt. PrestaShop bringt dafuer einen eingebauten Updater mit. Auf der Seite Currencies gibt es die Aktion Update currency rates, die frische Kurse zieht (PrestaShops Waehrungsfeed / die mitgelieferte Kursquelle) und den conversion rate fuer jede Nicht-Standardwaehrung mit einem Klick neu schreibt.

Ein Buttonklick von Hand ist aber nicht "automatisch". Haengen Sie ihn an den Scheduler, damit er selbst laeuft. PrestaShop liefert ein eigenes Skript cron_currency_rates.php in Ihrem Admin-Ordner, und die Seite Currencies zeigt im Panel "Automatically update currency rates" die fertige URL (inklusive secure_key); diese URL tragen Sie in die Server-Crontab ein, zum Beispiel fuer einen taeglichen Lauf am fruehen Morgen:

  • Planen Sie ihn vor dem Tagestraffic - ein frueher Lauf (etwa 06:00 Serverzeit) bedeutet frische Preise, bevor die ersten europaeischen Kunden eintreffen, und ein fehlerhafter Abruf hat Stunden, um aufzufallen, bevor die Spitze kommt.
  • Behandeln Sie den Feed als fehlbar. API-Ausfaelle koennen gelegentlich eine Null oder einen extrem falschen Kurs liefern, und ein schlechter Kurs verfaelscht still jeden Preis in dieser Waehrung. Bauen Sie eine Plausibilitaetspruefung ein - notfalls ein morgendlicher Blick oder ein Guard, der keinen Kurs uebernimmt, der sich ueber Nacht um mehr als zum Beispiel 10% bewegt hat -, bevor Sie ihn unbeaufsichtigt vertrauen.
  • Planen Sie einen Margenpuffer ein. Live-Mittelkursen fehlt der Spread, den Ihr Zahlungsanbieter bei der Auszahlung berechnet. Wenn Sie zum Rohkurs umrechnen, frisst der Processor-Anteil bei jeder Auslandsbestellung Ihre Marge. Viele Haendler setzen den automatisch aktualisierten Kurs und legen dann einen kleinen Aufschlag darauf oder bepreisen Schluesselwaehrungen manuell (naechster Abschnitt), genau um das zu vermeiden.

Manuelle Preise pro Waehrung: wann Sie gar nicht mehr umrechnen sollten

Hier ist die Funktion, die viele Haendler nie entdecken, und sie ist der groesste Hebel, um wie ein lokaler Anbieter statt wie ein Tourist zu wirken. PrestaShop laesst Sie den umgerechneten Preis pro Waehrung auf Produktebene ueberschreiben, im Tab Pricing des Produkts ueber Specific prices. Statt die Engine aus einer €49-Basis £41.73 ausspucken zu lassen, setzen Sie den GBP-Preis explizit auf £42.00 - eine saubere, psychologisch sinnvolle Zahl - nur fuer diese Waehrung.

Warum das ganz praktisch zaehlt:

  • Charm Pricing ueberlebt die Grenze. Ein €49,00-Produkt, das automatisch zu £41.73 wird, wirft jede Preispsychologie weg, die Sie zu Hause eingesetzt haben. Ein spezifischer Preis stellt die £42.00 (oder £39.99) wieder her, die wirklich konvertiert.
  • Sie jagen dem Wechselkurs nicht hinterher. Ein fixer lokaler Preis wackelt nicht jedes Mal, wenn der Kurs-Updater laeuft. Ihr UK-Shop hat einfach UK-Preise.
  • Sie bepreisen nach Markt, nicht nach Mathematik. Wenn britische Kaeufer eine hoehere Zahl akzeptieren oder Sie in dieser Region zusaetzliche Versandkosten tragen, setzen Sie das bewusst, statt zu nehmen, was der Multiplikator liefert.

Der ehrliche Nachteil: Specific prices sind produktbezogen, also ist es ohne Import oder Pricing-Tool nicht realistisch, tausend SKUs in fuenf Waehrungen von Hand zu pflegen. Das pragmatische Muster ist dasselbe wie bei Uebersetzungen: Machen Sie es fuer Ihre Bestseller. Setzen Sie bewusste lokale Preise auf die Top 20% der Produkte, die den groessten Umsatz treiben, und lassen Sie saubere automatische Umrechnung den Long Tail abdecken.

Was der Kunde sieht - und wie die Abrechnung wirklich passiert

Wenn ein Kunde die Waehrung wechselt (ueber den Front-Office-Selector, den wir in Currency Selector und Language Flags behandeln), speichert PrestaShop diese Wahl im Warenkorb und berechnet Anzeigepreise ueber denselben Umrechnungspfad neu. Entscheidend ist: Die Bestellung wird in der Waehrung gespeichert, in der der Kunde tatsaechlich checkout gemacht hat - id_currency wird auf Warenkorb und Bestellung gespeichert, und die Rechnung wird in dieser Waehrung erzeugt. Ihre Back-Office-Bestellliste und Ihre Buchhaltung sehen also "dieser Kunde hat £42.00 bezahlt", nicht einen EUR-Betrag mit Sternchen.

Die Auszahlungsrealitaet sollten Sie im Kopf behalten: Ihr Zahlungsanbieter, nicht PrestaShop, entscheidet, was auf Ihrem Bankkonto landet. Stripe, PayPal, Mollie und andere haben jeweils eigene Regeln fuer Multi-Currency-Auszahlung und Umrechnung - manche zahlen jede Waehrung nativ aus, manche konvertieren alles zurueck in Ihre Kontowaehrung und nehmen dabei einen Spread. PrestaShop belastet dem Kunden die richtige lokale Zahl; was Ihr Processor auf dem Weg zu Ihrem Konto daraus macht, ist eine separate Frage, die Sie fuer das konkrete Gateway pruefen sollten, bevor Sie eine neue Waehrung live schalten.

Geolocation: die richtige Waehrung vorsichtig vorauswaehlen

PrestaShop kann die Waehrung eines Besuchers anhand seines Standorts schaetzen, sodass ein UK-Besucher ohne Klick in Pfund landet. Das liegt unter International → Localization → Geolocation und nutzt die MaxMind-GeoLite2-Datenbank, die Sie von MaxMind herunterladen und in PrestaShop hochladen (das aeltere gebuendelte GeoLite wurde eingestellt, ein aktueller Shop braucht also die GeoLite2-Datei). Ist sie aktiviert, koennen Besucher aus einem bestimmten Land standardmaessig auf passende Waehrung und Land gesetzt werden.

Zwei Warnungen, weil man Geolocation leicht zu viel zutraut:

  • Sperren Sie die Wahl nie. Geolocation sollte vorauswaehlen, nie erzwingen. Ein Expat, ein Reisender oder jemand mit VPN wird falsch erkannt; wenn er nicht in die Waehrung zurueckwechseln kann, in der er denkt, geht er. Halten Sie den Currency Selector immer sichtbar.
  • Halten Sie die GeoLite2-Datenbank frisch. IP-zu-Land-Zuordnungen verschieben sich; eine veraltete Datenbank leitet mit der Zeit einen wachsenden Anteil der Besucher falsch. Aktualisieren Sie sie nach Plan, genauso wie Wechselkurse.

Eine Standardwaehrung oder ein Shop pro Markt?

Ein einzelner PrestaShop-Shop kann viele Waehrungen zugleich bedienen - das ist alles oben Beschriebene. Aber es gibt einen Punkt, an dem "viele Waehrungen in einem Shop" nicht mehr reicht: wenn jeder Markt nicht nur eine andere Waehrung braucht, sondern eine andere Standardwaehrung, nativ eingetragene statt umgerechnete Preise, eine andere Domain oder einen anderen Katalog. Dann greifen Sie zu Multistore, also zum Beispiel einem EUR-Shop fuer die Eurozone und einem GBP-Shop fuer UK aus einem Back Office, jeweils mit eigener Standardwaehrung und eigener Preisbasis. Das ist eine groessere Architekturentscheidung, die wir in mehrere Shops aus einem Admin-Panel betreiben durchgehen.

Eine schnelle Entscheidungshilfe:

Wenn Sie...Nutzen Sie
Denselben Katalog verkaufen und Kunden nur in ihrer eigenen Waehrung sehen und bezahlen lassen wollenMulti-Currency in einem Shop (dieser Leitfaden)
Bewusste, saubere lokale Preise auf Ihren Bestsellern wollenEin Shop + Specific prices pro Waehrung
Fuer jeden Markt eigene Standardwaehrung, eigene Domain oder anderes Sortiment brauchenMultistore, eine Standardwaehrung pro Shop

Eine praktische Launch-Reihenfolge fuer eine neue Waehrung

Zusammengefasst ist das die Reihenfolge, die teure Fehler vermeidet:

  • Bestaetigen Sie, dass Ihre Standardwaehrung richtig und final ist, bevor alles andere passiert - sie ist die Basis jeder Umrechnung und das eine Element, das Sie spaeter nicht aendern duerfen.
  • Fuegen Sie die neue Waehrung mit ihrem echten ISO-Code hinzu, damit CLDR-Formatierung und Gateways korrekt arbeiten.
  • Setzen Sie den Wechselkurs richtig herum und pruefen Sie den umgerechneten Preis eines Produkts per Bauchcheck, bevor Sie weitermachen.
  • Legen Sie Rundungsmodus und Round type in den Shop Parameters fest und lassen Sie sie unveraendert, sobald Bestellungen existieren.
  • Automatisieren Sie den Kurs-Updater mit taeglichem Cron-Lauf und Plausibilitaets-Guard gegen Null- oder Muellkurse.
  • Setzen Sie bewusste Specific prices auf Ihre Bestseller in der neuen Waehrung, damit die Zahlen lokal wirken, nicht automatisch umgerechnet.
  • Pruefen Sie die Auszahlung mit Ihrem Zahlungsanbieter fuer diese Waehrung, platzieren Sie dann eine echte Testbestellung und lesen Sie die Rechnung.

Die Abdeckung der Zahlungsmethoden ist genauso wichtig wie der Preis - ein deutscher Kunde, der Rechnung erwartet, oder ein niederlaendischer Kunde, der iDEAL erwartet, bricht einen reinen Karten-checkout ab, egal wie sauber Ihre Europreise sind. Das ist eine Payment-Stack-Entscheidung statt eine Waehrungsfrage; das groessere regionale Bild liegt in Verkauf in Europa.

Multi-Currency in PrestaShop belohnt Haendler, die es als Pricing-Disziplin behandeln, nicht als Anzeige-Schalter. Die Plattform rechnet auf Autopilot gerne alles fuer Sie um - und "alles auf Autopilot" ist genau das, was £41.73-Preise und Kursfeed-Ueberraschungen produziert. Entscheiden Sie Ihre Standardwaehrung einmal und dauerhaft, automatisieren Sie Kurse mit Guardrail und bepreisen Sie Ihre wichtigsten Produkte in jedem Markt von Hand. Dann ist jede neue Waehrung ein Markt, der Preise sieht, die fuer ihn gemacht wurden - und genau darum geht es beim Verkauf ins Ausland.

Diesen Beitrag teilen:
David Miller

David Miller

Über ein Jahrzehnt praktische PrestaShop-Expertise. David entwickelt leistungsstarke E-Commerce-Module mit Fokus auf SEO, Checkout-Optimierung und Shop-Management. Leidenschaft für sauberen Code und messbare Ergebnisse.

Hat Ihnen dieser Artikel gefallen?

Erhalten Sie unsere neuesten Tipps, Anleitungen und Modul-Updates direkt in Ihr Postfach.

Kommentare

Noch keine Kommentare. Seien Sie der Erste!

Stellen Sie als Erster eine Frage oder teilen Sie hilfreiches Feedback.

Lade ...
Nach oben