Skip to main content

Quick Start

Bringen Sie Ihre mobile Zahlungsintegration in 4 einfachen Schritten zum Laufen

Platform Examples

Vollständige Codebeispiele für Android, iOS, React Native und Flutter

Checkout Customization

Konfigurieren Sie Themes, Vorausfüllung und 14 mobile-spezifische Parameter

Mobile Recipes

Checkout-Konfigurationen zum Kopieren und Einfügen für 5 häufige mobile Szenarien
Dodo Payments stellt ein offizielles Checkout-SDK für Android, iOS, React Native, und Flutter bereit. Jedes SDK kapselt das unten dokumentierte Muster (Checkout- URL öffnen, Rückgabe erfassen, Ergebnis analysieren) hinter einem einzigen typisierten start(...)-Aufruf und bietet eine integrierte Wiederherstellung abgebrochener Sitzungen. Verwenden Sie nur dann eine manuelle WebView, wenn keines der SDKs zu Ihrem Stack passt.

Voraussetzungen

Bevor Sie Dodo Payments in Ihre mobile App integrieren, stellen Sie sicher, dass Sie über Folgendes verfügen:
  • Dodo Payments-Konto: Aktives Händlerkonto mit API-Zugriff
  • API-Zugangsdaten: API-Schlüssel und Webhook-Secret-Key aus Ihrem Dashboard
  • Mobiles App-Projekt: Android-, iOS-, React-Native- oder Flutter-Anwendung
  • Backend-Server: Zur sicheren Erstellung von Checkout-Sitzungen

Integrationsablauf

Die mobile Integration folgt einem sicheren Prozess in 4 Schritten, bei dem Ihr Backend die API-Aufrufe verarbeitet und Ihre mobile App die Benutzererfahrung steuert.
Der Deep-Link status ist lediglich ein UI-Hinweis darauf, was dem Benutzer angezeigt werden soll. Gewähren Sie Zugriff immer über den payment.succeeded / subscription.active Webhook in Ihrem Backend – niemals allein auf Grundlage des mobilen Ergebnisses.
1

Backend: Create Checkout Session

Checkout Session API Docs

Erfahren Sie, wie Sie eine Checkout-Sitzung in Ihrem Backend mit Node.js, Python und weiteren Technologien erstellen. Vollständige Beispiele und Parameterreferenzen finden Sie in der speziellen Dokumentation zur Checkout Sessions API.
Sicherheit: Checkout-Sitzungen müssen auf Ihrem Backend-Server erstellt werden, niemals in der mobilen App. Dadurch werden Ihre API-Schlüssel geschützt und eine korrekte Validierung sichergestellt.
2

Mobile: Get Checkout URL

Ihre mobile App ruft Ihr Backend auf, um die Checkout-URL abzurufen. Authentifizieren Sie diese Anfrage mit dem Sitzungstoken des angemeldeten Benutzers.
Sicherheit: Mobile Apps kommunizieren ausschließlich mit Ihrem Backend, niemals direkt mit der Dodo Payments API.
3

Mobile: Open Checkout in Browser

Öffnen Sie die Checkout-URL zur Zahlungsabwicklung in einem sicheren In-App-Browser. Oder überspringen Sie die manuelle Einrichtung vollständig mit dem offiziellen Checkout-SDK für Ihre Plattform.

Pick your mobile SDK

Installationsschritte und Einrichtungsanweisungen für Android, iOS, React Native und Flutter.
4

Backend: Handle Payment Completion

Verarbeiten Sie den Abschluss der Zahlung über Webhooks und Redirect-URLs, um den Zahlungsstatus zu bestätigen.

SDK auswählen

Jedes mobile SDK stellt denselben Vertrag bereit: Ein start(...)-Aufruf öffnet den gehosteten Checkout von Dodo im nativen Browser der Plattform und gibt ein typisiertes CheckoutResult zurück, dessen status succeeded, failed, cancelled, pending oder expired ist. Keines davon enthält einen API-Schlüssel oder ruft die Dodo Payments API auf; alle vier unterstützen die Wiederherstellung abgebrochener Sitzungen.

Android

com.dodopayments.api:checkout-android öffnet einen Chrome Custom Tab. Erfordert minSdk 23.

iOS

dodopayments-mobile-sdk-ios öffnet SFSafariViewController. Erfordert iOS 16+.

React Native

@dodopayments/react-native-checkout, ein Turbo Module über beide nativen Kerne. Erfordert React Native 0.76+.

Flutter

dodopayments_checkout, ein Pigeon-Kanal über beide nativen Kerne. Erfordert Flutter 3.44+.
Der zurückgegebene status ist ein UI-Hinweis, kein Zahlungsnachweis. Bestätigen Sie jede Zahlung über Ihr Backend anhand des payment.succeeded / subscription.active Webhooks oder rufen Sie die Zahlung mit Ihrem Secret Key ab.

Callback-URL-Schema registrieren

Alle vier SDKs übergeben die Kontrolle über ein benutzerdefiniertes URL-Schema an Ihre App, das Sie selbst auswählen, zum Beispiel myapp://checkout/return. Registrieren Sie es einmal pro Plattform:
android/app/build.gradle
Das Manifest des SDKs deklariert die Redirect-Aktivität bereits, daher müssen Sie kein Manifest-XML hinzufügen.
Möchten Sie die Implementierung selbst erstellen? Öffnen Sie checkout_url im Systembrowser der Plattform (Android Custom Tabs / iOS SFSafariViewController), fangen Sie die Navigation zu return_url ab und lesen Sie anschließend die Query-Parameter status und payment_id aus. Die oben genannten SDKs erledigen dies für Sie.
Öffnen Sie den Checkout nicht in einer eingebetteten WebView (WKWebView / Android WebView). Dies ist das häufigste Problem bei mobilen Integrationen: Eine eingebettete WebView unterdrückt Apple Pay und Google Pay und kann außerdem 3-D-Secure-Herausforderungen sowie das automatische Ausfüllen gespeicherter Karten beeinträchtigen. Dadurch sehen Kunden weniger Zahlungsoptionen und es treten mehr Fehler auf. Verwenden Sie immer das SDK oder öffnen Sie checkout_url im Systembrowser (Custom Tabs / SFSafariViewController). Genau deshalb funktionieren Apple Pay und Google Pay in dieser nativen Browseroberfläche weiterhin.

Darstellung anpassen

Jedes SDK akzeptiert einen optionalen customization-Parameter für start(...) / CheckoutParams, der Darstellung und Verhalten der nativen Browseroberfläche steuert – Symbolleiste, Schaltflächen und Präsentation. Dies ist vom eigenen Theme der Checkout-Seite getrennt, das Sie serverseitig über customization.theme_config in der Checkout-Sitzung konfigurieren. Die Optionen sind nach Plattform gruppiert, da Android Custom Tab und iOS SFSafariViewController unterschiedliche native Steuerelemente bereitstellen. Alle Felder sind optional; wenn customization vollständig weggelassen wird, verwendet jede Plattform ihre Standarddarstellung.
Color
Hintergrundfarbe der Symbolleiste.
Color
Farbe der Navigationsleiste.
Color
Farbe der Trennlinie über der Navigationsleiste.
'default' | 'back'
default zeigt das systemeigene „X“-Symbol an; back zeichnet stattdessen einen Zurück-Pfeil.
'start' | 'end'
Auf welcher Seite der Symbolleiste die Schaltfläche zum Schließen angezeigt wird.
boolean
Zeigt das Teilen-Symbol der Symbolleiste an.
boolean
Zeigt den Seitentitel unter der URL in der Symbolleiste an.
boolean
Ermöglicht das automatische Ausblenden der Symbolleiste beim Scrollen.
boolean
Zeigt „Diese Seite als Lesezeichen speichern“ im Überlaufmenü an.
boolean
Zeigt „Seite herunterladen“ im Überlaufmenü an.
'system' | 'light' | 'dark'
Erzwingt eine helle oder dunkle Darstellung unabhängig von der Systemeinstellung des Geräts.
'done' | 'close' | 'cancel'
Beschriftung oder Symbol der Schaltfläche zum Schließen.
'pageSheet' | 'fullScreen'
pageSheet wird als Karte mit „Zum Schließen wischen“ angezeigt; fullScreen nimmt den gesamten Bildschirm ein.
boolean
Ermöglicht das Einklappen der Symbolleiste beim Scrollen. Nur sichtbar, wenn presentationStyle fullScreen ist – pageSheet hält die Leisten unabhängig von dieser Einstellung fixiert.
'system' | 'light' | 'dark'
Erzwingt eine helle oder dunkle Darstellung unabhängig von der Systemeinstellung des Geräts.

Checkout-Seite anpassen

Der Abschnitt Darstellung anpassen oben steuert die native Browseroberfläche – Symbolleiste, Schaltflächen und Farbschema. Die Checkout-Seite selbst – die angezeigten Felder, das Theme und die verfügbaren Zahlungsmethoden – wird serverseitig bei der Erstellung der Checkout-Sitzung konfiguriert. Diese Parameter haben den größten Einfluss auf die mobile Conversion. Die folgenden Parameter befinden sich an drei verschiedenen Stellen der Checkout-Sitzungsanfrage – in der Spalte Ziel sehen Sie, zu welchem Objekt der jeweilige Parameter gehört. Dies falsch zu konfigurieren ist der häufigste Fehler: Ein Parameter im falschen Objekt wird stillschweigend ignoriert.
Übergeben Sie billing_currency und billing_address.country immer gemeinsam. Wenn einer der beiden Parameter fehlt, kann Adaptive Currency die Abrechnungswährung anhand der IP-Adresse des Kunden stillschweigend ändern. Bei einem Händler wurde ein US-Abonnement in EUR umgewandelt, als der Kunde nach Europa reiste – weil das Abrechnungsland nicht explizit festgelegt war.
Der größte einzelne Conversion-Hebel auf Mobilgeräten: show_order_details: false und minimal_address: true setzen. Zahlungsmethoden oberhalb des sichtbaren Bereichs zu platzieren und die Anzahl der Formularfelder zu reduzieren, sind die beiden wirkungsvollsten Änderungen.
Checkout im Vergleich: ausgeklappte Bestelldetails (Felder unterhalb des sichtbaren Bereichs) gegenüber eingeklappten Details (Felder oben)

show_order_details: false moves the contact and payment fields above the fold, instead of behind the order summary.

Setzen Sie minimal_address: true, um nur eine Postleitzahl statt der vollständigen Felder für Straße, Stadt und Bundesland zu erfassen:
Checkout im Vergleich: vollständiges Rechnungsadressformular gegenüber Eingabe nur der Postleitzahl

minimal_address: true reduces the billing address to a single postcode field.

Setzen Sie theme: "system", damit der Checkout die helle oder dunkle Darstellung des Geräts übernimmt:
Checkout im Vergleich: dieselbe Seite in heller und dunkler Darstellung

With theme: system, the checkout follows the device's light or dark appearance automatically.

Die Verfügbarkeit von Zahlungsmethoden variiert je nach Produkttyp. Apple Pay und Cash App werden für wiederkehrende Abonnements mit einem Betrag ungleich null unterstützt. Für einmalige Zahlungen sind alle aktivierten Methoden verfügbar.

Full checkout session parameter reference

Alle verfügbaren Parameter, Typen und Standardwerte finden Sie im Leitfaden zu Checkout-Sitzungen.

Für Mobilgeräte optimierte Rezepte

Jedes der folgenden Rezepte ist ein vollständiger Request-Body für eine Checkout-Sitzung. Kopieren Sie das passende Rezept, ersetzen Sie die Produkt-ID und übergeben Sie es an den Endpoint Ihres Backends zur Sitzungserstellung.
Verwenden Sie dies, wenn Sie das kürzestmögliche Formular wünschen: Zahlungsmethoden oben, für die Adresse nur eine Postleitzahl erforderlich, kein Rabattfeld und ein Theme passend zum Gerät.
Alle verfügbaren Parameter und ihre Standardwerte finden Sie unter Checkout Sessions.
Verwenden Sie dies, wenn sich die Checkout-Seite wie ein Teil Ihrer App anfühlen soll. Legen Sie Ihre Markenfarben, eine benutzerdefinierte Schriftart und eine lokalisierte Beschriftung der Bezahlschaltfläche fest.
Marken-Checkout für Mobilgeräte mit einer benutzerdefinierten dunkelblauen Palette über theme_config
theme_config akzeptiert separate dark- und light-Objekte, damit sich die Palette an die aktuelle Darstellung des Geräts anpassen kann. Die vollständige Referenz der Farbschlüssel finden Sie unter Checkout Sessions.
Verwenden Sie dies für angemeldete Benutzer, die bereits bezahlt haben. Kombinieren Sie eine Kunden-ID, die gespeicherte Zahlungsmethode des Kunden und confirm: true, um das Checkout-Formular vollständig zu überspringen.
status in der Deep-Link-Rückgabe ist lediglich ein UI-Hinweis. Bestätigen Sie den Zugriff, indem Sie den payment.succeeded-Webhook in Ihrem Backend empfangen.
Verwenden Sie dies für Abonnementprodukte, die vor dem ersten Abrechnungszyklus eine kostenlose Testphase anbieten.
Gewähren Sie Zugriff auf das Feature, wenn Ihr Backend den subscription.active-Webhook empfängt – nicht wenn das mobile SDK zurückkehrt. Den vollständigen Webhook-Ablauf finden Sie im Leitfaden zur Abonnementintegration.
Verwenden Sie dies, um die Karte eines Kunden für spätere Abbuchungen zu tokenisieren (Wallet-Aufladungen, Pay-as-you-go, BNPL), ohne die Beschriftung „subscription“ anzuzeigen. Der Kunde autorisiert seine Zahlungsmethode einmal; später berechnen Sie variable Beträge nach Bedarf.
Dieses Muster wird von Apps verwendet, die nutzungsabhängig abrechnen – beispielsweise eine Astrologie-App, die pro Sitzung eine vorab autorisierte Karte belastet, statt nach einem festen Zeitplan.
On-Demand-Abbuchungen erfordern mindestens 1 USD (100 Cent). Beträge unter 1 USD werden mit "value out of range" abgelehnt. Für eine Autorisierung über null verwenden Sie wie oben gezeigt mandate_only: true und belasten Sie in nachfolgenden Aufrufen mindestens 1 USD.
Den vollständigen Abbuchungsablauf, Webhook-Ereignisse und Wiederholungsrichtlinien finden Sie unter On-Demand-Abonnements.

Abonnementabläufe auf Mobilgeräten

Abonnements werden über denselben Checkout-Sitzungsablauf wie einmalige Zahlungen erstellt – das mobile SDK öffnet den gehosteten Checkout, der Kunde schließt das Abonnement ab und Ihre App verarbeitet die Deep-Link-Rückgabe. Der Lebenszyklus des Abonnements wird anschließend vollständig im Backend verwaltet.

Reguläre wiederkehrende Abonnements

Für Abrechnungen in festen Intervallen (monatlich, jährlich) erstellen Sie eine Checkout-Sitzung mit einem Abonnementprodukt und einem Deep-Link return_url. Ihr Backend empfängt subscription.active, sobald das Abonnement bestätigt wurde.
Apple Pay und Cash App werden für wiederkehrende Abonnements mit einem Betrag ungleich null unterstützt.
Den vollständigen Backend-Webhook-Ablauf finden Sie im Leitfaden zur Abonnementintegration.

On-Demand-Abonnements

Mit On-Demand-Abonnements autorisieren Sie die Zahlungsmethode eines Kunden einmal und belasten später variable Beträge – ideal für Wallet-Aufladungen, Pay-as-you-go und alle Szenarien, in denen der Zahlungsbetrag im Voraus nicht bekannt ist. Den vollständigen Request-Body finden Sie im oben genannten Rezept On-Demand-Mandat. Wichtige mobile Aspekte:
  • Setzen Sie show_on_demand_tag: false, damit die Checkout-Seite keine Begriffe wie „subscription“ oder „on-demand“ anzeigt. Bei Anwendungsfällen zur Kartentokenisierung erwarten Kunden keine Abonnementterminologie.
  • Nachdem das Mandat autorisiert wurde, empfängt Ihr Backend subscription.active. Speichern Sie subscription_id – Sie verwenden es für alle zukünftigen Abbuchungen.
Der Mindestbetrag beträgt 1 USD (100 Cent). On-Demand-Abbuchungen unter 1 USD werden mit "value out of range" abgelehnt. Belasten Sie entweder mindestens 1 USD oder verwenden Sie mandate_only: true, um ohne Belastung zu autorisieren und den ersten tatsächlichen Betrag später einzuziehen.
Vermeiden Sie zu schnelle Wiederholungsversuche. Wenn eine vorherige Abbuchung noch verarbeitet wird, schlägt eine neue Abbuchung für dasselbe Abonnement mit "Cannot create new charge as previous payment is not successful yet" fehl. Dies kommt besonders häufig bei indischen Zahlungsmethoden (UPI, indischen Debit- und Kreditkarten) vor, bei denen RBI-Mandatsregeln eine Transaktion bis zu 48 Stunden im Verarbeitungsstatus halten können. Fügen Sie vor einem erneuten Versuch eine Cooldown-Prüfung in Ihre Abbuchungslogik ein.
Den vollständigen Abbuchungs-Endpoint, Webhook-Ereignisse und Wiederholungsrichtlinien finden Sie unter On-Demand-Abonnements.

Abonnement mit kostenloser Testphase

Übergeben Sie subscription_data.trial_period_days in der Checkout-Sitzung, um vor dem ersten Abrechnungszyklus eine Testphase anzubieten. Der Kunde autorisiert seine Zahlungsmethode bei der Anmeldung zur Testphase; die erste Abbuchung erfolgt automatisch nach deren Ende. Den vollständigen Request-Body finden Sie im oben genannten Rezept Abonnement mit kostenloser Testphase.

Upgrades und Downgrades

Planänderungen werden über die API in Ihrem Backend vorgenommen, nicht über eine neue Checkout-Sitzung. Dodo Payments berechnet die anteilige Abrechnung automatisch. Um Kunden eine Self-Service-Option zu bieten, betten Sie das Customer Portal ein oder verlinken Sie darauf.

Subscription Integration Guide

Vollständige Backend-Einrichtung: Webhook-Ablauf, Zugriffsbereitstellung und Kündigung

On-Demand Subscriptions

Mandatsautorisierung, variable Abbuchungen und Wiederholungsrichtlinien

Upgrade / Downgrade

Strategien für anteilige Abrechnung, Planänderungen und Anpassungen der Sitzanzahl

Customer Portal

Self-Service-Abonnementverwaltung für Ihre Kunden

Checkout-Abbrüche reduzieren

Bei mobilen Checkouts kommt es häufiger zu Abbrüchen als im Web – kleinere Bildschirme, mehr Ablenkungen und längere Formulare tragen dazu bei. Die schnellsten Verbesserungen erzielen Sie direkt über die Konfiguration der Checkout-Sitzung.

Formular optimieren

Kundendaten vorausfüllen

Jedes Feld, das der Kunde nicht selbst eingeben muss, verringert die Wahrscheinlichkeit eines Abbruchs:
  • Neue Kundencustomer.email und customer.name aus Ihrer Authentifizierungssitzung setzen.
  • Wiederkehrende Kundencustomer.customer_id setzen, um alle gespeicherten Daten automatisch vorauszufüllen.
  • Währungbilling_currency und billing_address.country immer gemeinsam übergeben.

Tools zur Wiederherstellung

Abandoned Cart Recovery

Automatisierte E-Mail-Sequenzen für unvollständige Checkouts

Payment Retries

Intelligente Wiederholungslogik für fehlgeschlagene Abonnementverlängerungen

Subscription Dunning

Reaktivierungs-E-Mails für ausgelaufene Abonnements

Recovery Overview

Alle Wiederherstellungstools und ihre gemeinsame Umsatzwirkung
Testen Sie E-Mails zur Warenkorbwiederherstellung, bevor Sie sie aktivieren. Erstellen Sie eine Checkout-Sitzung im Live-Modus und geben Sie ungültige Kartendaten ein. Die fehlgeschlagene Zahlung löst den Wiederherstellungsablauf per E-Mail aus, sodass Sie genau sehen können, was Ihre Kunden erhalten.

Best Practices

  • Sicherheit: Liefern Sie niemals einen API-Schlüssel in Ihrer App aus. Erstellen Sie Checkout-Sitzungen in Ihrem Backend und übergeben Sie dem Client nur das resultierende checkout_url.
  • Berechtigung: Behandeln Sie CheckoutResult.status als UI-Hinweis. Gewähren Sie Zugriff erst, nachdem Ihr Backend die Zahlung bestätigt hat.
  • Benutzererfahrung: Zeigen Sie einen Ladestatus an, während Ihr Backend die Sitzung erstellt, und behandeln Sie cancelled als normales Ergebnis, nicht als Fehler.
  • Tests: Verwenden Sie den Testmodus und Testkarten und überprüfen Sie den Roundtrip der Rückgabe-URL sowohl auf einem echten Gerät als auch in einem Simulator.
  • Conversion: Setzen Sie show_order_details: false und minimal_address: true, um die besten Abschlussraten beim mobilen Checkout zu erzielen. Zahlungsmethoden oberhalb des sichtbaren Bereichs zu platzieren und Formularfelder zu reduzieren, sind die wirkungsvollsten Änderungen.
  • Währung: Übergeben Sie billing_currency und billing_address.country immer explizit – fehlt einer der beiden, kann Adaptive Currency die Abrechnungswährung anhand der IP-Adresse des Kunden ändern.
  • On-Demand-Abrechnung: Setzen Sie show_on_demand_tag: false, wenn Sie On-Demand-Abonnements zur Kartentokenisierung verwenden. Kunden in einem Wallet-Aufladungsablauf erwarten keine Begriffe wie „subscription“.
  • Wiederherstellung: Aktivieren Sie die Wiederherstellung abgebrochener Warenkörbe in Ihrem Dodo Payments-Dashboard, um Kunden, die den Checkout nicht abschließen, automatisch erneut anzusprechen.

Fehlerbehebung

Häufige Probleme

  • Callback trifft nie ein: Das Schema in returnUrl muss mit dem registrierten Schema übereinstimmen. Unter Android ist dies der dodoCallbackScheme-Manifest-Platzhalter, unter iOS und React Native der Info.plist-URL-Typ.
  • Checkout kehrt unter iOS zum Browser statt zur App zurück: Sie haben die eingehende URL nicht weitergeleitet. Rufen Sie DodoCheckout.handleOpenURL(url) aus .onOpenURL, scene(_:openURLContexts:) oder einem React-Native-Listener Linking auf.
  • PLATFORM_ERROR unter Android: Meist liegt ein nicht übereinstimmendes Schema vor. Der Fehler kann auch auftreten, wenn MainActivity android:taskAffinity="" setzt (den standardmäßigen flutter create), wodurch einige OEM-Builds den laufenden Checkout verlieren können.
  • ALREADY_IN_PROGRESS: Ein Checkout ist noch geöffnet. Warten Sie den vorherigen Checkout ab oder schließen Sie ihn, bevor Sie einen neuen starten.
  • Build schlägt mit einem nicht aufgelösten Platzhalter fehl: Sie haben das Android SDK hinzugefügt, aber manifestPlaceholders["dodoCallbackScheme"] nicht gesetzt.
  • Zahlung erfolgreich, aber kein Zugriff gewährt: Das ist zu erwarten, wenn Sie sich auf das mobile Ergebnis stützen. Gewähren Sie Zugriff stattdessen über den payment.succeeded / subscription.active Webhook.
  • Apple Pay / Google Pay werden mobil nicht angezeigt: Der Checkout wird in einer eingebetteten WebView (WKWebView / Android WebView) geladen, die Wallets unterdrückt und 3-D Secure beeinträchtigen kann. Öffnen Sie ihn stattdessen mit dem SDK oder im Systembrowser (Custom Tabs / SFSafariViewController).

Zusätzliche Ressourcen

Bei Fragen oder für Support wenden Sie sich an support@dodopayments.com.
Zuletzt geändert am 21. August 2026