Sehen Sie jemandem zu, der auf dem Handy mit Karte bezahlt. Er sucht das Portemonnaie, liest sechzehn Ziffern ab, vertippt sich bei einer, versucht es nochmal, sucht den CVV — und scheitert dann an der Authentifizierung, weil die SMS auf das Telefon ging, das er gerade benutzt.
Jetzt derselbe Kauf mit einem Wallet. Doppelklick, Daumen, fertig.
Dieser Unterschied ist der Grund, warum Payment-Integration ein Conversion-Projekt ist — kein Rohrleitungsbau.
Die erste Entscheidung ist nicht technisch
Bevor irgendeine Integrationsarbeit beginnt, klären Sie, was Sie verkaufen — denn für iOS- und Android-Apps entscheidet das, ob Sie überhaupt eine Wahl haben.
Digitale Güter, die in der App konsumiert werden — Abos, Premium-Features, Spielwährung — müssen in aller Regel über das In-App-Kaufsystem der Plattform laufen, zu Plattform-Kommissionssätzen. Es gab regulatorische Bewegung, und einige Jurisdiktionen erlauben inzwischen Alternativen — aber der Standard bleibt Plattform-Billing, und die Regeln unterscheiden sich je Markt.
Physische Güter und reale Dienstleistungen — Handel, Essenslieferung, Fahrdienste, Ticketing — nutzen gewöhnliche Zahlungsabwicklung zu gewöhnlichen Kartengebühren. Sie behalten die Kontrolle und zahlen einen Bruchteil des Plattformsatzes.
Das falsch einzuordnen ist kein technischer Bug. Es ist eine App-Ablehnung — und wiederholte Umgehungsversuche gefährden das Listing. Sitzt Ihr Produkt nahe der Grenze, lesen Sie die aktuellen Richtlinien, statt sich darauf zu verlassen, was ein Wettbewerber scheinbar tut.
Was Wallets wirklich ändern
Apple Pay und Google Pay sind keine Zahlungsabwickler. Sie sind ein schnellerer Weg für den Kunden, Kartendaten zu übergeben, die bereits auf dem Gerät liegen — tokenisiert, sodass die echte Kartennummer Sie nie erreicht.
Zwei Konsequenzen. Erstens: Sie brauchen weiterhin einen Prozessor dahinter — das Wallet liefert die Berechtigung, der Prozessor bewegt das Geld. Zweitens, nützlicher: Durch die Tokenisierung fassen Sie Kartendaten nie direkt an, was Ihre Compliance-Exposition drastisch verengt.
Der Conversion-Effekt ist der Grund für den Aufwand. Die manuelle Karteneingabe zu entfernen entfernt genau den Schritt, an dem mobile Checkouts abgebrochen werden — und die Verbesserung ist dort am grössten, wo es am meisten weh tut: Erstkäufer, kleiner Bildschirm, keine hinterlegte Karte.
Abb. — Die Kartennummer berührt Ihren Code nie. Das ist der Grossteil des Compliance-Gewinns.
Den Prozessor wählen
Gebührensätze zählen bei kleinem Volumen weniger, als Teams erwarten, und bei grossem sehr — und der Schaufenster-Prozentsatz ist selten der ganze Preis.
Fragen Sie nach den Zusätzen: Währungsumrechnungsmarge, Chargeback-Gebühren, Auszahlungsrhythmus, Rückerstattungsabwicklung — und ob der beworbene Satz für den Kartenmix gilt, den Sie tatsächlich sehen. Wer an Konsumenten mit Premium-Karten verkauft, zahlt spürbar mehr als die Schlagzeile.
Fragen Sie nach lokalen Zahlarten. Kartenabdeckung ist in den meisten Ländern nicht der ganze Markt — TWINT in der Schweiz nicht vergessen, UPI in Indien, iDEAL in den Niederlanden, diverse Überweisungs- und Wallet-Verfahren anderswo. Ein Prozessor ohne die dominierende lokale Zahlart Ihres Markts kostet Sie Kunden, die schlicht nicht bequem zahlen können.
Und prüfen Sie die SDK-Qualität, denn Sie werden darin wohnen: native Unterstützung beider Plattformen, eine funktionierende Testumgebung, sinnvolle Fehlerkategorien, und Dokumentation, die Fehlerfälle abdeckt statt nur den Happy Path.
Die Compliance, die Sie nicht überspringen können
PCI DSS greift in dem Moment, in dem Kartendaten Ihre Systeme berühren. Die richtige Strategie: dafür sorgen, dass sie es nie tun — das SDK des Prozessors nutzen, damit die Kartendaten vom Gerät zum Prozessor gehen, ohne Ihre Server zu passieren. Das reduziert Ihre Pflichten auf die leichteste Stufe und ist die wertvollste Architekturentscheidung des ganzen Projekts.
Starke Kundenauthentifizierung gilt in Europa und zunehmend anderswo. Bestimmte Transaktionen brauchen einen zweiten Faktor über 3-D Secure — Ihr Checkout muss es also verkraften, mitten in der Zahlung unterbrochen und wieder aufgenommen zu werden. Testen Sie das gezielt; es ist die häufigste Quelle von «Zahlung schlägt manchmal fehl»-Meldungen.
Steuern sind bei digitalen Diensten über Grenzen hinweg genuin kompliziert und nichts, das man hinterher klärt. Sie verändern Preisanzeige, Rechnungsstellung — und teils, ob Sie in einem Markt überhaupt verkaufen dürfen.
Abos sind ihr eigenes Problem
Wiederkehrende Abrechnung sieht aus wie eine Variante des Einmalkaufs und verhält sich völlig anders.
Karten laufen ab, werden nach Betrugsfällen ersetzt und werden aus Gründen abgelehnt, die sich in einem Tag von selbst erledigen. Ein bedeutender Teil der Abo-Kündigungen ist unfreiwillig — Kunden, die weiterzahlen wollten und deren Zahlung leise scheiterte. Das gut zu behandeln heisst Dunning, und es ist überwiegend unglamouröse Logik: in vernünftigem Rhythmus wiederholen, den Kunden über einen Kanal informieren, den er wirklich liest, und das Konto in einem Kulanzzustand halten, statt sofort zu kündigen.
Card-Updater-Dienste, die die meisten Prozessoren anbieten, aktualisieren hinterlegte Karten, wenn eine Bank neu ausstellt. Sie kosten wenig und holen mehr zurück, als sie kosten.
Die andere Hälfte ist der Zustand. Ein Abo kann im Test sein, aktiv, überfällig, pausiert, gekündigt-aber-aktiv-bis-Periodenende oder abgelaufen — und Ihre App muss für jeden Fall das Richtige anzeigen. Teams, die das als Boolean modellieren, entdecken die Lücke, wenn ein Kunde, der letzte Woche gekündigt hat, drei Wochen zu früh den Zugriff verliert und sich öffentlich beschwert.
Und wenn Sie für digitale Güter auf Plattform-Billing sind, liegt die Berechtigung bei der Plattform statt auf Ihrem Server — Sie gleichen also deren Belegdaten permanent mit Ihren eigenen ab. Diese Abstimmung ist ein Dauerjob, keine Launch-Aufgabe.
Wo Implementierungen scheitern
Zahlung als Screen statt als Zustandsmaschine behandeln. Eine Zahlung kann ausstehend, autorisiert, eingezogen, gescheitert, bestritten oder erstattet sein — und die App kann an jedem Punkt dieser Sequenz beendet werden. Entwerfen Sie um die Zustände herum, nicht um den Button.
Keine Idempotenz. Ein Nutzer tippt bei langsamer Verbindung zweimal, oder die App wiederholt nach einem Timeout — und er zahlt doppelt. Idempotenz-Schlüssel auf jeder Zahlungsanfrage sind nicht optional.
Dem Client vertrauen. Betrag, Währung und Artikel werden serverseitig aus dem Warenkorb bestimmt — niemals von der App entgegengenommen. Das ist der schädlichste und häufigste Fehler der Kategorie.
Fehlertexte ignorieren. «Zahlung fehlgeschlagen» sagt dem Kunden nichts und verliert den Verkauf. «Ihre Bank hat abgelehnt — versuchen Sie eine andere Karte oder kontaktieren Sie sie» holt einen spürbaren Teil zurück.
Belege und Historie weglassen. Kunden erwarten zu sehen, was sie wann bezahlt haben. Das Fehlen produziert Support-Tickets, für immer.
Kein Erstattungsweg im Produkt. Wenn eine Rückerstattung ein Login ins Prozessor-Dashboard erfordert, werden Erstattungen langsam und lückenhaft dokumentiert. Bauen Sie sie in Ihr eigenes Admin-Tooling, mit erfasstem Grund — sonst entwickelt Ihr Support einen Workaround, den Sie nicht auditieren können.
Eine vernünftige Reihenfolge
Beginnen Sie mit Karten über einen einzigen Prozessor, serverseitiger Betragsbestimmung, Idempotenz und einer sauber modellierten Zahlungs-Zustandsmaschine. Machen Sie das korrekt und langweilig.
Dann die Wallets — überschaubarer Aufwand auf einer bestehenden Integration und die grösste verfügbare Conversion-Verbesserung.
Lokale Zahlarten kommen, sobald Sie wissen, wo Ihre Kunden wirklich sind — geleitet davon, wo Checkouts abgebrochen werden, nicht von einer Landkarte.
Testen Sie vor dem Launch mit echten Karten in der echten Welt, nicht nur in der Sandbox. Sandboxes modellieren den Happy Path und eine Handvoll geskripteter Ablehnungen; sie reproduzieren nicht den Authentifizierungsablauf einer Bank auf einem echten Telefon, während die SMS eintrifft und Ihre App im Hintergrund liegt. Ein kleiner Pilot, bei dem Mitarbeitende echte Kleinbeträge kaufen, findet an einem Tag mehr Probleme als zwei Wochen Sandbox.
Dann instrumentieren: Versuchsrate, Erfolgsrate, Fehlergründe, und wo im Ablauf Menschen aussteigen. Ohne das sind Zahlungsprobleme unsichtbar — Kunden schreiben kein Ticket über einen abgebrochenen Checkout. Sie kommen einfach nicht wieder.
Zahlungen, die sich an den Rändern benehmen, sind Standard in unseren Builds — sagen Sie uns, wo Ihre leckt.
