Zahlungsarten für DACH in Solidus: Kauf auf Rechnung, SEPA, Klarna, EPS und Twint

Der Checkout der mit einem Drittel der Rate konvertiert hat

Ich habe einmal zugesehen wie eine britische Marke in Deutschland mit einem Checkout gestartet ist der Visa, Mastercard und Apple Pay angeboten hat. Schöner Checkout. Schnell, sauber, mobil optimiert, so etwas das man in einem Portfolio zeigt. Er hat mit knapp einem Drittel der Rate konvertiert die derselbe Shop zu Hause geschafft hat.

Niemand konnte sich erklären warum, bis endlich jemand eine deutsche Kundin gefragt hat, die mit dem leicht verwunderten Ton einer Person die erklärt dass Wasser nass ist gesagt hat, dass sie ihre Kartendaten keinem Shop gibt bei dem sie noch nie gekauft hat. Sie wollte per Rechnung zahlen nachdem das Paket da ist, oder zumindest mit PayPal. Der Shop hat beides nicht angeboten. Also ist sie gegangen.

In einem früheren Artikel habe ich darüber geschrieben warum deutsche Käufer Abos meiden und Kauf auf Rechnung erwarten. Das war das Warum. Das hier ist das Wie. Wenn du einen Solidus Shop betreibst oder baust der nach Deutschland, Österreich oder in die Schweiz verkauft, dann steht hier was dein Checkout anbieten muss, wem, und wie jede dieser Zahlungsarten tatsächlich angebunden wird, inklusive der Teile die deinen Bestellablauf kaputt machen wenn du sie nicht einplanst.

Ich baue auf Solidus, die Umsetzungsnotizen sind also Solidus spezifisch. Die Marktfakten gelten egal was du betreibst.

Drei Länder, drei verschiedene Geldbörsen

Leute werfen DACH gerne in einen Topf als wäre es ein Markt mit einer Sprache. Bei Zahlungen sind es drei Märkte die zufällig eine Sprache teilen und sich über fast alles andere uneinig sind.

Deutschland. Der größte, der konservativste und der rechnungsverliebteste der drei. Wenn du die verschiedenen Umfragen der Handelsverbände mittelst, ist PayPal die meistgenutzte einzelne Methode mit irgendwo zwischen einem Viertel und einem Drittel der Onlinekäufe. Kauf auf Rechnung, also Zahlung nach Lieferung, liegt knapp dahinter bei rund einem Viertel. Dann SEPA Lastschrift, dann Karten, was in Deutschland viele Girocard Besitzer bedeutet die überhaupt keine Kreditkarte haben, dann Klarnas Raten und Später zahlen Produkte, dann ein langer Schwanz aus Apple Pay, Google Pay und Amazon Pay. Sofort, die Überweisungsmethode die halb Deutschland jahrelang genutzt hat, wurde in Klarna aufgesogen und ist jetzt nur noch eine Option in deren Widget. Giropay, die Antwort der Banken auf PayPal, wurde Ende 2024 nach einem Jahrzehnt ohne echten Durchbruch abgeschaltet.

Das Wichtige an dieser Liste ist was nicht oben steht. Karten sind Vierter. Ein Checkout der mit Karten anfängt, fängt mit der Methode an der ein deutscher Kunde am wenigsten traut.

Österreich. Kleiner, kartenfreundlicher als Deutschland, aber immer noch nicht Karte zuerst. Die österreichische Besonderheit ist EPS, das Überweisungsverfahren das die meisten österreichischen Onlinebanken nativ unterstützen, und es hat einen spürbaren Anteil, irgendwo um ein Fünftel der Käufe, je nachdem wessen Zahlen du liest. PayPal ist stark. Karten sind stärker als in Deutschland. Rechnung wird erwartet, ist aber etwas weniger heilig. Klarna wächst. Wenn du für Österreich nur eine Sache hinzufügst die du für Deutschland nicht hattest, dann EPS.

Die Schweiz. Ein anderes Land in jeder Hinsicht die hier zählt. Die Währung ist der Franken, nicht der Euro, und ein Schweizer Kunde dem ein Europreis gezeigt wird geht davon aus dass du nicht wirklich in die Schweiz verkaufst. Die dominierende Methode ist Twint, die App die die Schweizer Banken gemeinsam gebaut haben, die in etwa fünf Jahren von einer Kuriosität zum Standard geworden ist und in den meisten Umfragen inzwischen Karten bei inländischen Onlinekäufen schlägt. Karten kommen an zweiter Stelle, PayPal ist vorhanden aber schwächer als in Deutschland, Rechnung wird ab einem mittleren Warenkorb erwartet, und PostFinance zählt für eine bestimmte Art von Kunde immer noch. Die Schweiz ist außerdem nicht in der EU, was Zoll bedeutet, eine eigene Umsatzsteuerregistrierung sobald du die Schwelle überschreitest, und kein OSS. Die Logistikseite behandle ich in meinem Artikel zu Versand und Retouren, aber die Konsequenz für die Zahlung ist einfach: CHF Preise, Twint und eine Rechnungsoption, oder lass es bleiben.

Was der Checkout zeigen sollte, und wem

Der häufigste Fehler den ich sehe ist ein Checkout der jedem Kunden jede Zahlungsart zeigt. Es fühlt sich großzügig an. Es ist in Wirklichkeit ein Conversion Problem und ein Betrugsproblem zugleich.

Ein deutscher Kunde der an Twint und EPS vorbeiscrollt um Rechnung zu finden ist ein Kunde der sich fragt ob dieser Shop wirklich nach Deutschland verkauft. Ein Schweizer Kunde dem SEPA Lastschrift angeboten wird, die ein Eurokonto braucht, ist ein Kunde dem etwas angeboten wird das scheitern wird. Und ein Betrüger liebt nichts mehr als einen Shop der Kauf auf Rechnung an eine Adresse in einem Land anbietet in dem der Shop kein Inkasso hat.

In Solidus ist jede Zahlungsart an eine Zone gebunden, und eine Zone ist eine Menge von Ländern oder Bundesländern. Das ist der Mechanismus. Nutz ihn richtig und der Checkout zeigt immer nur die Methoden die zur gerade eingegebenen Rechnungsadresse passen. Mein Standardaufbau für einen DACH Shop sieht ungefähr so aus:

Zone Deutschland. PayPal, Kauf auf Rechnung, SEPA Lastschrift, Karten, Klarna. In dieser Reihenfolge auf der Seite.

Zone Österreich. EPS, PayPal, Karten, Kauf auf Rechnung, Klarna.

Zone Schweiz. Twint, Karten, Kauf auf Rechnung, PayPal. Preise in CHF aus der Schweizer Preisliste des Shops, nie im Checkout umgerechnet.

Zone restliche EU. Karten, PayPal, und was auch immer der lokale Favorit ist wenn du dir die Mühe gemacht hast ihn hinzuzufügen, iDEAL für die Niederlande, Bancontact für Belgien und so weiter.

Zone UK und Rest der Welt. Karten, PayPal, Apple Pay, Google Pay.

Die Reihenfolge ist keine Dekoration. Die meisten Kunden wählen die erste Methode die sie erkennen. Setz die vertraute lokale Methode nach oben und der Checkout wird schneller. Setz Karten in Deutschland nach oben und du hast den Shop gebaut den ich im ersten Absatz beschrieben habe.

Solidus lässt dich weiter gehen als Zonen wenn du willst. Du kannst eine Methode unter oder über einem Warenkorbwert ausblenden, Rechnung für Kunden mit offener Bestellung ausblenden, Raten nur ab einer Schwelle zeigen, oder einem B2B Kunden einen komplett anderen Satz anzeigen. All das sind ein paar Zeilen in der Verfügbarkeitsprüfung der Zahlungsart. Der Punkt ist dass das Framework "welche Methoden sieht dieser Kunde" als deine Entscheidung behandelt, nicht als die der Plattform, und du solltest sie bewusst treffen.

Karten, SEPA und Wallets: Stripe als Schiene

Für Karten, SEPA Lastschrift, Apple Pay, Google Pay und eine Handvoll lokaler Methoden nutze ich Stripe über die offizielle Solidus Stripe Erweiterung, und ich bräuchte einen guten Grund etwas anderes zu nehmen. Die Erweiterung kümmert sich um das Payment Element, das die richtigen Methoden für das Land des Kunden rendert, um die starke Kundenauthentifizierung, um das Speichern von Zahlungsquellen am Kunden für Wiederholungskäufe, und sie bildet Stripes Payment Intents sauber auf Solidus Zahlungen ab. Sie wird von denselben Leuten gepflegt die Solidus selbst pflegen, was mehr zählt als jedes Feature.

Ein paar Dinge die du dazu im DACH Kontext wissen solltest.

SEPA Lastschrift ist langsam und widerrufbar. Eine Kartenzahlung ist in Sekunden autorisiert und in Tagen abgerechnet. Eine SEPA Lastschrift wird eingereicht, braucht dann mehrere Bankarbeitstage um zu scheitern oder durchzugehen, und der Kunde kann sie acht Wochen lang ohne Angabe von Gründen zurückholen. Stripe bildet das korrekt ab: die Zahlung sitzt in einem Verarbeitungsstatus und du bekommst einen Webhook wenn sie abgerechnet ist. Deine Solidus Bestellung muss das respektieren. Versende nicht auf eine SEPA Lastschrift die noch nicht abgerechnet ist, außer du hast bewusst entschieden dass du Kredit gibst. Bei günstigen Waren ist das normalerweise in Ordnung. Bei einem Artikel für zweitausend Euro ist es eine Entscheidung.

Girocard ist keine Kreditkarte. Viele deutsche Kunden haben eine Girocard, das inländische Debitverfahren, und keine Visa oder Mastercard. Historisch konnte die Girocard online gar nicht genutzt werden. Das hat sich langsam geändert, und Stripe unterstützt die Co Badge Varianten, aber geh nicht davon aus dass "wir akzeptieren Karten" dasselbe bedeutet wie in Großbritannien.

Wallets brauchen eine verifizierte Domain. Apple Pay und Google Pay erscheinen im Payment Element erst wenn deine Domain bei Stripe registriert ist und die Verifizierungsdatei ausgeliefert wird. Ich habe Shops gesehen die wochenlang live waren und bei denen die Wallets still gefehlt haben. Setz es auf die Launch Checkliste.

SCA ist nicht optional. Unter PSD2 geht jede Kartenzahlung in der EU durch die starke Kundenauthentifizierung, außer sie fällt unter eine Ausnahme. Stripe übernimmt den Challenge Ablauf, aber dein Checkout muss rausleiten und zurückkommen können ohne die Bestellung zu verlieren. Die Solidus Stripe Erweiterung kann das. Eine selbstgebaute Integration meistens nicht, und der Fehlerfall ist eine Bestellung die in einem halb bezahlten Zustand hängt und die niemand bemerkt bis der Kunde sich beschwert.

Kauf auf Rechnung: die die du nicht überspringen kannst

Jetzt die Methode die entscheidet ob du in Deutschland überhaupt verkaufst.

Kauf auf Rechnung heißt der Kunde bestellt, du versendest, das Paket kommt mit einer Rechnung, und der Kunde zahlt innerhalb von vierzehn Tagen per Überweisung. Aus Sicht des Kunden ist das perfekt: keine Kartendaten, kein Vertrauensvorschuss, erst die Ware anschauen. Aus Sicht des Shops hast du gerade Ware an einen Fremden verschickt auf das Versprechen einer Überweisung hin.

Es gibt zwei Arten das zu betreiben und du musst dich entscheiden bevor du den Code anfasst.

Selbst betreiben. Du trägst das Risiko, du stellst die Rechnung, du treibst das Geld ein. So haben deutsche Shops das jahrzehntelang gemacht und manche tun es noch, meist mit einer Bonitätsprüfung bei der Schufa oder einer ähnlichen Auskunftei im Checkout und harten Grenzen für Warenkorbgröße und Lieferadresse. Es kostet nichts an Gebühren und alles an Betrieb. Jemand muss jeden Tag das Bankkonto mit den offenen Bestellungen abgleichen. Jemand muss die erste Erinnerung schicken, die zweite Erinnerung, die Mahnung mit Mahngebühr, und die Akte an ein Inkassounternehmen geben. Bei tausend Bestellungen im Monat sind ein paar Prozent davon verspätet und ein Bruchteil eines Prozents zahlt nie. Dieser Bruchteil ist deine Marge bei Rechnungsbestellungen und du musst ihn kennen.

Einem Spezialisten übergeben. Klarna, Unzer, Mollie, PayPals eigenes Später zahlen Produkt und ein paar andere nehmen dir das Risiko ab. Der Kunde sieht "Rechnung" in deinem Checkout, der Anbieter führt im Hintergrund die Bonitätsprüfung durch, genehmigt oder lehnt ab in unter einer Sekunde, und du bekommst dein Geld vom Anbieter, egal ob der Kunde ihn bezahlt oder nicht. Die Gebühren sind höher als bei Karten, typischerweise zwei bis drei Prozent plus ein fester Betrag pro Transaktion, und der Anbieter besitzt die Kundenbeziehung für die Zahlung. Dafür jagst du nie jemandem hinterher und dein Cashflow sieht aus wie Karten Cashflow.

Für fast jedes KMU mit dem ich arbeite ist der Weg über den Spezialisten richtig. Die Ausnahme ist B2B, wo du deine Kunden kennst, die Warenkörbe groß sind, und die Risikoprüfung eines Anbieters genau die Bestellungen ablehnt die du am liebsten hättest. Im B2B betreibst du Rechnung selbst, auf Ziel, mit deinen eigenen Kreditlimits, und das ist ein Thema für einen eigenen Artikel.

In Solidus ist der Spezialistenweg eine Zahlungsart die während des Checkouts mit der API des Anbieters spricht, ein Genehmigungstoken bekommt, und eine Zahlung anlegt die abgeschlossen wird wenn du sie einziehst, meist beim Versand. Der selbst betriebene Weg ist eine Zahlungsart ganz ohne Gateway, was Solidus von Haus aus als Methode im Stil von "Scheck" unterstützt, plus deine eigene Logik obendrauf: der Aufruf der Bonitätsprüfung, die Limits, die Rechnungserstellung und der Mahnplan.

Was Kauf auf Rechnung mit deinem Bestellablauf macht

Das ist der Abschnitt den Leute überspringen und wegen dem sie mich dann anrufen.

Solidus Bestellungen durchlaufen einen Zustandsautomaten: Warenkorb, Adresse, Lieferung, Zahlung, Bestätigung, abgeschlossen. Zahlungen haben ihre eigenen Zustände: Checkout, ausstehend, in Verarbeitung, abgeschlossen, fehlgeschlagen, storniert, ungültig. Sendungen haben ihre eigenen: ausstehend, bereit, versendet. Das Standardverhalten ist für Karten sinnvoll: eine Bestellung wird abgeschlossen wenn die Zahlung autorisiert ist, die Sendung wird bereit wenn die Zahlung eingezogen ist, du versendest, fertig.

Rechnung bricht das auf eine bestimmte Art. Die Bestellung ist abgeschlossen und die Sendung muss versandbereit sein während die Zahlung nicht nur nicht eingezogen, sondern noch nicht einmal versucht wurde. Du versendest absichtlich eine unbezahlte Bestellung.

So handhabe ich das:

Der automatische Einzug der Zahlungsart ist aus und ihre Zahlung geht im Checkout direkt auf ausstehend. Noch ist nichts fällig.

Sendungen dürfen bereit werden wenn die Bestellung eine ausstehende Zahlung einer Rechnungsmethode hat. In Solidus ist das ein kleines Überschreiben der Versandbereitschaftsprüfung, und es ist die wichtigste einzelne Codezeile der ganzen Integration. Machst du es in die eine Richtung falsch, werden Rechnungsbestellungen nie versendet. Machst du es in die andere Richtung falsch, werden unbezahlte Kartenbestellungen versendet.

Der Einzug passiert beim Versand. Wenn das Lager die Sendung als versendet markiert, wird die Rechnungszahlung eingezogen, was bei einem Spezialisten "wir haben versendet, Uhr starten, zahlt uns" bedeutet, und bei einer selbst betriebenen Rechnung "Rechnungsdokument mit heutigem Datum erzeugen, an die Bestellung hängen, per Mail schicken und ein Fälligkeitsdatum setzen".

Der Zahlungseingang ist ein eigenes Ereignis. Beim Spezialisten ist die Zahlung abgeschlossen sobald der Anbieter bestätigt dass er dich bezahlt, meist beim Einzug. Bei der selbst betriebenen Rechnung bleibt die Zahlung in einem eingezogen aber nicht beglichen Zustand bis eine Überweisung ankommt und jemand, oder etwas, sie der Bestellung zuordnet. Ich modelliere das als eigenen Zahlungszustand und einen täglichen Abgleichjob der den Bankfeed liest und über die auf der Rechnung gedruckte Referenznummer zuordnet.

Mahnwesen ist ein geplanter Job, keine Person. Tag fünfzehn, freundliche Erinnerung. Tag zweiundzwanzig, zweite Erinnerung. Tag dreißig, förmliche Mahnung mit gesetzlicher Mahngebühr und Zinsen. Tag fünfundvierzig, Übergabe ans Inkasso und das Kundenkonto markiert, damit der Kunde Rechnung nie wieder als Option sieht. Jeder Schritt wird an der Bestellung protokolliert. Das ist ein Background Worker mit Zeitplan, in den Tests mit Zeitreise geprüft, und er läuft egal ob die Person die das früher gemacht hat im Urlaub ist.

Retouren bei Rechnungsbestellungen reduzieren die Rechnung, sie erstatten nicht. Wenn der Kunde die halbe Bestellung zurückschickt bevor er bezahlt hat, stellst du eine Gutschrift gegen die Rechnung aus und der fällige Betrag sinkt. Hat er schon bezahlt, erstattest du per Überweisung, was bedeutet du brauchst seine IBAN, was bedeutet dein Retourenablauf muss danach fragen. Kartenerstattungen gehen automatisch auf die Karte zurück. Rechnungserstattungen gehen nirgendwohin automatisch. Bau die IBAN Abfrage ins Retourenformular ein oder du wirst für den Rest deines Lebens Kunden nach Bankdaten fragen.

Klarna, Unzer, Mollie: den Spezialisten wählen

Drei Anbieter decken das meiste ab wonach ich gefragt werde.

Klarna ist die Verbrauchermarke. Deutsche Kunden kennen das rosa Logo, das Widget bündelt Rechnung, Raten und Sofortzahlung an einer Stelle, und die Genehmigungsquoten für Verbraucher sind hoch. Der Preis ist dass Klarna deine Kunden über die eigene App bewirbt, die Gebühren am oberen Ende liegen, und die Integration Klarnas Checkout in deinem Checkout ist, der sich mit deinem Design beißt. Solidus spricht über die Payments API mit Klarna statt über den eingebetteten Checkout, was deinen Ablauf deinen bleiben lässt.

Unzer, früher Heidelpay, ist der deutsche Spezialist nach dem Agenturen greifen. Rechnung, Raten, Lastschrift, Karten, alles unter einem Vertrag, mit einer für DACH abgestimmten Risikoprüfung und einem ordentlichen B2B Rechnungsprodukt. Weniger Markenbekanntheit beim Verbraucher als Klarna, mehr Flexibilität, und Support der auf Deutsch antwortet. Mein Standard für einen Shop der es mit DACH ernst meint und einen Anbieter für alles außer Karten will.

Mollie ist der niederländische Aggregator der still zum einfachsten Weg geworden ist jede europäische lokale Methode hinzuzufügen. iDEAL, Bancontact, EPS, Twint, SEPA, Karten, PayPal, Klarna über Mollie, alles über eine API und eine Abrechnung. Für einen Shop der EU weit und in die Schweiz verkauft mit überschaubarem Volumen decken Mollie plus Stripe alles ab. Für einen Shop der vom deutschen Rechnungsvolumen lebt wird ein Spezialist mit eigener Risikoprüfung mehr Bestellungen genehmigen.

Egal wen du wählst, lies den Vertrag auf die zwei Dinge die zählen: die Genehmigungsquote zu der sie sich verpflichten, und was mit einer strittigen Bestellung passiert. Dann bau es über eine einzelne Solidus Zahlungsartklasse pro Anbieter ein, mit dem SDK des Anbieters hinter einem Adapter, damit ein späterer Wechsel eine Konfigurationsänderung ist und kein Neubau. Ich habe eine warnende Geschichte darüber geschrieben was passiert wenn man Payment Gateways unbedacht wechselt und mir wäre lieber du liest sie bevor du sie brauchst.

EPS für Österreich, Twint für die Schweiz

Beide sind bankgetrieben, beide sind Redirect Methoden, beide werden in Solidus gleich behandelt.

Der Kunde wählt die Methode, wird zu seiner Bank oder in die Twint App weitergeleitet, genehmigt die Zahlung dort und wird mit Erfolg oder Misserfolg auf deine Seite zurückgeschickt. Stripe unterstützt EPS direkt. Twint gibt es über Stripe in manchen Konfigurationen und zuverlässiger über Mollie, Datatrans, Adyen und die Schweizer Acquirer. Für einen Shop der es mit der Schweiz ernst meint nutze ich einen Schweizer Acquirer für Twint und Karten in CHF, weil die Abrechnung in Franken auf ein Schweizer Konto eine Umrechnungsgebühr bei jeder Bestellung vermeidet und Schweizer Kunden einen ausländischen Händlernamen auf ihrem Kontoauszug bemerken.

Die Solidus Seite ist eine Zahlungsart die die Zahlung im Verarbeitungszustand anlegt, die Redirect Referenz speichert, den Kunden wegschickt, und die Zahlung beim Rückkehr Webhook abschließt oder scheitern lässt. Die Bestellung sollte nicht abgeschlossen werden bevor der Webhook ankommt. Erstaunlich viele Integrationen schließen die Bestellung beim Redirect zurück ab, was bedeutet dass ein Kunde der den Bank Tab schließt und deine Seite neu öffnet eine Bestellbestätigung für eine Zahlung bekommt die nie stattgefunden hat. Der Webhook ist die Wahrheit. Der Redirect ist ein Hinweis.

Noch ein Schweizer Detail: Rundung. Schweizer Barpreise runden auf fünf Rappen und viele Schweizer Shops runden elektronische Preise aus Gewohnheit genauso. Deine CHF Preisliste sollte Preise tragen die bereits schweizerisch aussehen, also 49.95 oder 50.00, nicht 49.37 aus einer Umrechnung. In Solidus ist das einfach ein eigener Preis pro Variante in der CHF Preisliste, was ohnehin so sein sollte.

Betrug und Risiko, pro Methode

Jede Methode hat ihre eigene Art zu scheitern und deine Risikoregeln sollten dazu passen.

Karten. Gestohlene Kartennummern. Stripe Radar fängt das meiste, SCA fängt mehr, und der Rest sind Chargebacks die du verlierst. Regeln die helfen: abweichende Rechnungs und Lieferländer über einer Schwelle blockieren, SCA beim ersten Kauf verlangen, Bestellungen markieren bei denen die Maildomain letzte Woche registriert wurde.

PayPal. Kontoübernahmen und "Ware nicht erhalten" Streitfälle. Versende mit Tracking nur an die PayPal Adresse, und behalte die Trackingnummer an der Bestellung damit du den Streitfall gewinnst.

SEPA Lastschrift. Der acht Wochen Widerruf. Beschränke Lastschrift auf wiederkehrende Kunden, oder auf Warenkörbe unter einem Wert den du verlieren kannst, oder akzeptiere das Risiko bewusst.

Rechnung. Die große. Jemand bestellt an eine Packstation oder einen Spediteur unter einem Namen der zu keiner echten Person passt, und zahlt nie. Wenn ein Spezialist das Risiko trägt, kümmert sich dessen Prüfung darum und du akzeptierst seine Ablehnungen. Trägst du es selbst, brauchst du Adressprüfung, eine Bonitätsprüfung, ein Verbot von Packstationen und Spediteuren für Rechnungsbestellungen, ein Warenkorblimit für Neukunden, und eine Frequenzprüfung die merkt wenn dieselbe Adresse fünfmal an einem Tag bestellt. All das ist ein Satz Regeln in der Verfügbarkeitsprüfung der Zahlungsart plus ein Vorabprüfungsaufruf, und all das sollte protokolliert werden damit du sehen kannst warum eine Bestellung abgelehnt wurde wenn der Kunde anruft.

Twint und EPS. Sehr wenig Betrug, weil der Kunde sich bei seiner Bank authentifiziert hat. Das Risiko ist operativ: ein Webhook der nie ankommt. Überwache Zahlungen die länger als eine Stunde in Verarbeitung hängen.

Erstattungen, Teilerstattungen und die Retouren die du nicht eingeplant hast

Erstattungen sind die Stelle an der ich die meisten Fehler in Zahlungsintegrationen finde, weil niemand sie testet bis ein Kunde eine will.

Solidus hat ein ordentliches Erstattungsmodell: eine Erstattung gehört zu einer Zahlung, hat einen Betrag und einen Grund, und ruft das Gateway auf um das Geld tatsächlich zu bewegen. Die Stripe Erweiterung macht das korrekt, inklusive Teilerstattungen und Erstattungen einer Zahlung die in mehreren Teilen eingezogen wurde. Die Spezialanbieter unterscheiden sich. Manche unterstützen Teilerstattungen über ihre API, manche brauchen eine Gutschrift, manche brauchen einen Anruf. Find es vor dem Launch heraus.

Die DACH spezifische Falte ist dass Retouren häufig sind und Teilretouren sehr häufig. Eine deutsche Kundin bestellt drei Größen, behält eine, schickt zwei zurück, und erwartet die Erstattung innerhalb von Tagen. Auf einer Karte ist das eine Teilerstattung gegen die ursprüngliche Zahlung. Bei PayPal dasselbe. Bei Rechnung ist es eine Gutschrift die den offenen Betrag reduziert wenn unbezahlt, oder eine Überweisungserstattung wenn bezahlt. Bei SEPA eine Erstattung einer Lastschrift die vielleicht noch nicht abgerechnet ist, was manche Anbieter erst danach können. Bei Twint eine Erstattung in die App. Jeder dieser Fälle ist ein anderer Codepfad und jeder braucht einen Test.

Ich baue den Retourenablauf so dass die Erstattungsmethode von der Zahlungsart bestimmt wird, nicht von der Person die die Retoure bearbeitet. Das Lager markiert Artikel als erhalten, das System rechnet aus was geschuldet wird, und die richtige Erstattung passiert auf der richtigen Schiene. Der einzige manuelle Schritt ist das Eintragen einer IBAN wenn die ursprüngliche Zahlung keine Erstattung empfangen kann, und selbst die wird beim Kunden in der Retourenanfrage abgefragt.

Abgleich, oder wie dein Steuerberater dich mögen lernt

Ein Shop mit fünf Zahlungsarten hat fünf Auszahlungsströme die in fünf verschiedenen Rhythmen mit fünf verschiedenen Gebührenstrukturen auf dem Bankkonto ankommen, und einen Steuerberater der jede Zeile einer Rechnung zuordnen muss.

Stripe zahlt täglich oder wöchentlich als Sammelbetrag aus, mit einem Bericht der jede Zahlung und Gebühr dahinter auflistet. PayPal hält ein Guthaben das du manuell oder nach Zeitplan abrufst. Klarna und Unzer rechnen in ihrem eigenen Zyklus ab, netto nach Gebühren, mit einer Abrechnungsdatei. Ein Schweizer Acquirer rechnet in CHF auf ein Schweizer Konto ab. Selbst betriebene Rechnungszahlungen kommen eine Überweisung nach der anderen mit dem Verwendungszweck den der Kunde eingetippt hat.

Was der Steuerberater von deinem Solidus Shop braucht ist ein Export pro Periode, der jede Bestellung, die Zahlungsart, den Bruttobetrag, die Gebühr, den Nettobetrag und den Abrechnungslauf in dem sie gelandet ist auflistet. In Solidus ist das eine Berichtsabfrage über Zahlungen und ihre Gateway Antworten, plus eine gespeicherte Abrechnungsreferenz pro Zahlung die du aus den Webhooks oder Abrechnungsdateien des Anbieters befüllst. Das ist nicht glamourös. Es ist aber der Unterschied zwischen einem Monatsabschluss der einen Nachmittag dauert und einem der eine Woche dauert.

Bei der selbst betriebenen Rechnung läuft der Abgleich umgekehrt: eingehende Überweisungen den offenen Rechnungen zuordnen. Ich mache das mit einem täglichen Import des Bankfeeds, einer Zuordnung über die Rechnungsnummer im Verwendungszweck, einer unscharfen Zuordnung über Betrag und Kundenname für die Fälle in denen der Kunde etwas Kreatives getippt hat, und einer Warteschlange nicht zugeordneter Überweisungen für einen Menschen. Diese Warteschlange sind bei einem Shop mit tausend Bestellungen im Monat normalerweise eine Handvoll pro Woche, und sie ist die einzige manuelle Arbeit im ganzen Ablauf.

Gespeicherte Zahlungsquellen und der wiederkehrende Kunde

Ein wiederkehrender Kunde sollte nichts eintippen müssen. Stripe speichert die Zahlungsquelle am Solidus Nutzer, mit Einwilligung des Kunden, und der Checkout bietet sie bei der nächsten Bestellung standardmäßig an. SEPA Mandate funktionieren genauso sobald die erste Lastschrift durchgegangen ist. PayPal hat ein Produkt für Referenztransaktionen mit dem sich die meisten Shops nicht befassen. Rechnung muss nicht gespeichert werden, aber deine Risikoregeln sollten freundlicher werden bei einem Kunden mit drei bezahlten Rechnungen hinter sich, und das ist eine Abfrage seiner Bestellhistorie zum Zeitpunkt des Checkouts.

Die Einwilligung zählt. Unter der DSGVO braucht das Speichern einer Zahlungsquelle für zukünftige Nutzung ein klares Opt in, kein vorangekreuztes Kästchen, und der Kunde muss sie auf seiner Kontoseite löschen können. Bau beides.

Was der falsche Mix wirklich kostet

Lass mich Zahlen auf die Geschichte vom Anfang legen, denn "Conversion Problem" ist vage und vage bekommt kein Budget genehmigt.

Nimm einen Shop der zehntausend Besucher im Monat aus Deutschland in den Checkout schickt, mit einem Warenkorb von achtzig Euro. Ein Checkout der nur Karten und PayPal anbietet, keine Rechnung, keine Lastschrift, konvertiert nach meiner Erfahrung bei rund zwei Prozent, das sind zweihundert Bestellungen und sechzehntausend Euro. Derselbe Shop mit PayPal, Rechnung, SEPA, Karten und Klarna, in dieser Reihenfolge, konvertiert eher bei dreieinhalb Prozent. Das sind dreihundertfünfzig Bestellungen und achtundzwanzigtausend Euro. Hundertfünfzig Bestellungen im Monat, zwölftausend Euro Umsatz, aus demselben Traffic, weil der Checkout aufgehört hat Deutsche um etwas zu bitten das sie nicht tun.

Die Rechnungsbestellungen in diesem Mix kosten dich zwei bis drei Prozent mehr an Gebühren als Kartenbestellungen gekostet hätten. Auf zwölftausend Euro zusätzlichen Umsatz sind das ein paar hundert Euro. Niemand verhandelt eine Anbietergebühr hart genug um einen Checkout auszugleichen der ein Drittel der Kunden abweist die ihn erreicht haben.

Dieselbe Rechnung gilt umgekehrt für die Schweiz mit Twint und für Österreich mit EPS. Die Zahlen sind kleiner weil die Märkte kleiner sind. Das Verhältnis nicht.

Die Launch Checkliste

Wenn du sonst nichts aus diesem Artikel mitnimmst, nimm diese Liste. Jeder Punkt ist etwas das ich bei einem Shop fehlen gesehen habe der schon live war.

Zahlungsarten an Zonen gebunden, damit jeder Kunde nur sieht was zu seiner Adresse passt.
Lokale Methode zuerst in jeder Zone: PayPal oder Rechnung für Deutschland, EPS für Österreich, Twint für die Schweiz.
CHF Preisliste für die Schweiz mit schweizerisch aussehenden Preisen, keine Umrechnungen.
Rechnungsmethode mit Versand bei ausstehender Zahlung, Einzug beim Versand, ein Mahnplan der von selbst läuft, und eine IBAN Abfrage im Retourenablauf.
Stripe Domain verifiziert damit Apple Pay und Google Pay tatsächlich erscheinen.
SCA Redirect und Rückkehr mit einer echten Karte im Testmodus geprüft.
Jede Redirect Methode schließt die Bestellung beim Webhook ab, nie beim Redirect.
Teilerstattung bei jeder Methode getestet, inklusive SEPA vor der Abrechnung.
Abrechnungsreferenz pro Zahlung gespeichert und ein Abgleichexport den dein Steuerberater abgenommen hat.
Betrugsregeln pro Methode, protokolliert, mit einer Möglichkeit zu sehen warum eine Bestellung abgelehnt wurde.
Speichern von Zahlungsquellen hinter einem echten Opt in, löschbar von der Kontoseite.
Ein Monitor für Zahlungen die länger als eine Stunde in Verarbeitung hängen.

Wo das hingehört

Zahlungen sind ein Teil der DACH Geschichte, und wohl der mit dem schnellsten Ertrag. Mach den Mix richtig und der Checkout konvertiert. Mach den Ablauf richtig und die Rechnungsbestellungen werden versendet, bezahlt und abgeglichen ohne dass ein Mensch eingreift. Mach die Betrugsregeln richtig und die Rechnungsbestellungen die versendet werden sind die die bezahlt werden.

Wenn du gerade eine Plattform wählst und dich fragst ob dir dieses Maß an Kontrolle überhaupt zur Verfügung steht, habe ich die Optionen in Solidus versus Shopify, Shopware, Magento und WooCommerce für ein KMU in der DACH Region verglichen. Die Kurzfassung: alles in diesem Artikel sind ein paar gut getestete Ruby Klassen auf Solidus, ein Plugin und ein Angebot auf Shopware, und eine App plus Strafgebühr auf Shopify. Welches du willst hängt davon ab wie viel von deinem deutschen Umsatz du behalten möchtest.