Eine Integration wird meist als Entwickleraufgabe geplant und entpuppt sich als
Projekt mit drei Beteiligten. Der Entwickler bindet die API an, die Buchhaltung gleicht das Konto ab. Zudem muss jemand Käufern antworten, deren Zahlung sich seltsam verhalten hat. Teams, die eine Woche einplanen, entdecken die
anderen beiden Rollen in Woche drei.
Die Arbeit selbst ist nicht schwer. Lang wird sie durch die Reihenfolge. Ein paar Entscheidungen gehören vor die erste Codezeile. Ändert man sie später, wird es teuer.
Vier Entscheidungen vor dem Start
Wo die Kartendaten eingegeben werden. Eine vom Anbieter gehostete Seite hält Kartendaten vollständig aus Ihren Systemen heraus. Dadurch sinkt der Compliance-Aufwand auf das Minimum. Ein in den Checkout eingebettetes Formular sieht besser aus und konvertiert etwas höher. Doch nun berühren Kartendaten Ihre Seite, und die Anforderungen ändern sich. Die meisten Shops starten besser gehostet
und wechseln später, wenn Zahlen es rechtfertigen.
Was nach der Zahlung passiert. Der Kunde kehrt auf Ihre Seite
zurück, maßgeblich ist jedoch die Server-zu-Server-Benachrichtigung, nicht die
Weiterleitung. Bauen Sie den Bestellstatus darauf. Shops, die bei Rückkehr des
Browsers auf «bezahlt» setzen, versenden Ware für Zahlungen, die nie ankamen.
Sofort belasten oder erst reservieren. Bei physischer Ware
heißt das üblicherweise: jetzt autorisieren, beim Versand einziehen. Digitale Güter
werden sofort eingezogen. Ein Fehler hier erzeugt verärgerte Kunden, deren Geld für nicht vorrätige Ware abging. Oder umgekehrt: abgelaufene Autorisierungen und verlorene Verkäufe.
Wie Erstattungen laufen. Am zweiten Tag wird jemand eine
Bestellung erstatten müssen. Legen Sie fest, ob das im eigenen Backend oder im Portal des Anbieters geschieht. Klären Sie auch, wer das Recht dazu hat.
Die Reihenfolge, die funktioniert
Stellen Sie den Kontoantrag vor der Entwicklung, denn er dauert ab 5 Tagen und
läuft parallel zum Code. Die Schritte stehen auf
wie es funktioniert.
Während die Unterlagen laufen, lohnt ein Blick auf die Möglichkeiten unter
Zahlungsabwicklung.
Was der Acquirer prüft, steht auf der Seite Händlerkonto. Wer das vor dem Kickoff liest, spart sich später eine Fragerunde.
Während der Antrag läuft, bauen Sie gegen die Testumgebung. Eine Sandbox liefert Kartennummern mit festgelegtem Ausgang: angenommen, abgelehnt, Zeitüberschreitung. Weil jeder dieser Pfade eintreten kann, braucht jeder eine Behandlung. Die Zeitüberschreitung wird übersprungen und verursacht später
Doppelbelastungen im Echtbetrieb.
Testen Sie danach mit kleinen echten Beträgen, bevor Sie live gehen. Denn Sandboxen verhalten sich höflich, echte Banken nicht. Eine echte Transaktion je Zahlart plus
eine Erstattung fangen das meiste, was die Sandbox verbirgt.
Wo Integrationen schiefgehen
Doppelbelastungen bei Wiederholung. Der Kunde tippt zweimal
auf «Bezahlen», oder das Netz bricht ab und die App wiederholt. Ohne
Idempotenzschlüssel werden beide Versuche zu Transaktionen, und Sie erfahren es vom
Käufer. Das ist der häufigste Defekt, den wir sehen.
Bestellstatus läuft dem Zahlungsstatus davon. Die Zahlung
gelingt, die Benachrichtigung geht verloren, die Bestellung bleibt unbezahlt. Bauen
Sie einen täglichen Abgleich statt darauf zu vertrauen, dass jede Nachricht
ankommt.
Währung an der falschen Stelle bestimmt. Zeigt der Shop Euro, geht die Anfrage aber in anderer Währung. Dann sieht der Kunde einen Betrag, dem er nicht zugestimmt hat. Legen Sie die Währung dort fest, wo der Preis angezeigt wird, und geben Sie sie
anschließend ausdrücklich weiter.
Authentifizierung als Fehler behandelt. Die Bestätigung durch
die Bank ist ein normaler Schritt, kein Ausfall. Ein Checkout, der
«Zahlungsfehler» meldet, während die Bank nachfragt, verliert den Verkauf auf dem
letzten Zentimeter.
Was vor dem Start mit dem Support geklärt gehört
Wer Kunden antwortet, braucht am ersten Tag drei Dinge. Erstens eine Suche nach Zahlungen über die Bestellnummer. Zweitens das Recht auf eine Erstattung ohne Eskalation. Drittens eine verständliche Erklärung der häufigsten Fehler. Die meisten Tickets lauten «zweimal belastet» oder «bezahlt, Bestellung trotzdem offen». Deshalb deckt eine vorbereitete Antwort darauf den Großteil des ersten Monats ab.
Was die Finanzseite braucht
Die Integration ist nicht fertig, wenn die Testzahlung durchgeht, sondern wenn
Geld durchgängig nachvollziehbar ist. Die Buchhaltung braucht einen Auszahlungsbericht, der zu den Bestellungen passt. Also muss jede Auszahlung in die enthaltenen Transaktionen aufklappbar sein. Fragen Sie vor dem Bau des Imports, was
der Bericht enthält, denn den Abgleich später umzubauen dauert länger.
Kommt Umsatz in mehreren Währungen herein, klären Sie früh, wo er gesammelt
wird. Ein Geschäfts-IBAN auf Ihren Namen hält die
Kette einfach, weil Abrechnung und ausgehende Zahlungen an einer Stelle
bleiben.
Die Konditionen dazu stehen auf der Seite Preise, wo
die Sätze für Middle-Risk-Handel ab 1,8% beginnen.
Realistische Zeitplanung
Wenn ein gewöhnlicher Shop auf einer verbreiteten Plattform läuft, sind das
wenige Tage Arbeit und eine Woche Tests. Die Kontoprüfung läuft ab 5 Tagen parallel. Der Plan rutscht, wenn Unterlagen unvollständig eintreffen oder die Website dem Antrag widerspricht. Preise weichen vom Checkout ab, Bedingungen fehlen, Kontakte führen ins Leere.
Planen Sie den Start in eine ruhige Woche statt vor einen Verkaufsgipfel. In
den ersten Tagen nach dem Livegang tauchen die Randfälle auf, und dann sollte
Aufmerksamkeit frei sein. Die Kontoseite haben wir im Beitrag über
Händlerkonten
beschrieben.
Anbindung ab 5 Tagen. Gebühren ab 1,8 % — transparente Konditionen, keine
versteckten Kosten. Hinterlassen Sie eine Anfrage oder vereinbaren Sie eine Beratung. Wir finden die passende Lösung für Ihre Nische und Ihr Risikoprofil.