Ein Pflichtfeld verschwindet. In der Payments Apps API ist der Nachname (family_name) im shipping_address und billing_address für B2B-Bestellungen jetzt optional. Für Payment-Apps, die bislang ein hartes Validierungsschema fahren – Nachname rein, sonst Abbruch – ist das kein kosmetisches Update. Es ist die stille Ursache für fehlgeschlagene Checkouts, die im B2B-Segment seit Monaten Conversion kosten.
Denn B2B-Checkout funktioniert anders als B2C. Im Geschäftskundengeschäft ist der Rechnungsempfänger häufig eine juristische Person, die Bestellung läuft auf eine Firma, eine Abteilung, eine Kostenstelle. Der Nachname des einkaufenden Mitarbeiters ist für die Rechnungsstellung irrelevant – und in vielen Fällen schlicht nicht bekannt, weil Bestellungen zentral über Procurement-Tools, Punch-out-Kataloge oder ERP-Anbindungen ausgelöst werden.
Was sich in der Payments Apps API konkret geändert hat
Die Änderung ist eng umrissen: family_name in shipping_address und billing_address ist für B2B-Bestellungen nicht mehr verpflichtend. Die API akzeptiert Payment-Session-Requests, in denen das Feld fehlt oder leer bleibt. Das gilt nicht für B2C-Orders – dort bleibt der Nachname Pflicht, weil Verbraucher- und Geschäftskundengeschäft unterschiedlichen regulatorischen und fiskalischen Logiken folgen.
Der Knackpunkt liegt nicht in der API, sondern in den Payment-Apps, die darauf aufsetzen. Viele von ihnen haben ihre Request-Validierung defensiv gebaut: Pflichtfelder definieren, bevor der Request rausgeht, um fehlerhafte Sessions früh abzufangen. Sinnvoll – bis sich die Spezifikation ändert. Dann wird aus defensiver Programmierung ein Umsatzblocker.
Warum verlieren Händler B2B-Umsatz an der Validierungsschicht?
Ein abgelehnter Payment-Session-Request ist ein stummer Fehler. Der Käufer bekommt in der Regel keine hilfreiche Fehlermeldung, der Händler sieht einen Abbruch, das Monitoring zählt eine fehlgeschlagene Checkout-Session. Bei B2C ist das ein Conversion-Problem mit bekanntem Muster. Bei B2B ist es oft ein Integrationsproblem, das niemandem auffällt – weil das Volumen kleiner ist und der einzelne Warenkorbwert deutlich höher.
Genau diese Relation macht die Sache teuer. Ein B2B-Warenkorb liegt nicht bei 60 Euro, sondern häufig bei mehreren Tausend. Wenn ein Payment-Gateway oder eine Buy-Button-App den Request wegen eines fehlenden Nachnamens verwirft, kostet das nicht einen verlorenen Sale, sondern einen verlorenen Beschaffungsvorgang – inklusive der Folgebestellungen, die an einem abgebrochenen ersten Checkout scheitern.
B2B-Checkout ist kein größerer B2C-Checkout. Es ist ein anderer Kaufvorgang mit anderen Pflichtfeldern, anderen Freigabeprozessen und anderen Haftungsverhältnissen.
Hinzu kommt die Datenlage: Viele B2B-Adressen stammen aus ERP-Systemen wie SAP, aus Rechnungsprüfungssystemen oder aus Procurement-Plattformen. Dort wird zwischen Lieferanschrift und Rechnungsanschrift unterschieden, oft mit Firmenname, Abteilung, Gebäude, Kostenstelle – aber ohne den Nachnamen eines Einkäufers, der im System schlicht nicht als Feld existiert. Eine Payment-App, die family_name hart verlangt, fordert Daten an, die die Quelle nicht liefert.
Wie sollten Payment-Apps ihre Validierung umbauen?
Die pragmatische Antwort: Der Order-Typ muss die Validierung steuern. Apps, die sowohl B2C als auch B2B abwickeln, sollten die Adressvalidierung an das Flag oder den Kontext der Bestellung koppeln. Für B2B heißt das: family_name optional, dafür andere Felder prüfen, die im Geschäftskundenkontext tatsächlich Pflicht sind.
- Firmenname und USt-IdNr. treten an die Stelle natürlicher Personendaten – die Umsatzsteuer-Identifikationsnummer ist bei innergemeinschaftlichen Lieferungen belegungsrelevant.
- Rechnungsadresse ≠ Lieferadresse: Im B2B ist die Trennung von Bestell-, Rechnungs- und Lieferanschrift Standard, nicht Ausnahme.
- Abweichende Empfänger (z. B. Logistik-Dienstleister, Zentrallager) müssen ohne Personenbezug adressierbar bleiben.
Wer die Validierung zuerst nach Logik und nicht nach Feldnamen strukturiert, fällt bei der nächsten API-Änderung nicht wieder um zwei Wochen Backlog aus. Das klingt nach Software-Engineering – ist aber ein E-Commerce-Thema, weil die Validierungsschicht die letzte Instanz zwischen Warenkorb und Bezahlung ist.
Welche Rolle spielen Marktstandards und der DACH-Raum?
Im DACH-Markt trifft die Änderung auf ein B2B-Ökosystem, in dem Bestellprozesse stärker formalisiert sind als in vielen angloamerikanischen Märkten. Rechnungsstellung mit USt-IdNr., Leitzahl-basierte Kreditorenprozesse, Lieferantenportale wie SAP Ariba oder Onventis – hier läuft B2B-Commerce selten über den klassischen Shop-Checkout des Endverbrauchers. Genau deshalb ist der Nachname als Pflichtfeld an dieser Stelle besonders fehl am Platz.
Bemerkenswert ist der Zeitpunkt. Der B2B-Commerce wächst seit Jahren deutlich schneller als der B2C-Bereich, und ein zunehmender Teil dieses Wachstums läuft nicht über Portale, sondern über direkte Shop- und Checkout-Integrationen. Wenn Payment-Apps in diesem Kanal als Gatekeeper agieren, müssen sie die Spezifikationen der B2B-Realität spiegeln – nicht die des Consumer-Checkouts.
Die API-Änderung ist also mehr als eine Feldanpassung. Sie markiert eine Grenze: B2B-Commerce braucht eigene Validierungslogik. Wer das als Nebensache abtut, lässt Umsatz an einer Code-Zeile liegen, die einen optionalen Nachnamen hart erzwungen hat. Für Payment-App-Anbieter ist die Frage nicht, ob sie diese Änderung nachziehen – sondern wie schnell, und ob sie ihre B2B-Validierung grundsätzlich auf den Prüfstand stellen. Die nächste Spezifikationsänderung kommt bestimmt. Die Frage ist nur, ob sie diesmal jemand in der Release-Planung vorgesehen hat.