Zahlungen & Acquiring
Bezahlt werden, sauber in Ihr Produkt gebaut — samt der Teile, die erst nach dem Go-live auftauchen.
Von außen wirken Zahlungen wie ein gelöstes Problem. Anbieter-SDK einbinden, Karte annehmen, fertig. Tatsächlich ist der glückliche Pfad vielleicht ein Fünftel der Arbeit, und alles Teure liegt in den anderen vier Fünfteln: ein Kunde, dessen Karte belastet wird, während Ihr Server in einen Timeout läuft; eine Erstattung, die eine teilweise erfüllte Bestellung rückabwickeln muss; ein doppelt zugestellter Webhook; ein Monatsabschluss, bei dem die Summe des Anbieters und Ihre um elf Euro auseinandergehen und niemand weiß, warum.
Ich integriere Zahlungsabwicklung und Acquiring in Produkte, damit Kunden so bezahlen können, wie sie es erwarten — sicher und ohne Überraschungen an der Kasse. Ich habe es in einem Abo-Produkt ausgeliefert, das Pakete und Einzeldokumente verkauft, in einer Streaming-Plattform, die ich von der leeren Seite an entworfen habe und in der jeder Abspielvorgang ein Guthaben belastet, und als Bank-Acquiring in einem bestehenden CRM eines anderen Teams, das für eine registrierte, aber noch nicht abgeschlossene Zahlung schlicht keinen Begriff hatte. Ich habe die interessanten Fehler also debuggt und nicht nur darüber gelesen.
Ich bin Entwickler, keine Zahlungslizenz. Ich binde die Anbieter und Acquirer an, mit denen Sie Verträge haben, und baue die Teile Ihres Systems, die darum herum korrekt sein müssen.
Was Sie bekommen
Checkout, der auf echten Geräten funktioniert
Web- und Mobile-Abläufe an Ihren Anbieter angebunden, inklusive der Zustände, die real auftreten: Ablehnungen, Timeouts, Zurück-Buttons und mitten in der Zahlung abbrechende Verbindungen.
Korrekter Umgang mit Geld
Idempotenz, Wiederholungen, die nicht doppelt belasten können, und ein Transaktionsdatensatz, der die Wahrheit hält. Code, der Geld anfasst, wird defensiv geschrieben — ein Fehler hier hat einen Preis in Währung.
Erstattungen, Teilerstattungen und Stornos
Die Abläufe, die in Version eins übersprungen und später unter Druck gebaut werden, während ein verärgerter Kunde wartet. Besser von Anfang an.
Abstimmung, der Sie trauen können
Ihr Buch gegen die Abrechnung des Anbieters, mit sichtbar gemachten Differenzen — statt einer Entdeckung durch die Buchhaltung im Folgequartal.
Wie es abläuft
- 01
Das Modell festlegen
Einmalzahlung, Abo, Marktplatz oder aufgeteilte Auszahlungen — jedes bedeutet eine andere Architektur und andere rechtliche wie anbieterseitige Randbedingungen. Das später zu ändern ist teuer.
- 02
Sauber gegen die Sandbox integrieren
Jeder Zustand, den der Anbieter zurückgeben kann — auch die, mit denen seine Erfolgspfad-Dokumentation nicht beginnt.
- 03
Die unglücklichen Pfade bauen
Doppelte Webhooks, Timeouts, Teillieferungen, Rückbuchungen. Genau das trennt eine Zahlungsintegration von einer Zahlungsdemo.
- 04
Mit Abstimmung ab Tag eins live gehen
Denn der erste Monat ist genau der, in dem Sie die Zahlen belegen können müssen.
Meist gebaut mit
Wo ich das gemacht habe
E-PL
Ferngesteuerte Untersuchungen vor Fahrtantritt über einen Bluetooth-Alkoholtester, elektronische Fahraufträge mit qualifizierter Signatur — und der Shop samt Versand, der die Hardware zum Fahrer bringt.
Mehr lesen →Benzigo
Die Kundenanwendung samt Kartenzahlung offener Rechnungen — und mehrere autonome Bots, die Tankkarten-Operationen im Portal des Anbieters selbst ausführen.
Mehr lesen →fjalla
Eine Streaming-Plattform, die Künstler pro Abspielvorgang bezahlt — aus dem Nichts entworfen und geschrieben, dann mit einem Team gewachsen.
Mehr lesen →Cinemusic
Eine Plattform für rechtegeklärte Musiklizenzierung für Fernsehen und Postproduktion — meine Seite war die kommerzielle: Zahlungen, Abonnements und der Katalog, in dem gesucht wird.
Mehr lesen →Häufige Fragen
Mit welchen Zahlungsanbietern arbeiten Sie?
Mit denen, mit denen Sie Verträge schließen. Die Anbieterwahl folgt Ihrem Markt, Ihrem Geschäftsmodell und den ausgehandelten Konditionen — nicht dem SDK, das ein Entwickler bevorzugt. Die Integrationsarbeit ähnelt sich weitgehend, und ich weise früh darauf hin, wenn ein erwogener Anbieter schlecht zu Ihrer Verkaufsweise passt.
Übernehmen Sie die PCI-Konformität?
Der übliche Weg ist, Kartendaten nie Ihre Server berühren zu lassen — gehostete Felder oder der Checkout des Anbieters — was Sie in der leichtesten Konformitätsstufe hält. So baue ich es standardmäßig. Die formale Zertifizierung liegt zwischen Ihnen, Ihrem Anbieter und, in höheren Stufen, einem Prüfer; ich sorge dafür, dass die Architektur das nicht schwerer macht als nötig.
Können Sie Zahlungen in ein bestehendes Produkt einbauen?
Ja, das ist der Normalfall. Die entscheidende Frage ist, ob Ihr bestehendes Bestell- und Zustandsmodell teilbezahlt, erstattet und strittig ausdrücken kann — oder ob es annimmt, jede Bestellung sei schlicht „bezahlt“. Ist Letzteres der Fall, ist genau das die eigentliche Arbeit, und ich finde es lieber vorher heraus als hinterher.
Was ist mit Abos und wiederkehrender Abrechnung?
Machbar, und es verdient ein eigenes Projekt statt eines Häkchens. Mahnläufe, fehlgeschlagene Verlängerungen, Tarifwechsel mitten im Zyklus und anteilige Abrechnung sind die Stellen, an denen Abo-Systeme wirklich kompliziert werden — und nichts davon ist in einer ersten Demo sichtbar.
Ein ähnliches Projekt?
Beschreiben Sie mir, was das System leisten und mit welchen Systemen es sprechen muss. Sie bekommen eine klare Einschätzung zu Umfang, Reihenfolge und dem, was ich zuerst bauen würde — noch bevor Sie sich festlegen.
Gespräch beginnen