Skip to main content
यह पेज Android checkout SDK, com.dodopayments.api:checkout-android, को कवर करता है, जो आपके app के अंदर Dodo Payments hosted checkout खोलता है। अपने server से Dodo Payments API को call करने के लिए इसके बजाय backend Kotlin SDK का उपयोग करें।

Checkout Sessions API

वह checkout_url बनाएं जिसे यह SDK खोलता है।

Mobile Integration Guide

mobile checkout flows के लिए best practices।
Android SDK Dodo Payments hosted checkout को Custom Tab (androidx.browser.customtabs) में खोलता है और customer के checkout पूरा करने या छोड़ने पर typed CheckoutResult लौटाता है। आपका backend checkout session बनाता है और उसका checkout_url app को भेजता है। SDK में networking code नहीं है और यह कोई API key नहीं रखता, इसलिए यह कभी भी Dodo Payments API को call नहीं करता। आवश्यकताएं: minSdk 23, Kotlin और Java 17। SDK केवल androidx.activity, androidx.browser और kotlinx-coroutines-android पर निर्भर करता है।

Installation

1

Add the Dependency

Maven Central से SDK को अपने app module के build.gradle.kts में जोड़ें:
build.gradle.kts
Appearance customization के लिए version 1.1.0 या बाद का version आवश्यक है।
2

Register a Callback URL Scheme

अपने callback scheme को Gradle manifest placeholder के रूप में सेट करें। SDK का अपना manifest redirect activity के intent filter को ${dodoCallbackScheme} placeholder के साथ declare करता है, इसलिए यह property ही एकमात्र setup step है। आपको कोई manifest XML जोड़ने की आवश्यकता नहीं है:
build.gradle.kts
CheckoutParams.returnUrl में वही scheme उपयोग करें, उदाहरण के लिए myapp://checkout/return, और backend द्वारा session बनाते समय checkout session के return_url के रूप में वही URL सेट करें। SDK return URL का मिलान scheme, host और path के आधार पर करता है और query string को अनदेखा करता है। URL का किसी वास्तविक page को load करना आवश्यक नहीं है।
यदि आप placeholder छोड़ देते हैं, तो unresolved-placeholder error के साथ build विफल हो जाता है। यदि placeholder, returnUrl के scheme से मेल नहीं खाता, तो SDK checkout खोलने से पहले PLATFORM_ERROR throw करता है।

उपयोग

SDK में checkout शुरू करने के दो तरीके हैं: activity result launcher और suspend function। दोनों समान CheckoutResult लौटाते हैं।

Result का अर्थ

SDK return URL के query parameters से CheckoutResult बनाता है।
status field एक UI hint है, payment का प्रमाण नहीं। Access देने से पहले webhook या Get Payment Detail endpoint के माध्यम से अपने backend पर payment की पुष्टि करें।
CheckoutStatus
आवश्यक
पांच values में से एक:
  • SUCCEEDED: return URL में status=succeeded (one-time payment) या status=active (subscription) है।
  • FAILED: payment अस्वीकार कर दिया गया (status=failed)।
  • CANCELLED: return URL आने से पहले customer ने Custom Tab बंद कर दिया। SDK को outcome पता नहीं है और payment सफल हो सकता है, इसलिए failure screen न दिखाएं। इसके बजाय abandoned session को reconcile करें।
  • PENDING: payment बाद में settle होता है (status=processing या कोई भी requires_* value), या status parameter missing या unrecognized था। इसे CANCELLED की तरह reconcile करें।
  • EXPIRED: checkout session expire हो गया (status=expired)।
String?
payment_id query parameter, जब return URL में यह शामिल हो। इसे अपने UI में दिखाएं, लेकिन access देने के लिए इसका उपयोग न करें। Verify the Payment देखें।
String?
subscription_id query parameter। Subscription checkouts के लिए सेट होता है।
List<String>?
license_key query parameter। Checkout में license key products शामिल होने पर सेट होता है।
String?
email query parameter। Checkout द्वारा email address capture करने पर सेट होता है।
Map<String, String>
Return URL का प्रत्येक query parameter, verbatim।

Payment सत्यापित करें

Webhooks

Payment events को real time में listen करें।

Get Payment Detail

मांग पर payment status query करें।
Access तभी दें जब इनमें से कोई एक payment की पुष्टि करे, उदाहरण के लिए payment.succeeded या subscription.active webhook के माध्यम से। केवल CheckoutResult.status पर निर्भर न रहें।

Appearance Customization

Custom Tab के toolbar, buttons और color scheme को बदलने के लिए, CheckoutParams पर customization के रूप में BrowserCustomization pass करें। प्रत्येक field optional है और इसका default null होता है। null field के लिए SDK वह option सेट नहीं करता, इसलिए Custom Tab को host करने वाला browser अपना default लागू करता है।
Int?
Toolbar का background color, ARGB Color int के रूप में।
Int?
Navigation bar का color, ARGB Color int के रूप में।
Int?
Navigation bar के ऊपर divider का color, ARGB Color int के रूप में।
CloseButtonStyle?
DEFAULT system का “X” icon दिखाता है। BACK SDK द्वारा बनाया गया back arrow दिखाता है।
CloseButtonPosition?
Toolbar का वह side जहां close button दिखाई देता है: START या END।
Boolean?
Toolbar का share icon दिखाता है। false इसे छिपाता है।
Boolean?
Toolbar में URL के नीचे page title दिखाता है।
Boolean?
Page scroll होने पर toolbar को अपने-आप छिपाता है।
Boolean?
Overflow menu में “Bookmark this page” दिखाता है।
Boolean?
Overflow menu में “Download page” दिखाता है।
ColorScheme?
LIGHT या DARK device की system setting की परवाह किए बिना उस appearance को force करता है। SYSTEM system setting का अनुसरण करता है।
यह example Usage से checkoutLauncher का पुनः उपयोग करता है:

Errors

DodoCheckout.start केवल misuse या platform failure के लिए CheckoutError throw करता है। कारण CheckoutError.code से पढ़ें:
  • INVALID_CHECKOUT_URL: checkoutUrl कोई https checkout session URL नहीं है (/session/ से शुरू होने वाला path), जो checkout.dodopayments.com या test.checkout.dodopayments.com पर हो।
  • INVALID_RETURN_URL: returnUrl scheme और host वाला absolute URL नहीं है।
  • ALREADY_IN_PROGRESS: कोई अन्य checkout चल रहा है। एक समय में केवल एक checkout चल सकता है।
  • PLATFORM_ERROR: unexpected platform failure, जिसमें ऐसा returnUrl scheme भी शामिल है जो आपके dodoCallbackScheme placeholder से मेल नहीं खाता।
जो customer cancel करता है या जिसका payment decline होता है, वह हमेशा result (CANCELLED या FAILED) होता है, thrown error कभी नहीं। Launcher के साथ validation errors launcher.launch(...) से throw होते हैं। Launch के बाद platform failure को activity result callback के माध्यम से throw नहीं किया जा सकता, इसलिए launcher CANCELLED लौटाता है और error code raw["error"] में देता है।

Abandoned Sessions

Checkout शुरू होने पर SDK checkout session को record करता है और record को केवल तब clear करता है जब checkout SUCCEEDED, FAILED या EXPIRED के साथ समाप्त होता है। Checkout के दौरान app बंद होने पर record बना रहता है, और CANCELLED या PENDING result के बाद भी बना रहता है, क्योंकि इन मामलों में SDK को outcome पता नहीं होता। अगली app launch पर और प्रत्येक CANCELLED या PENDING result के बाद इसकी जांच करें:
abandoned.sessionId checkout session ID है, जो cks_ से शुरू होती है। abandoned.createdAt checkout शुरू होने का समय है, epoch timestamp in milliseconds के रूप में। आपका backend Get Checkout Session के माध्यम से session lookup कर सकता है, जो उसका payment_id और payment_status लौटाता है। जब तक payment final status तक नहीं पहुंचता, इसे failed नहीं बल्कि pending मानें।

संबंधित

Mobile Integration Guide

mobile checkout flows के लिए best practices।

Kotlin SDK

server-side operations के लिए Backend SDK।
अंतिम संशोधन 26 सितंबर 2026