Am 18. April 2024 schob Shopify eine Changelog-Notiz in die Welt, die in keinem DACH-Händler-Postfach landen wird. Kein Marketing, kein Blogpost, nur eine Zeile für Developer. Ab GraphQL Admin API 2026-10 enthält ShopifyPaymentsTransactionType den neuen Typ CURRENCY_CONVERSION. Das klingt nach einem technischen Randdetail. Es ist die späte Offenlegung eines Problems, das jeden Händler betrifft, der in mehr als einer Währung verkauft.
„As of GraphQL Admin API version 2026-10, ShopifyPaymentsTransactionType now includes CURRENCY_CONVERSION type.“ — shopify.dev Changelog
Was da steht, ist harmlos formuliert. Was es bedeutet, ist es nicht: Bis zu diesem Update tauchten Währungsumrechnungen in den Shopify Payments Balance Transactions schlicht nicht als eigener Typ auf. Wer über die API seine Auszahlungen, Gebühren und Rückerstattungen automatisiert auswertet, konnte Umrechnungsverluste nicht sauber isolieren. Sie verschwanden – je nach Setup – in Sammelbuchungen oder wurden gar nicht sichtbar.
Wer Multi-Currency als Feature verkauft, schuldet Multi-Currency als Transparenz
Shopify Markets, Shopify Payments, lokale Preise in acht Währungen – das ist seit Jahren die Wachstumsstory. Der Händler darf in Euro, Schweizer Franken, Pfund und Zloty verkaufen und bekommt ein Gefühl von globaler Reichweite. Was er nicht bekommt: eine saubere, API-lesbare Aufschlüsselung, was ihm auf jedem dieser Wege durch Umrechnung, Wechselkurs-Spread und Timing verloren geht. Bis jetzt.
Man muss kein Zyniker sein, um hier ein Muster zu erkennen. Die Plattform monetarisiert Währungsumrechnung über eigene Spreads – und liefert Entwickler-Tools, die genau diese Spreads transparent machen, erst nachgelagert. Das ist im Kern eine Governance-Frage. Wer die Datenhoheit über Conversions in einer proprietären Payment-Schicht hält, entscheidet, was Händler sehen können. Der neue CURRENCY_CONVERSION-Typ ist kein Geschenk an die Community. Er ist die späte Reaktion auf Anforderungen von Agenturen und ERP-Anbindungen, die seit Jahren stöhnen.
Für DACH-Händler ist der Fall besonders pikant. Der typische Mid-Market-Händler hier verkauft in EUR als Home Currency, aber liefert in CH, AT, oft auch PL und CZ. Jede Order löst eine Conversion aus – oder eine Auszahlung über eine lokale Währung. Wer sein Controlling mit DATEV, sevdesk oder einem eigenen Data Warehouse fährt, musste bis dato kreativ werden: manuelles Matching, Excel-Exporte, geschätzte Durchschnittskurse. Das ist 2024 nicht tragbar, und Shopify weiß es.
Was jetzt konkret zu tun ist – und was es den Händler kostet
Die praktische Konsequenz ist unspektakulär und überfällig zugleich. Wer die GraphQL Admin API ohnehin nutzt – und das tun alle ernsthaften Multi-Currency-Setups – kann ab Version 2026-10 Währungsumrechnungen als eigenen Transaktionstyp abfragen. Damit lässt sich endlich sauber rechnen: Welcher Anteil der Payment-Fees entfällt auf Conversion? Wie stark verschiebt sich die Netto-Marge, wenn der EUR/CHF-Kurs in einer Woche um 1,5 Prozent schwankt? Das sind keine akademischen Fragen. Bei einem Händler mit zehn Millionen Euro GMV und 30 Prozent Auslandsanteil reden wir über sechs- bis siebenstellige Beträge, die jährlich durch Kurse, Spread und Settlement-Timing wandern.
Nur: Die API-Version 2026-10 ist nicht sofort überall verfügbar. Ältere Versionen bleiben ohne diesen Typ. Wer in einer stabilen API-Version hängt, muss migrieren – und Migration kostet Entwicklerzeit, Regressionstests, Downtime-Fenster. Für Agenturen heißt das: ein neues Projekt, das niemand eingeplant hat. Und für Händler heißt es: ein weiteres Quartal, in dem die Conversion-Kosten noch im Nebel liegen.
Der eigentliche Skandal liegt aber nicht in der API-Reife. Er liegt in der Standardsetzung. Kein einziger anderer großer Payment-Stack im europäischen Raum – Adyen, Mollie, Stripe Connect – hat DACH-Händler so lange ohne granularen Conversion-Reporting-Typ gelassen, wie es Shopify bei seinen eigenen Payments getan hat. Das ist ein Wettbewerbsproblem für die gesamte Plattform, nicht nur für einzelne Shops. Und es ist ein Argument dafür, die Payment-Schicht wieder als das zu behandeln, was sie ist: Finanzinfrastruktur mit Buchhaltungspflicht, kein Produktfeature.
Wer heute in DACH Multi-Currency fährt, sollte drei Dinge tun. Erstens: gegen die Balance Transaction API testen, ob der neue Typ in der eigenen Umgebung tatsächlich die Conversions sauber splittet. Zweitens: die eigene Controlling-Logik so umbauen, dass Conversion-Verluste eine eigene Kostenstelle bekommen – nicht als Sammelposten. Drittens: die Spreads über zwölf Monate rückwirkend auswerten, soweit Daten vorhanden sind. Wer das nicht tut, wird beim nächsten FX-Schock nicht wissen, ob die Marge eingebrochen ist, weil der Einkauf teurer wurde – oder weil Shopify Payments still an der Umrechnung verdient hat.
Und die unangenehme Frage bleibt: Wenn Player wie Shopify Conversions jahrelang nicht als eigenen Transaktionstyp ausweisen, wie viele andere Kostenzeilen in der Payment-Abwicklung bleiben unsichtbar? Der neue CURRENCY_CONVERSION-Typ ist kein Grund zum Feiern. Er ist der Beweis, dass Händler ihre eigenen Zahlen nie vollständig besessen haben. Wer das jetzt nicht zum Anlass nimmt, die Payment-Architektur radikal zu prüfen, hat den eigentlichen Patch verpasst.