Diese Seite behandelt das Android-Checkout-SDK,
com.dodopayments.api:checkout-android, das den von Dodo Payments gehosteten Checkout innerhalb deiner App öffnet. Um die Dodo Payments API von deinem Server aufzurufen, verwende stattdessen das Backend-Kotlin-SDK.Checkout Sessions API
Erstelle die
checkout_url, die dieses SDK öffnet.Mobile Integration Guide
Best Practices für mobile Checkout-Abläufe.
androidx.browser.customtabs) und gibt ein typisiertes CheckoutResult zurück, wenn der Kunde den Checkout abschließt oder verlässt. Dein Backend erstellt die Checkout-Session und sendet ihre checkout_url an die App. Das SDK enthält keinen Netzwerkcode und speichert keinen API-Schlüssel. Daher ruft es die Dodo Payments API niemals auf.
Voraussetzungen: minSdk 23, Kotlin und Java 17. Das SDK hängt nur von androidx.activity, androidx.browser und kotlinx-coroutines-android ab.
Installation
1
Add the Dependency
Füge das SDK aus Maven Central zur Darstellung anpassen erfordert Version 1.1.0 oder höher.
build.gradle.kts deines App-Moduls hinzu:build.gradle.kts
2
Register a Callback URL Scheme
Lege dein Callback-Schema als Gradle-Manifest-Platzhalter fest. Das eigene Manifest des SDK definiert den Intent-Filter der Weiterleitungsaktivität mit dem Platzhalter Verwende dasselbe Schema in
${dodoCallbackScheme}. Daher ist diese Eigenschaft der einzige Einrichtungsschritt. Du musst kein Manifest-XML hinzufügen:build.gradle.kts
CheckoutParams.returnUrl, zum Beispiel myapp://checkout/return, und setze dieselbe URL als return_url der Checkout-Session, wenn dein Backend die Session erstellt. Das SDK gleicht die Rückgabe-URL anhand von Schema, Host und Pfad ab und ignoriert die Query-Zeichenfolge. Die URL muss keine echte Seite laden.Wenn du den Platzhalter weglässt, schlägt der Build mit einem Fehler wegen eines nicht aufgelösten Platzhalters fehl. Wenn der Platzhalter nicht mit dem Schema von
returnUrl übereinstimmt, löst das SDK PLATFORM_ERROR aus, bevor es den Checkout öffnet.Verwendung
Das SDK bietet zwei Möglichkeiten, den Checkout zu starten: einen Activity-Result-Launcher und eine Suspend-Funktion. Beide geben dasselbeCheckoutResult zurück.
- Launcher (Recommended)
- Suspend Function
Registriere den Vertrag mit
registerForActivityResult und starte ihn anschließend:Bedeutung des Ergebnisses
Das SDK erstelltCheckoutResult aus den Query-Parametern der Rückgabe-URL.
CheckoutStatus
erforderlich
Einer von fünf Werten:
SUCCEEDED: Die Rückgabe-URL enthältstatus=succeeded(einmalige Zahlung) oderstatus=active(Abonnement).FAILED: Die Zahlung wurde abgelehnt (status=failed).CANCELLED: Der Kunde hat den Custom Tab geschlossen, bevor die Rückgabe-URL eingetroffen ist. Das SDK kennt das Ergebnis nicht, und die Zahlung kann erfolgreich gewesen sein. Zeige daher keinen Fehlerbildschirm an. Gleiche stattdessen die abgebrochene Session ab.PENDING: Die Zahlung wird später abgeschlossen (status=processingoder ein beliebigerrequires_*-Wert), oder der Parameterstatusfehlte oder war unbekannt. Gleiche sie wieCANCELLEDab.EXPIRED: Die Checkout-Session ist abgelaufen (status=expired).
String?
Der Query-Parameter
payment_id, sofern die Rückgabe-URL einen solchen enthält. Zeige ihn in deiner Benutzeroberfläche an, verwende ihn aber nicht zur Gewährung von Zugriff. Siehe Zahlung verifizieren.String?
Der Query-Parameter
subscription_id. Wird für Abonnement-Checkouts gesetzt.List<String>?
Der Query-Parameter
license_key. Wird gesetzt, wenn der Checkout Produkte mit Lizenzschlüsseln enthält.String?
Der Query-Parameter
email. Wird gesetzt, wenn der Checkout eine E-Mail-Adresse erfasst.Map<String, String>
Jeder Query-Parameter aus der Rückgabe-URL, unverändert.
Zahlung verifizieren
Webhooks
Höre in Echtzeit auf Zahlungsereignisse.
Get Payment Detail
Frage den Zahlungsstatus bei Bedarf ab.
payment.succeeded- oder subscription.active-Webhook. Verlasse dich nicht allein auf CheckoutResult.status.
Darstellung anpassen
Um die Symbolleiste, Schaltflächen und das Farbschema des Custom Tabs zu ändern, übergib einBrowserCustomization als customization an CheckoutParams. Jedes Feld ist optional und verwendet standardmäßig null. Bei einem Feld mit dem Wert null setzt das SDK diese Option nicht, sodass der Browser, der den Custom Tab hostet, seinen eigenen Standardwert verwendet.
Int?
Hintergrundfarbe der Symbolleiste als ARGB-Integer
Color.Farbe der Navigationsleiste als ARGB-Integer
Color.Farbe der Trennlinie über der Navigationsleiste als ARGB-Integer
Color.CloseButtonStyle?
DEFAULT zeigt das Systemsymbol „X“. BACK zeigt einen Zurück-Pfeil, den das SDK zeichnet.CloseButtonPosition?
Die Seite der Symbolleiste, auf der die Schaltfläche zum Schließen angezeigt wird:
START oder END.Zeigt das Teilen-Symbol der Symbolleiste an.
false blendet es aus.Boolean?
Zeigt den Seitentitel unter der URL in der Symbolleiste an.
Boolean?
Blendet die Symbolleiste beim Scrollen der Seite automatisch aus.
Boolean?
Zeigt „Diese Seite als Lesezeichen speichern“ im Überlaufmenü an.
Boolean?
Zeigt „Seite herunterladen“ im Überlaufmenü an.
ColorScheme?
LIGHT oder DARK erzwingt diese Darstellung unabhängig von der Systemeinstellung des Geräts. SYSTEM folgt der Systemeinstellung.checkoutLauncher aus Verwendung erneut:
Fehler
DodoCheckout.start löst CheckoutError nur bei falscher Verwendung oder einem Plattformfehler aus. Lies den Grund aus CheckoutError.code ab:
INVALID_CHECKOUT_URL:checkoutUrlist keinehttps-URL einer Checkout-Session (Pfad beginnend mit/session/) aufcheckout.dodopayments.comodertest.checkout.dodopayments.com.INVALID_RETURN_URL:returnUrlist keine absolute URL mit einem Schema und einem Host.ALREADY_IN_PROGRESS: Ein anderer Checkout läuft bereits. Es kann immer nur ein Checkout gleichzeitig ausgeführt werden.PLATFORM_ERROR: Ein unerwarteter Plattformfehler, einschließlich einesreturnUrl-Schemas, das nicht mit deinemdodoCallbackScheme-Platzhalter übereinstimmt.
CANCELLED oder FAILED), niemals ein ausgelöster Fehler. Beim Launcher werden Validierungsfehler aus launcher.launch(...) ausgelöst. Ein Plattformfehler nach dem Start kann nicht über den Activity-Result-Callback ausgelöst werden. Daher gibt der Launcher CANCELLED mit dem Fehlercode in raw["error"] zurück.
Abgebrochene Sessions
Das SDK zeichnet die Checkout-Session beim Start des Checkouts auf und löscht den Eintrag nur, wenn der Checkout mitSUCCEEDED, FAILED oder EXPIRED endet. Der Eintrag bleibt bestehen, wenn die App während des Checkouts beendet wird, sowie nach einem Ergebnis CANCELLED oder PENDING, da das SDK in diesen Fällen das Ergebnis nicht kennt. Suche beim nächsten App-Start und nach jedem Ergebnis CANCELLED oder PENDING danach:
abandoned.sessionId ist die ID der Checkout-Session, die mit cks_ beginnt. abandoned.createdAt ist der Zeitpunkt, zu dem der Checkout gestartet wurde, als Epoch-Zeitstempel in Millisekunden. Dein Backend kann die Session mit Get Checkout Session abrufen. Dieser Aufruf gibt payment_id und payment_status zurück. Bis die Zahlung einen endgültigen Status erreicht, behandle sie als ausstehend und nicht als fehlgeschlagen.
Verwandte Themen
Mobile Integration Guide
Best Practices für mobile Checkout-Abläufe.
Kotlin SDK
Backend-SDK für serverseitige Vorgänge.