BigCommerce-Mehrwährungs-Checkout: Erst Währungsrolle, dann Abbuchung prüfen
BigCommerce unterscheidet in seiner Währungsdokumentation zwischen der active currency und der transactional currency. Diese Trennung ist für die Abnahme entscheidend: Ein angezeigter Preis in einer Käuferwährung beweist nicht, dass auch in dieser Währung abgerechnet wird. Prüfen Sie deshalb Produktseite, Checkout und Bestell- beziehungsweise Zahlungsnachweis gemeinsam. Widersprechen sich diese Belege, sollte der Shop vor einer Ausweitung des Traffics überprüft werden. BigCommerce beschreibt die Währungsrollen und ihre Voraussetzungen in der offiziellen Übersicht.
Dieser Artikel richtet sich an Cross-Border-Händler, die die Währungsdarstellung ihres BigCommerce-Shops einrichten oder ändern und wissen müssen, was Käufer tatsächlich sehen und bezahlen.
Er hilft Shop-Verantwortlichen, Beschwerden zu Preis- oder Währungsabweichungen anhand des Kaufwegs einzugrenzen.
Auch für Abnahmeverantwortliche ist er gedacht, die Nachweise für unterschiedliche Märkte festhalten und über Freigabe, Korrektur oder Aufschub entscheiden müssen.
Währungsrollen als erster Prüfmaßstab
Die angezeigte Währung und die Transaktionswährung können unterschiedliche Aufgaben erfüllen. Eine active currency kann der Darstellung dienen; die transactional currency ist dagegen für die Währung maßgeblich, die BigCommerce für die Transaktion verwendet. Welche Auswahl ein Shop anbietet und wie der Checkout sie behandelt, hängt von der Konfiguration und den unterstützten Funktionen ab. Prüfen Sie dafür die aktuelle offizielle Dokumentation und die Einstellungen des konkreten Shops, statt aus einer allgemeinen Anleitung auf alle Storefronts zu schließen. Die Übersicht zu BigCommerce-Währungen erläutert die Begriffe und die Abhängigkeit von der jeweiligen Konfiguration.
| Prüfpunkt | Nur Anzeige in Käuferwährung | Transaktion in Käuferwährung | Nachweis für die Abnahme |
|---|---|---|---|
| Produktseite | Preis wird in einer anderen Währung dargestellt oder umgerechnet | Preis wird in der gewählten Transaktionswährung angezeigt | Währung und Preis auf der Produktseite festhalten |
| Warenkorb | Darstellung kann von der für die Transaktion verwendeten Währung abweichen | Warenkorb zeigt die Transaktionswährung für den Kauf | Sitzung, Auswahl und Warenkorbanzeige dokumentieren |
| Checkout | Währungsangabe und Zahlungsbedingungen genau lesen; Symbol allein genügt nicht | Checkout-Angabe mit Zahlungsoption und Transaktionsdaten abgleichen | Checkout-Anzeige und Zahlungsweg erfassen |
| Bestellung | Bestellwährung beweist nicht automatisch die endgültige Kartenabrechnung | Bestellwährung ist ein wesentlicher Beleg, ersetzt aber nicht die Zahlungsprüfung | Bestellfeld und Zahlungsnachweis vergleichen |
Wenn die Produktseite US-Dollar anzeigt, welche Währung wird dann belastet?
Das lässt sich nicht zuverlässig am Dollarzeichen ablesen. Prüfen Sie, ob der Betrag lediglich in einer aktiven Anzeigewährung dargestellt wird oder ob der Checkout die US-Dollar als Transaktionswährung ausweist. Gleichen Sie diese Anzeige anschließend mit der Währung der Bestellung und dem Transaktionsnachweis des Zahlungsanbieters ab. Die Bestellwährung und die Belastung auf dem Kartenkonto sind nicht automatisch derselbe Nachweis.
BigCommerce dokumentiert, wie Währungen im Katalog und im Warenkorb behandelt werden. Die Unterscheidung ist wichtig, weil ein umgerechneter Produktpreis nicht mit dem ursprünglichen Katalogpreis gleichgesetzt werden sollte. Eine Abweichung zwischen Produktseite und Warenkorb ist daher zuerst nach Darstellungs- und Transaktionslogik einzuordnen; sie ist nicht automatisch ein Grund, die Standardwährung des Katalogs zu ändern. Die Dokumentation zur Verarbeitung von Währungen in Katalog und Warenkorb ist hierfür der maßgebliche Ausgangspunkt.
Seitenübergreifende Preisstetigkeit erfassen
Eine belastbare Prüfung verwendet dieselbe Storefront, dasselbe Produkt und dieselbe Käufersitzung. Wer auf der Produktseite eine Währung notiert und später in einer anderen Sitzung den Checkout prüft, kann Unterschiede übersehen, die durch Markt-, Währungs- oder Sitzungswahl entstanden sind. Halten Sie daher nicht nur den Betrag, sondern auch die ausgewählte Marktdarstellung, die Währungsbezeichnung und den jeweiligen Bildschirm fest.
Was bedeutet es, wenn der Shop nur die lokale Währung zeigt, aber nicht in dieser Währung kassiert?
Dann kann die lokale Währung eine reine Anzeige- oder Umrechnungswährung sein. Entscheidend ist, welche Währung im Checkout als Transaktionswährung angegeben ist und welche Währung der Zahlungsweg tatsächlich verarbeitet. Dokumentieren Sie die beiden Angaben getrennt. Eine auf der Produktseite lokalisierte Preisangabe darf nicht als Beleg für eine lokale Abbuchung verwendet werden.
Für die Abnahme empfiehlt sich eine kurze, nachvollziehbare Aufzeichnung:
- Markt- oder Storefront-Auswahl zu Beginn der Sitzung.
- Produktseite mit Produktkennung, angezeigtem Betrag und sichtbarer Währungsangabe.
- Warenkorb nach dem Hinzufügen desselben Produkts, einschließlich der dortigen Währung.
- Checkout vor der Zahlungsbestätigung mit Preis, Währung und angezeigten Zahlungshinweisen.
- Bestellansicht sowie, soweit zugänglich, der Transaktionsdatensatz des Zahlungsanbieters.
Verwenden Sie für den Vergleich die tatsächlich sichtbaren Währungsnamen oder Codes, nicht allein Symbole. Ein Symbol kann in unterschiedlichen Ländern verwendet werden und beweist für sich genommen weder den Markt noch die Transaktionswährung. Notieren Sie außerdem, ob die Käuferseite die Währung aktiv gewählt hat oder ob die Storefront mit einer Standardauswahl geladen wurde. Damit bleibt die Prüfung später reproduzierbar.
Rabatte, Steuern und Versand als eigene Betragsbestandteile behandeln
Ein Gesamtbetrag kann sich verändern, obwohl die Produktwährung korrekt angezeigt wird. Rabatt, Steuer und Versand sind eigene Bestandteile des Warenkorbs und können je nach Konfiguration und unterstütztem Funktionsumfang anders berechnet oder dargestellt werden. Trennen Sie sie deshalb in Ihrer Aufzeichnung, statt nur den Endbetrag auf der Checkout-Seite zu notieren.
| Betragsbestandteil | Was auf Käuferseite zu prüfen ist | Typische Abweichungsquelle | Entscheidung bei Unklarheit |
|---|---|---|---|
| Produktpreis | Währung und Betrag auf Produktseite und im Warenkorb | Umrechnung oder abweichende Kataloggrundlage | Währungsrolle und Preisquelle im Shop prüfen |
| Rabatt | Angabe des angewendeten Rabatts und resultierender Betrag | Aktionsregel oder unterstützter Funktionsumfang | Rabattregel im Shop und im Checkout vergleichen |
| Steuer | Steuerbetrag, Bezeichnung und Währungsangabe | Markt- und Steuerkonfiguration | Einstellung und geltende Checkout-Anzeige kontrollieren |
| Versand | Versandbetrag, Währung und verwendete Versandoption | Lieferland, Versandregel oder nicht verfügbare Option | Mit identischer Lieferadresse erneut prüfen |
| Endbetrag | Summe und Währung unmittelbar vor der Zahlungsbestätigung | Zusammenspiel mehrerer Einzelpositionen | Einzelpositionen statt nur der Summe abgleichen |
Ändern Sie bei einer Differenz nicht sofort die Standardwährung. Prüfen Sie zunächst, ob die Abweichung von einer Preisumrechnung, einer Rabattregel, Steuerangaben, der Lieferadresse oder einer Checkout-Funktion herrührt. Welche Promotions, Preisfilter oder Checkout-Funktionen verfügbar sind, hängt von der konkreten Konfiguration und der aktuellen Unterstützung ab. Die verbindliche Prüfung gehört deshalb in das aktuelle BigCommerce-Backend und die dazugehörige offizielle Dokumentation, nicht in eine Annahme aus einem anderen Shop.
Welche Einstellungen und Zahlungsarten sind vor einem mehrwährungsfähigen Checkout zu prüfen?
Kontrollieren Sie, welche Währungen für die Storefront aktiviert sind, welche davon lediglich angezeigt werden und welche als Transaktionswährung vorgesehen sind. Prüfen Sie danach, ob der konfigurierte Zahlungsweg diese Transaktionswährung unterstützt und welche Währung im Checkout ausgewiesen wird. Die Einrichtung der Zahlungsintegration und die unterstützten Transaktionen müssen zur konkreten Anbieter-Konfiguration passen; BigCommerce beschreibt die relevanten Anforderungen in der Dokumentation zur Transactions API und Zahlungsanbieter-Konfiguration.
Zahlungsweg und tatsächliche Belastung auseinanderhalten
Für die Abnahme sind drei Ebenen getrennt zu betrachten: die Transaktionswährung des Shops, die Währung, in der der Zahlungsanbieter die Zahlung verarbeitet, und die Währung, in der ein Händler eine Auszahlung erhält. Diese Angaben können voneinander abweichen. Daraus folgt, dass eine sichtbare Währung auf der Storefront keine Aussage darüber erlaubt, welche Währung später auf der Händlerauszahlung erscheint.
Auch die endgültige Kartenabrechnung ist nicht allein durch BigCommerce festgelegt. Zahlungsanbieter und kartenausgebende Bank können bei einer Währungsumrechnung eigene Umrechnungskurse oder Gebühren anwenden. Solche Beträge darf ein Händler nicht als von BigCommerce kontrollierte Checkout-Gebühr behandeln. Für die technische Shop-Abnahme dokumentieren Sie den Checkout und die Bestellwährung; für eine Aussage zur konkreten Kartenbelastung benötigen Sie den Transaktionsbeleg beziehungsweise die Abrechnung des Zahlungswegs und gegebenenfalls die Kartenabrechnung.
Prüfen Sie den Zahlungsweg, ohne eine Testbestellung vorschnell als Beweis für jede spätere Zahlung zu verallgemeinern. Eine erfolgreiche Transaktion zeigt, dass diese konkrete Kombination aus Sitzung, Konfiguration und Zahlungsweg funktioniert hat. Sie bestätigt nicht automatisch, dass alle Käufermärkte, Karten oder Zahlungsoptionen dieselbe Währung verwenden. Notieren Sie daher die tatsächlich verwendete Option und halten Sie Abweichungen als offene Prüfbedingung fest. Die BigCommerce-Dokumentation zu Bestellungen erläutert Bestellfelder, während die Zahlungs- beziehungsweise Transaktionsdaten zusätzlich für die Kontrolle des Zahlungswegs heranzuziehen sind.
Bestellung und Transaktion als getrennte Belege abgleichen
Eine Bestellung ist ein wichtiger Nachweis für die Währung, in der BigCommerce den Auftrag gespeichert hat. Sie beweist jedoch nicht in jedem Fall, welche Währung beim Käufer letztlich auf dem Kartenkonto verbucht wird. Vergleichen Sie deshalb die Käuferanzeige mit dem Währungsfeld der Bestellung und – wenn die Frage die tatsächliche Belastung betrifft – mit dem verfügbaren Transaktionsnachweis.
Was ist zu tun, wenn Bestellwährung und angezeigter Käuferpreis voneinander abweichen?
Ermitteln Sie zunächst, ob auf der Käuferseite eine Anzeigeumrechnung aktiv war oder ob die falsche Marktauswahl beziehungsweise Standardsitzung geprüft wurde. Stimmen Produktseite, Checkout und Bestellung danach weiterhin nicht überein, sollte die Freigabe ausgesetzt und die Währungs- sowie Zahlungsanbieter-Konfiguration untersucht werden. Ist dagegen nur die Händlerauszahlung in einer anderen Währung ausgewiesen, muss zusätzlich die Abrechnung des Zahlungsanbieters geprüft werden; das allein belegt noch keinen Fehler in der Käuferanzeige.
Für eine nachvollziehbare Abnahme sollten Sie zwei Sitzungsarten getrennt erfassen: eine Sitzung, in der ein Käufer eine angebotene Währung ausdrücklich auswählt, und eine Sitzung mit der voreingestellten Marktauswahl. Halten Sie pro Sitzung die sichtbare Währungsbezeichnung auf Produktseite, Warenkorb und Checkout sowie die Bestellwährung fest. Wenn ein Zahlungsnachweis verfügbar ist, ergänzen Sie dessen Währungsangabe, ohne sie mit der Händlerauszahlung gleichzusetzen.
Safari-Käuferprüfung reproduzierbar durchführen
Die Safari-Käuferseiten-Abnahme dient dazu, die reale Darstellung in Safari zu prüfen, nicht die Plattformregeln zu verändern. Safari oder ein Mac-Standort ändern weder die von BigCommerce unterstützte Zahlungsfähigkeit noch garantieren sie eine erfolgreiche Transaktion. Sie ermöglichen lediglich, eine zusätzliche Browser- und Gerätekombination kontrolliert zu untersuchen. Für Seiteninspektion und Fehlersuche erläutert Apple den Einsatz des Safari Web Inspector.
Gehen Sie für eine reproduzierbare Prüfung wie folgt vor:
- Prüfumgebung festhalten. Notieren Sie Browser, Gerätetyp, ausgewählten Markt und den Startpunkt der Storefront. Verwenden Sie dieselbe Umgebung für die zusammengehörigen Seiten, damit Unterschiede nicht aus einem Sitzungswechsel stammen.
- Marktauswahl dokumentieren. Öffnen Sie den vorgesehenen Markteinstieg und erfassen Sie, welche Währung vorausgewählt ist und ob der Käufer sie selbst ändern kann.
- Produktseite prüfen. Schreiben Sie angezeigten Betrag, Währungsbezeichnung und sichtbare Preis- oder Umrechnungshinweise auf. Verwenden Sie ein Produkt, das sich später im Warenkorb eindeutig wiedererkennen lässt.
- Warenkorb vergleichen. Prüfen Sie dieselbe Sitzung und dasselbe Produkt. Halten Sie Einzelpreis, Rabatt, Steuer- und Versandangaben getrennt fest, sobald diese im Warenkorb sichtbar sind.
- Checkout kontrollieren. Lesen Sie die Währungsangabe und die Hinweise zum Zahlungsweg vor einer verbindlichen Zahlungsbestätigung. Eine Währung, die nur auf der Produktseite sichtbar war, genügt nicht als Beleg.
- Bestellung und Transaktion abgleichen. Nach einer autorisierten Testbestellung oder einer regulären Bestellung vergleichen Sie die Käuferansicht mit dem Bestellwährungsfeld und dem verfügbaren Zahlungsnachweis.
- Abweichung einordnen. Ordnen Sie sie der Anzeigeumrechnung, dem Markt, einem Preisbestandteil, der Zahlungsanbieter-Konfiguration oder der Abrechnung zu. Ist die Ursache nicht belegt, lassen Sie die Prüfung offen und eskalieren Sie sie, anstatt eine Währungsänderung auf Verdacht vorzunehmen.
Apples Responsive Design Mode unterstützt die Prüfung responsiver Layouts, ist jedoch kein Ersatz für einen Test auf einem tatsächlichen Mobilgerät. Das ist besonders relevant, wenn die Abnahme eine mobile Safari-Kaufstrecke umfasst: Ein simuliertes Ansichtsfenster kann Layoutverhalten untersuchen, belegt aber nicht automatisch das Verhalten eines realen Geräts. Apple beschreibt sowohl den Zweck des Responsive Design Mode als auch die Inspektion von Webseiten auf verbundenen iOS-Geräten. Wählen Sie die Prüfung entsprechend der tatsächlich freizugebenden Käuferumgebung.
Freigabe anhand der Beleglage entscheiden
Verwenden Sie für die Entscheidung folgende Bedingungen:
- Freigabe: Produktseite, Warenkorb und Checkout weisen die erwartete Anzeige aus; die Transaktionswährung ist im Checkout nachvollziehbar und passt zur verfügbaren Zahlungsoption. Die Bestellwährung widerspricht diesem Ablauf nicht.
- Korrektur vor Freigabe: Die Käuferanzeige oder ein Betragsteil weicht ab, aber die Ursache lässt sich einer Preis-, Markt-, Steuer-, Versand- oder Rabattregel zuordnen. Korrigieren Sie die konkrete Regel und wiederholen Sie den Kaufweg.
- Aufschub und Eskalation: Checkout, Bestellwährung und Transaktionsnachweis widersprechen sich oder lassen sich nicht eindeutig zuordnen. Begrenzen Sie bis zur Klärung eine Ausweitung des Traffics auf den betroffenen Kaufweg und lassen Sie Shop- und Zahlungsanbieter-Konfiguration prüfen.
Das Ergebnis sollte nicht nur „bestanden“ oder „fehlgeschlagen“ lauten. Bewahren Sie die Marktauswahl, die Käuferansichten, die Checkout-Währung, den Bestellnachweis und – falls geprüft – den Transaktionsbeleg zusammen auf. So kann das Team unterscheiden, ob es sich um ein Anzeigeproblem, eine falsch verstandene Abrechnungswährung oder einen offenen Zahlungsanbieter-Fall handelt.
Wenn für solche Käuferprüfungen bisher nur ein einzelner Entwicklerrechner oder wechselnde Testgeräte bereitstehen, sind die Nachteile vor allem unvollständige Wiederholbarkeit, schwer vergleichbare Sitzungen und fehlende Kontinuität bei der Safari-Prüfung. Ein Mac zur eigenen Nutzung ist sinnvoll, wenn das Team dauerhaft und intensiv auf derselben physischen Umgebung testen muss; eine virtuelle Vorschau bleibt für echte Geräteprüfungen begrenzt. Wenn die Prüfung einen US-amerikanischen Markteinstieg umfasst, kann das Team außerdem die verfügbaren Angaben zum RUVCLOUD-Angebot für die US-Ostküste mit den Anforderungen an die eigene Testumgebung abgleichen. Für eine zeitlich begrenzte, reproduzierbare Safari-Abnahme kann ein gemieteter Remote Mac von RUVCLOUD eine passendere Testumgebung sein – ohne dadurch BigCommerce-Zahlungsregeln zu umgehen oder ein bestimmtes Abbuchungsergebnis zu garantieren. Prüfen Sie zunächst die verfügbaren RUVCLOUD-Angebote und wählen Sie eine Umgebung nur dann, wenn sie zum vorgesehenen Test passt.