Kartenzahlung in der App annehmen: Leitfaden für Waren und Services

In diesem Leitfaden zeigen wir von Talha Aslan und Team den gesamten Ablauf. Er passt vor allem dann, wenn Sie Dinge verkaufen, die Menschen außerhalb der App nutzen: Essensbestellungen, Mode, Lieferungen, Reinigung oder Fahrdienste. Kurz gesagt sieht der Fahrplan so aus:

1. Klären Sie zunächst, ob Sie physische Waren und Dienstleistungen oder digitale Inhalte verkaufen.
2. Wählen Sie einen Zahlungsdienstleister oder einen Händlervertrag bei einer Bank.
3. Binden Sie das mobile SDK in die App ein und halten Sie geheime Schlüssel ausschließlich auf dem Server.
4. Testen Sie 3D Secure, gespeicherte Karten und Erstattungen einzeln in der Testumgebung.
5. Ergänzen Sie danach Apple Pay und Google Pay.
6. Reichen Sie die App mit Prüfnotizen ein, die den Zahlungsablauf erklären.

Warum nutzen Sie bei physischen Waren nicht das Bezahlsystem des Stores?

Apple und Google möchten nicht, dass Sie ihr eigenes Abrechnungssystem für Produkte nutzen, die außerhalb der App zum Einsatz kommen. Bei Apple ist das allerdings keine Option, sondern eine Regel. Richtlinie 3.1.3(e) der App Store Review Guidelines verlangt für physische Waren und Dienstleistungen, die außerhalb der App genutzt werden, andere Zahlungswege als den Kauf über den Store. Als Beispiele nennt Apple dabei Apple Pay und die klassische Karteneingabe.

Google sieht das zudem ähnlich. Die Zahlungsrichtlinie von Google Play schließt das Abrechnungssystem von Google Play für physische Waren ausdrücklich aus. Das gilt zudem für physische Dienstleistungen wie Fahrdienste, Reinigung, Essenslieferung oder Tickets für Veranstaltungen. Eine Lebensmittel App, die über die Play Abrechnung kassiert, verstößt also gegen die Richtlinie.

Diese Trennung hat für Sie auch einen Vorteil. Für physische Waren und Dienstleistungen fällt keine Storeprovision an; es gelten die Konditionen, die Sie mit Ihrem Zahlungsdienstleister vereinbaren. Allerdings liegt die Verantwortung für die Kartensicherheit damit bei Ihnen und Ihrem Anbieter. Der Rest dieses Leitfadens zeigt, wie Sie diese Verantwortung sauber tragen.

Wann ist der Kauf über den Store doch Pflicht?

Die Regel hängt an einer einzigen Frage: Nutzt die Person das Gekaufte innerhalb der App? Premiumfunktionen, Spielwährung, gesperrte Inhalte oder eine werbefreie Version zählen als digitale Inhalte. Konkret verlangt Apple für solche Freischaltungen in Richtlinie 3.1.1 den Kauf über den Store. Google Play fordert für digitale Funktionen und Inhalte ebenfalls das eigene Abrechnungssystem; in manchen Regionen gibt es zudem alternative Abrechnungsprogramme mit eigener Anmeldung.

Die Provisionsfrage und die Webzahlung haben wir ausführlich im Beitrag Kauf in der App oder Webzahlung erklärt, deshalb wiederholen wir sie hier nicht. Planen Sie dagegen ein digitales Abo, ist unser Leitfaden zum Abo Modell in der App der bessere Einstieg.

Es gibt außerdem eine Grauzone. Apple erlaubt andere Zahlungswege für Dienstleistungen in Echtzeit zwischen genau zwei Personen, zum Beispiel Nachhilfe oder Personal Training. Eine Liveklasse, die eine Trainerin gleichzeitig für viele Personen hält, braucht dagegen den Kauf über den Store. Beantworten Sie daher bei Ihrem Angebot zwei Fragen klar: Wer erhält die Leistung, und wo nutzt er sie?

Welcher Zahlungsweg passt zu welcher Verkaufsart?

Die folgende Tabelle ordnet typische Verkaufsarten aus unserer Praxis den offiziellen Regeln zu. Sie dient also als Entscheidungshilfe. Liegt Ihr Modell auf der Grenze, prüfen Sie die aktuelle Regel in den offiziellen Richtlinien.

Ein Punkt fällt dabei auf. Eine einzige App kann nämlich beide Modelle tragen, das heißt Karte und Store parallel. Ein Café kann zum Beispiel Kaffeebestellungen per Karte abrechnen und eine werbefreie Version über den Store verkaufen. In so einem gemischten Aufbau trennen Sie beide Abläufe im Code und in der Oberfläche klar voneinander.

Was unterscheidet Händlervertrag und Zahlungsdienstleister?

Ein Händlervertrag ist das Akzeptanzkonto, das Ihnen eine Bank für Kartenzahlungen im Internet einrichtet. Ein Zahlungsdienstleister arbeitet dagegen mit mehreren Banken zusammen und bietet Ihnen eine einzige Schnittstelle, meist mit fertigem mobilem SDK. Beide ermöglichen Kartenzahlung in der App; der Unterschied liegt im Integrationsaufwand und im laufenden Betrieb.

• Händlervertrag bei der Bank: Sie schließen den Vertrag direkt mit der Bank. Fehlt ein mobiles SDK, arbeiten Sie mit einer gehosteten Zahlungsseite oder einer WebView.
• Zahlungsdienstleister: Er liefert gespeicherte Karten, Erstattungen und Marktplatzfunktionen meist direkt mit. Zudem sind seine mobilen SDKs in der Regel ausgereifter.
• Gemeinsamkeit: In beiden Fällen landen die Kartendaten in der sicheren Umgebung des Anbieters, nicht auf Ihrem Server.

Die Auswahlkriterien vergleichen wir im Beitrag Zahlungsanbieter für Onlineshops auswählen. Für eine App kommt eine Frage hinzu: Bietet der Anbieter ein aktuelles und gut dokumentiertes SDK für iOS und Android? Prüfen Sie außerdem, ob er für Ihr Framework, etwa React Native oder Flutter, ein offizielles und gepflegtes Paket anbietet.

Wie arbeitet das SDK eines Zahlungsdienstleisters in der App?

Ein SDK (Software Development Kit) ist ein fertiges Codepaket des Anbieters, das Sie in Ihre App einbauen. Es steuert das Kartenformular, den Bildschirm für 3D Secure und die verschlüsselte Übertragung der Kartendaten. Die Kartennummer läuft somit weder durch Ihren Code noch über Ihren Server. Ein typischer Ablauf sieht so aus:

1. Die Person bestätigt den Warenkorb, und die App schickt die Bestellung an Ihren Server.
2. Ihr Server berechnet den Betrag aus den Preisen in der Datenbank neu und eröffnet beim Anbieter eine Zahlungssitzung.
3. Dann liefert der Anbieter einen einmaligen Sitzungsschlüssel für die App zurück.
4. Mit diesem Schlüssel öffnet die App das Kartenformular des SDK, und die Person gibt ihre Karte ein.
5. Bei Bedarf läuft 3D Secure, und das SDK meldet das Ergebnis an den Anbieter.
6. Der Anbieter benachrichtigt zusätzlich Ihren Server; erst danach bestätigen Sie die Bestellung.

Beide Seiten sprechen dann über eine API miteinander. Ist der Begriff neu für Sie, erklärt unser Beitrag Was ist eine API die Grundlagen in einfachen Worten. Die wichtigste Regel lautet allerdings: Der geheime Schlüssel des Anbieters kommt nie ins App Paket. Die App landet auf dem Telefon der Nutzer und lässt sich dort untersuchen, daher bleibt der geheime Schlüssel auf dem Server.

Gehört das Kartenformular in die App oder auf eine Zahlungsseite?

Für die Kartenerfassung in einer App gibt es drei grundlegende Wege. Ihre Wahl prägt das Nutzungserlebnis und zugleich Ihre Sicherheitspflichten. Der folgende Vergleich hilft daher bei der Entscheidung.

In den meisten Projekten empfehlen wir die erste Zeile. Hat der Anbieter kein SDK, ist auch der zweite Weg sicher; allerdings müssen Sie die Rückkehr aus der WebView in die App sorgfältig bauen. Sammeln Sie Kartennummern dagegen im eigenen Formular und senden sie an den eigenen Server, verarbeiten Sie selbst Kartendaten. Das bedeutet somit eine deutlich größere Last bei der PCI Konformität.

Wie funktioniert 3D Secure in einer mobilen App?

3D Secure ist ein zusätzlicher Sicherheitsschritt, mit dem die kartenausgebende Bank die Karteninhaberin oder den Karteninhaber bestätigt. Meist tippt die Person einen Einmalcode ein oder gibt die Zahlung in der Banking App frei. In einer mobilen App übernimmt diesen Schritt entweder der Bildschirm des SDK oder eine WebView mit der Seite der Bank.

Die häufigsten Probleme entstehen in der App nicht durch den Code, sondern durch den Ablauf:

• Nutzer wechseln für den Code in die Nachrichten App und finden danach einen zurückgesetzten Bezahlbildschirm vor.
• Jemand gibt die Zahlung in der Banking App frei, doch Ihre App wartet nicht auf das Ergebnis, und die Bestellung bleibt offen.
• Auf kleinen Telefonen läuft der Bestätigungsbildschirm über, und die Schaltfläche zum Bestätigen verschwindet.
• Nach einer Zeitüberschreitung versucht es die Person erneut, und es entstehen zwei Zahlungsversuche.

Deshalb brauchen Sie einen stabilen Rückweg vom Bildschirm für 3D Secure. Außerdem sollte der Bestellstatus an der Meldung an den Server hängen, nicht nur an dem, was die App sieht. Schlägt die Prüfung bei Ihren Kunden immer wieder fehl, finden Sie die Ursachen Schritt für Schritt im Beitrag 3D Secure fehlgeschlagen.

Was bedeuten gespeicherte Karten und Tokenisierung?

Tokenisierung heißt, dass Sie statt der Kartennummer einen Referenzwert nutzen, den Token. Er verweist auf die Karte, ist für sich allein aber wertlos. Tippt eine Person auf „Karte speichern“, bewahrt der Anbieter die Kartendaten auf und gibt Ihnen nur diesen Token zurück. Bei der nächsten Bestellung senden Sie dann den Token statt der Kartennummer.

Für Ihr Unternehmen ist der Nutzen vor allem bei der Sicherheit groß. Selbst bei einem Einbruch in Ihre Datenbank erreicht niemand die Kartennummern, denn der Token funktioniert nur mit Ihrem Händlerkonto im System des Anbieters. Zudem müssen Kundinnen und Kunden ihre Karte nicht bei jeder Bestellung neu eintippen. Das verkürzt den Bezahlvorgang vor allem bei Stammkunden spürbar.

Zeigen Sie auf dem Bildschirm außerdem nur wenig an. Konkret reichen meist die Kartenmarke, die letzten vier Ziffern und ein frei wählbarer Name. Den Sicherheitscode der Karte speichern Sie nie, weder in der App noch auf dem Server. Planen Sie zudem ein, dass die Bank auch bei einer gespeicherten Karte erneut 3D Secure oder den Sicherheitscode verlangen kann.

Worauf achten Sie bei Zahlung mit einem Tipp und gespeicherten Karten?

Zahlung mit einem Tipp steigert die Konversion, doch ein schlechter Aufbau beschädigt schnell das Vertrauen. Diese Regeln haben sich in unserer Praxis bewährt:

• Setzen Sie die Option „Karte speichern“ nicht vorab; die Person entscheidet selbst.
• Bieten Sie eine Übersicht der gespeicherten Karten, in der sich jede Karte mit einem Tipp löschen lässt.
• Löscht jemand sein Konto, entfernen Sie auch die Kartenreferenzen beim Anbieter.
• Prüfen Sie eine zusätzliche Freigabe, etwa per biometrischer Sperre, vor der Zahlung.
• Zeigen Sie Gesamtbetrag, Liefergebühr und Lieferzeit vor der Bestätigung auf einem Bildschirm.

Gespeicherte Karten bedeuten außerdem die Verarbeitung personenbezogener Daten. Für Datenschutzhinweise, Einwilligungen und Berechtigungen lesen Sie unseren Beitrag Datenschutz in der App. Hinweis: Dieser Abschnitt ist keine Rechtsberatung; stimmen Sie Ihre Texte mit einer Anwältin oder einem Anwalt ab.

Wie passen Apple Pay und Google Pay zur Kartenzahlung in der App?

Mit Apple Pay und Google Pay zahlen Nutzer mit einer Karte aus ihrer Wallet, ohne die Nummer einzutippen. Ein Detail ist dabei wichtig. Konkret sind Wallets für sich allein keine Zahlungsabwickler. Die Zahlung läuft weiterhin über Ihren Anbieter; die Wallet transportiert lediglich die Kartendaten verschlüsselt und tokenisiert.

Auf der Entwicklerseite zu Apple Pay stellt Apple klar, dass Sie bei dieser Methode die echte Kartennummer Ihrer Kunden nicht erhalten. Bei Google Pay wählen Sie dagegen einen Integrationstyp. Laut Google Pay API Referenz geht der Token beim Gateway Typ direkt an Ihren Zahlungsdienstleister. Der direkte Typ, bei dem Sie die Daten auf eigenen Servern entschlüsseln, setzt dagegen PCI DSS Konformität voraus, die ein Qualified Security Assessor bestätigt.

In der Praxis klären Sie also zuerst, ob Ihr Anbieter beide Wallets unterstützt. Danach erledigen Sie im Apple Entwicklerkonto die Schritte für Händlerkennung und Zertifikat und anschließend die Einrichtung für Google Pay nach Vorgabe Ihres Anbieters. Für Nutzer ist das Ergebnis klar: weniger Felder, weniger Tippfehler und meist ein schnellerer Bezahlvorgang.

Was verlangen die Storeregeln beim Einsatz von Apple Pay?

Richtlinie 4.9 von Apple stellt klare Erwartungen an Apps mit Apple Pay. Zunächst müssen Sie vor dem Kauf alle wesentlichen Kaufinformationen anzeigen. Außerdem verwenden Sie die Marken und Oberflächenelemente von Apple Pay so, wie es die Marketing und Designrichtlinien von Apple beschreiben. Eine Schaltfläche in Ihrer eigenen Markenfarbe oder ein verändertes Logo kann deshalb zur Ablehnung führen.

Buchen Sie regelmäßig wiederkehrende Beträge ab, etwa für eine wöchentliche Reinigung oder eine monatliche Kaffeelieferung, werden die Regeln noch konkreter. Apple verlangt dann mindestens folgende Angaben:

• Die Dauer der Verlängerungsperiode und dass sie bis zur Kündigung weiterläuft.
• Was die Person in jedem Zeitraum erhält.
• Den tatsächlichen Betrag, den Sie abbuchen.
• Wie die Kündigung funktioniert.

Diese Angaben gehören zudem zu einem guten Nutzungserlebnis. Daher empfehlen wir dieselbe Transparenz auch im Kartenformular, selbst wenn Sie bei wiederkehrenden Zahlungen ganz ohne Apple Pay arbeiten.

Was bedeutet PCI Konformität für Ihr Unternehmen?

PCI DSS ist der Standard mit technischen und organisatorischen Sicherheitsanforderungen für alle, die Kartendaten speichern, verarbeiten oder übertragen. Herausgeber ist das von den Kartenmarken gegründete PCI Security Standards Council. Der Geltungsbereich umfasst außerdem Systeme, die die Sicherheit der Umgebung mit Kartendaten beeinflussen können.

Wer Kartenzahlung in der App anbietet, kann sich über eine gute Nachricht freuen: Die richtige Architektur verkleinert Ihren Geltungsbereich deutlich. Laufen Kartennummern nur durch das SDK oder die gehostete Seite des Anbieters, berühren Ihre Systeme nie Kartendaten. Trotzdem sinkt Ihre Pflicht nicht auf null. Die Sicherheit von App und Server, der Schutz geheimer Schlüssel und die Konformitätsnachweise, die Ihr Anbieter verlangt, bleiben bei Ihnen.

Stellen Sie Ihrem Anbieter daher schon bei Vertragsabschluss drei Fragen. Welches Konformitätsdokument müssen wir für unseren Integrationstyp ausfüllen? Verlangen Sie eine jährliche Bestätigung? In welchen Fällen wächst unser Geltungsbereich? Da sich Anforderungen ändern können, klären Sie Ihre aktuellen Pflichten immer mit dem Anbieter und dem offiziellen Standard.

Welche Serverprüfungen braucht Kartenzahlung in der App?

Die schwächste Stelle eines Zahlungsablaufs ist oft nicht die App, sondern der Server dahinter. Das Telefon liegt in der Hand der Nutzer, und jeder Wert, den die App sendet, lässt sich verändern. Deshalb empfehlen wir diese Prüfungen auf Ihrem Server:

1. Der Server rechnet den Betrag: Vertrauen Sie nie einem Preis aus der App; summieren Sie Produkte und Lieferkosten erneut aus der Datenbank.
2. Eine Bestellung, eine Zahlung: Geben Sie jedem Zahlungsversuch eine eindeutige Bestellnummer, damit ein Doppeltipp nie zur Doppelbelastung führt.
3. Bestätigung per Servermeldung: Markieren Sie eine Bestellung erst als bezahlt, wenn Sie die Meldung des Anbieters an Ihren Server geprüft haben.
4. Protokolle: Speichern Sie ohne Kartendaten den Betrag, die Zeit, die Bestellnummer und den Antwortcode des Anbieters.
5. Schlüsselverwaltung: Halten Sie Test und Liveschlüssel getrennt und tauschen Sie sie regelmäßig aus.

Ein Beispiel: Eine Person verliert während der Zahlung die Verbindung, also sieht die App das Ergebnis nicht. Ihr Server hat die Meldung jedoch erhalten, und beim nächsten Öffnen zeigt die App den richtigen Status. So verhindern Sie die meisten Beschwerden nach dem Muster „Geld abgebucht, aber keine Bestellung zu sehen“, bevor sie beim Support ankommen.

Wie gehen Sie mit Erstattungen, Stornos und Teilbeträgen um?

Erstattungen gehören bei Waren und Dienstleistungen einfach dazu. Eine Lieferung kommt unvollständig an, der Kurier verspätet sich, oder jemand sagt einen Termin ab. Planen Sie Erstattungen deshalb schon beim Entwurf des Zahlungsablaufs ein. Sonst wird jede Erstattung zu einer fehleranfälligen Handarbeit im Dashboard.

Die meisten Anbieter unterstützen volle und teilweise Erstattungen über ihre API. Manche bieten zudem Autorisierung und spätere Buchung an: Sie reservieren den Betrag zunächst und belasten erst danach die endgültige Summe. Beispielszenario: Eine Lebensmittel App reserviert den Warenkorbwert, zieht beim Kommissionieren fehlende Artikel ab und bucht nur den tatsächlichen Betrag. Prüfen Sie Verfügbarkeit und Bedingungen dieser Funktion in der Dokumentation Ihres Anbieters.

Aus Kundensicht zählt vor allem die Frage, wann das Geld zurück ist. Das hängt von der Bank ab. Statt eines festen Datums empfehlen wir daher einen ehrlichen Satz wie „je nach Bank kann das einige Werktage dauern“. Ein sichtbarer Erstattungsstatus in der Bestellübersicht senkt außerdem spürbar die Zahl der Supportanfragen.

Was senkt die Konversion im mobilen Bezahlvorgang am stärksten?

Selbst bei perfekter Technik kann der Bezahlbildschirm Nutzer verlieren. Auf dem Telefon ist der Platz klein, die Aufmerksamkeit kurz, und jedes zusätzliche Feld ist eine Gelegenheit zum Abbruch. Diese Fehler sehen wir am häufigsten:

• Registrierungszwang: Vor der Zahlung muss die Person ein langes Formular ausfüllen.
• Überraschende Kosten: Liefergebühr oder Servicegebühr erscheinen erst im letzten Schritt.
• Falsche Tastatur: Im Feld für die Kartennummer öffnet sich kein Ziffernblock.
• Unklare Fehlermeldung: Die App meldet „Zahlung fehlgeschlagen“, nennt aber keinen nächsten Schritt.
• Fehlende Vertrauenssignale: Neben dem Kartenformular fehlen Firmenname, Erstattungsregeln oder Kontaktdaten.

Viele dieser Fehler kommen auch auf Websites vor; Lösungen dazu finden Sie im Beitrag Warenkorbabbrüche reduzieren. Der Unterschied in der App sind die Wallets. Stehen Apple Pay und Google Pay direkt unter dem Warenkorb, entfällt das Kartenformular für viele Nutzer komplett.

Welche Konten und Unterlagen brauchen Sie vor dem Start?

Wenn Sie die Formalitäten vor dem Programmieren klären, verkürzt sich Ihr Zeitplan deutlich. Anbieter und Banken prüfen bei der Händleranmeldung Ihr Unternehmen, Ihr Produkt und Ihre Verkaufsbedingungen. Die Liste der Unterlagen unterscheidet sich je nach Anbieter, daher holen Sie die aktuelle Liste direkt dort ein. Nach unserer Erfahrung helfen diese Vorbereitungen:

• Offizielle Unterlagen zu Ihren Firmendaten und Ihrem Geschäftszweck.
• Verkaufsbedingungen, Erstattungsregeln und Kontaktdaten, die in der App und auf der Website erreichbar sind.
• Eine klare Beschreibung der Waren oder Dienstleistungen samt Beispielbildschirmen.
• Entwicklerkonten bei Apple und Google, die auf das Unternehmen laufen.

Der letzte Punkt geht oft unter. Stimmt der Verkäufername im Store mit dem Firmennamen beim Anbieter überein, stärkt das sowohl das Vertrauen als auch die Prüfung. Zudem senkt ein Name auf der Kartenabrechnung, den Kunden sofort erkennen, die Zahl der Rückbuchungen nach dem Muster „diese Abbuchung kenne ich nicht“. Kurz gesagt: Sammeln Sie die Unterlagen früh, dann warten Sie nach der Entwicklung nicht auf die Freigabe.

Welche Tests braucht Kartenzahlung in der App vor dem Start?

Fast jeder Zahlungsdienstleister bietet eine Testumgebung (Sandbox) und Testkarten. Dort fließt kein echtes Geld, also können Sie jedes Szenario gefahrlos ausprobieren. Vor dem Livegang nutzen wir diese Checkliste:

1. Testen Sie erfolgreiche Zahlung, fehlende Deckung und abgelehnte Karte getrennt.
2. Prüfen Sie bei 3D Secure den richtigen Code, einen falschen Code und eine Zeitüberschreitung.
3. Schicken Sie die App während der Zahlung in den Hintergrund, trennen Sie das Internet und kehren Sie zurück.
4. Probieren Sie Karte speichern, Zahlung mit gespeicherter Karte und Karte löschen aus.
5. Kontrollieren Sie, ob volle und teilweise Erstattungen korrekt in der Bestellübersicht erscheinen.
6. Testen Sie Apple Pay und Google Pay auf einem echten Gerät mit einer Testkarte.
7. Lassen Sie beim Livegang zwei Personen prüfen, ob die Schlüssel zur Liveumgebung gehören.

Der letzte Punkt wirkt banal. Eine App mit Testschlüsseln kann allerdings keine Zahlungen annehmen, und Teams bemerken das meist erst bei den ersten Bestellungen. Zudem ist eine kleine echte Bestellung beim Start mit anschließender Erstattung der praktischste Weg, die ganze Kette zu prüfen.

Wie vermeiden Sie eine Ablehnung im Store wegen des Zahlungsablaufs?

Das Prüfteam der Stores bewegt sich durch Ihre App wie echte Nutzer. Erreicht es den Bezahlvorgang nicht oder erkennt nicht, dass Sie physische Waren verkaufen, folgen Rückfragen und Verzögerungen. Bereiten Sie Ihre Prüfnotizen daher sorgfältig vor.

• Schreiben Sie in die Prüfnotiz klar, dass Sie physische Waren oder Dienstleistungen für die Nutzung außerhalb der App verkaufen.
• Geben Sie ein funktionierendes Demokonto an, falls die App eine Anmeldung verlangt.
• Verkaufen Sie eine digitale Funktion, bieten Sie diese über den Store an.
• Lassen Sie keine Links stehen, die für digitale Inhalte auf eine externe Zahlungsseite führen.

In gemischten Apps entsteht das häufigste Problem, wenn ein digitaler Vorteil per Karte verkauft wird, etwa Rabatte über eine kostenpflichtige Mitgliedschaft. In so einem Aufbau definieren Sie genau, was die Mitgliedschaft enthält und wo sie genutzt wird. Sind Sie unsicher, lesen Sie die passende Richtlinie selbst und richten Sie das Modell danach aus, statt zu raten.

Lohnt sich Zahlung in der App, wenn Sie schon einen Onlineshop haben?

Haben Sie bereits einen Onlineshop, lautet die erste Frage, ob Sie überhaupt eine App brauchen. Diese Entscheidung mit Kriterien wie Bestellhäufigkeit, Treueprogramm und Pushnachrichten behandeln wir im Beitrag Braucht ein Onlineshop eine App.

Steht die Entscheidung für eine App, ist eine gemeinsame Zahlungsbasis für beide Kanäle am effizientesten. Sie nutzen denselben Anbieter, dasselbe Bestellsystem und dieselben Erstattungsregeln. Dadurch funktioniert eine auf der Website gespeicherte Karte auch in der App, sofern Ihr Anbieter das unterstützt. Zudem laufen die Berichte an einem Ort zusammen, was den Abgleich in der Buchhaltung erleichtert.

Beispielszenario: Eine Modemarke nutzt im Shop und in der App denselben Anbieter. Eine Kundin speichert ihre Karte einmal im Shop, meldet sich dann in der App an und zahlt mit einem Tipp. Für dieses Szenario müssen beide Kanäle dasselbe Kundenkonto teilen.

Mit wem setzen Sie die Kartenzahlung in Ihrer App um?

Kartenzahlung ist der sensibelste Teil einer App, denn jeder Fehler kostet Geld und Vertrauen. Deshalb empfehlen wir, den Zahlungsablauf mit einem Team umzusetzen, das die Storeregeln kennt und auch die Serverseite baut. Bei Talha Aslan und Team richten wir in Projekten der App Entwicklung das SDK des Anbieters, 3D Secure, gespeicherte Karten und Wallets als einen durchgehenden Ablauf ein.

Wir entwickeln Ihre App, bereiten sie auf die Storeprüfung vor und bringen sie in die Stores. Sie schließen lediglich den Händlervertrag mit Ihrem Zahlungsdienstleister ab; die Technik übernimmt unser Team. Möchten Sie klären, welcher Zahlungsweg zu Ihrem Geschäft passt, beschreiben Sie Ihr Projekt über unsere Seite zur App Entwicklung für Unternehmen und fordern Sie ein Angebot an.