Skip to main content

Quick Start

अपना mobile payment integration 4 आसान steps में शुरू करें

Platform Examples

Android, iOS, React Native और Flutter के लिए complete code examples

Checkout Customization

themes, pre-fill और 14 mobile-specific parameters configure करें

Mobile Recipes

5 सामान्य mobile scenarios के लिए copy-paste checkout configs
Dodo Payments Android, iOS, React Native, और Flutter के लिए official checkout SDK उपलब्ध कराता है। इनमें से हर SDK नीचे दिए गए pattern (checkout URL खोलना, return को capture करना, result को parse करना) को एक single typed start(...) call के पीछे wrap करता है और abandoned-session recovery built in होती है। Manual WebView का उपयोग केवल तभी करें जब इनमें से कोई भी आपके stack के लिए उपयुक्त न हो।

आवश्यकताएँ

अपने mobile app में Dodo Payments को integrate करने से पहले सुनिश्चित करें कि आपके पास ये हैं:
  • Dodo Payments Account: API access वाला active merchant account
  • API Credentials: आपके dashboard से API key और webhook secret key
  • Mobile App Project: Android, iOS, React Native या Flutter application
  • Backend Server: checkout session creation को securely handle करने के लिए

Integration Workflow

Mobile integration एक secure 4-step process का पालन करता है, जिसमें आपका backend API calls handle करता है और आपका mobile app user experience manage करता है।
Deep-link status user को क्या दिखाना है, इसका केवल UI hint है। Access हमेशा अपने backend पर payment.succeeded / subscription.active webhook से grant करें — केवल mobile result के आधार पर कभी नहीं।
1

Backend: Create Checkout Session

Checkout Session API Docs

Node.js, Python और अन्य भाषाओं का उपयोग करके अपने backend में checkout session बनाना सीखें। Dedicated Checkout Sessions API documentation में complete examples और parameter references देखें।
Security: Checkout sessions आपके backend server पर ही बनाए जाने चाहिए, mobile app में कभी नहीं। इससे आपकी API keys सुरक्षित रहती हैं और proper validation सुनिश्चित होता है।
2

Mobile: Get Checkout URL

आपका mobile app checkout URL प्राप्त करने के लिए आपके backend को call करता है। इस request को signed-in user के अपने session token से authenticate करें।
Security: Mobile apps केवल आपके backend से communicate करते हैं, Dodo Payments API से सीधे कभी नहीं।
3

Mobile: Open Checkout in Browser

Payment processing के लिए checkout URL को secure in-app browser में खोलें। या अपने platform के लिए official checkout SDK का उपयोग करके manual setup पूरी तरह छोड़ दें।

Pick your mobile SDK

Android, iOS, React Native और Flutter के लिए installation steps और setup instructions।
4

Backend: Handle Payment Completion

Payment status की पुष्टि करने के लिए webhooks और redirect URLs के माध्यम से payment completion process करें।

अपना SDK चुनें

हर mobile SDK एक ही contract expose करता है: एक start(...) call Dodo के hosted checkout को platform के native browser surface में खोलता है और एक typed CheckoutResult लौटाता है, जिसका status succeeded, failed, cancelled, pending या expired होता है। इनमें से कोई भी API key store नहीं करता या Dodo Payments API को call नहीं करता, और सभी चार abandoned-session recovery support करते हैं।

Android

com.dodopayments.api:checkout-android एक Chrome Custom Tab खोलता है। इसके लिए minSdk 23 आवश्यक है।

iOS

dodopayments-mobile-sdk-ios, SFSafariViewController खोलता है। इसके लिए iOS 16+ आवश्यक है।

React Native

@dodopayments/react-native-checkout, दोनों native cores पर एक Turbo Module। इसके लिए React Native 0.76+ आवश्यक है।

Flutter

dodopayments_checkout, दोनों native cores पर एक Pigeon channel। इसके लिए Flutter 3.44+ आवश्यक है।
आपको वापस मिलने वाला status payment का प्रमाण नहीं, बल्कि केवल UI hint है। हर payment की पुष्टि अपने backend से payment.succeeded / subscription.active webhook के माध्यम से करें, या अपनी secret key से payment retrieve करें।

Callback URL Scheme register करना

सभी चार SDK आपके चुने हुए custom URL scheme के माध्यम से control वापस आपके app को देते हैं, उदाहरण के लिए myapp://checkout/return। इसे प्रत्येक platform पर एक बार register करें:
android/app/build.gradle
SDK का अपना manifest redirect activity पहले से declare करता है, इसलिए जोड़ने के लिए कोई manifest XML नहीं है।
इसे स्वयं build करना पसंद करेंगे? checkout_url को platform के system browser (Android Custom Tabs / iOS SFSafariViewController) में खोलें और navigation को अपने return_url पर intercept करें, फिर status और payment_id query parameters पढ़ें। ऊपर दिए गए SDK आपके लिए यही काम करते हैं।
Checkout को embedded WebView (WKWebView / Android WebView) के अंदर न खोलें। यह mobile integration की सबसे सामान्य समस्या है: embedded WebView Apple Pay और Google Pay को suppress करता है, और 3-D Secure challenges तथा saved-card autofill को भी तोड़ सकता है - जिससे customers को payment options कम दिखाई देते हैं और failures बढ़ते हैं। हमेशा SDK का उपयोग करें या checkout_url को system browser (Custom Tabs / SFSafariViewController) में खोलें। यही native browser surface Apple Pay और Google Pay को काम करते रहने देता है।

Appearance Customization

हर SDK start(...) / CheckoutParams पर एक optional customization parameter स्वीकार करता है, जो native browser surface के appearance और behavior - toolbar, buttons और presentation - को control करता है। यह checkout page की अपनी theme से अलग है, जिसे आप checkout session पर customization.theme_config के माध्यम से server-side configure करते हैं। Options को platform के अनुसार group किया गया है, क्योंकि Android का Custom Tab और iOS का SFSafariViewController अलग-अलग native controls expose करते हैं। सभी fields optional हैं; customization को पूरी तरह omit करने पर प्रत्येक platform का default appearance उपयोग होता है।
Color
Toolbar का background color।
Color
Navigation bar का color।
Color
Navigation bar के ऊपर divider का color।
'default' | 'back'
default system का “X” icon दिखाता है; back इसके बजाय back arrow draw करता है।
'start' | 'end'
Toolbar में close button किस side पर दिखाई देता है।
boolean
Toolbar का share icon दिखाता है।
boolean
Toolbar में URL के नीचे page title दिखाता है।
boolean
Page scroll होने पर toolbar को auto-hide होने देता है।
boolean
Overflow menu में “Bookmark this page” दिखाता है।
boolean
Overflow menu में “Download page” दिखाता है।
'system' | 'light' | 'dark'
Device की system setting की परवाह किए बिना light या dark appearance लागू करता है।
'done' | 'close' | 'cancel'
Dismiss button के लिए label या icon।
'pageSheet' | 'fullScreen'
pageSheet swipe-to-dismiss वाले card के रूप में प्रस्तुत होता है; fullScreen पूरी screen को cover करता है।
boolean
Scroll करने पर toolbar को collapse होने देता है। यह केवल तब visible होता है जब presentationStyle fullScreen हो - pageSheet इस setting की परवाह किए बिना bars को pinned रखता है।
'system' | 'light' | 'dark'
Device की system setting की परवाह किए बिना light या dark appearance लागू करता है।

Checkout Page Customization

ऊपर का Appearance Customization section native browser surface - toolbar, buttons और color scheme - को control करता है। checkout page स्वयं - कौन से fields दिखाई दें, theme और कौन से payment methods दिखें - checkout session बनाते समय server-side configure किया जाता है। इन parameters का mobile conversion पर सबसे अधिक प्रभाव पड़ता है। नीचे दिए गए parameters checkout session request में तीन अलग-अलग स्थानों पर होते हैं - Where it goes column बताता है कि प्रत्येक parameter किस object में होना चाहिए। इसे गलत रखना सबसे सामान्य गलती है: गलत object में रखा गया parameter silently ignore हो जाता है।
billing_currency और billing_address.country को हमेशा साथ pass करें। यदि इनमें से कोई एक omit किया जाता है, तो adaptive currency customer के IP address के आधार पर billing currency को silently बदल सकती है। एक merchant ने देखा कि उसके customer के Europe यात्रा करने पर US subscription EUR में बदल गया - क्योंकि billing country explicitly set नहीं किया गया था।
Mobile पर conversion बढ़ाने वाला सबसे बड़ा single improvement: show_order_details: false और minimal_address: true set करें। Payment methods को above the fold ले जाना और form fields कम करना, आपके द्वारा किए जा सकने वाले दो सबसे प्रभावी बदलाव हैं।
Side-by-side checkout: order details expanded (fields below the fold) vs collapsed (fields at the top)

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

Full street, city और state fields के बजाय केवल postcode collect करने के लिए minimal_address: true set करें:
Side-by-side checkout: full billing address form vs postcode-only

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

Checkout को device की light या dark mode preference का पालन कराने के लिए theme: "system" set करें:
Side-by-side checkout: same page rendered in light mode and dark mode

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

Payment method availability product type के अनुसार अलग होती है। Apple Pay और Cash App non-zero recurring subscriptions के लिए supported हैं। One-time payments के लिए सभी enabled methods उपलब्ध हैं।

Full checkout session parameter reference

Checkout Sessions guide में हर available parameter, type और default value देखें।

Mobile-Optimized Recipes

नीचे दिया गया प्रत्येक recipe एक complete checkout session request body है। अपने scenario से मेल खाने वाला recipe copy करें, उसमें अपना product ID डालें और उसे अपने backend के session-creation endpoint पर pass करें।
जब आपको सबसे छोटा संभव form चाहिए, तब इसका उपयोग करें: ऊपर payment methods, address के लिए केवल postcode आवश्यक, discount field नहीं और theme device से match करती है।
सभी available parameters और उनके defaults के लिए Checkout Sessions देखें।
जब checkout page को आपके app का हिस्सा जैसा महसूस होना चाहिए, तब इसका उपयोग करें। अपने brand colors, custom font और localized pay-button label set करें।
Branded mobile checkout with a custom dark navy palette applied via theme_config
theme_config अलग-अलग dark और light objects स्वीकार करता है, ताकि palette device के current appearance के अनुसार adapt हो सके। पूर्ण color key reference के लिए Checkout Sessions देखें।
पहले payment कर चुके signed-in users के लिए इसका उपयोग करें। Checkout form को पूरी तरह skip करने के लिए customer ID, उनका saved payment method और confirm: true combine करें।
Deep-link return में status केवल UI hint है। अपने backend पर payment.succeeded webhook सुनकर access की पुष्टि करें।
Subscription products के लिए इसका उपयोग करें जो पहले billing cycle से पहले free trial period offer करते हैं।
जब आपके backend को subscription.active webhook प्राप्त हो, तब feature access grant करें - mobile SDK के return पर नहीं। पूरे webhook flow के लिए Subscription Integration Guide देखें।
Customer के card को बाद के charges (wallet top-ups, pay-as-you-go, BNPL) के लिए tokenize करने हेतु इसका उपयोग करें, बिना “subscription” label दिखाए। Customer अपने payment method को एक बार authorize करता है; बाद में आप variable amounts को on demand charge करते हैं।
यह pattern usage के आधार पर charge करने वाले apps में उपयोग होता है - उदाहरण के लिए, एक astrology app जो fixed schedule के बजाय pre-authorized card से प्रति session charge करता है।
On-demand charges के लिए कम से कम 1 USD (100 cents) आवश्यक है। 1 USD से कम amounts को "value out of range" के साथ reject कर दिया जाएगा। Zero-amount authorization के लिए ऊपर दिखाए गए अनुसार mandate_only: true का उपयोग करें, फिर बाद की calls में कम से कम 1 USD charge करें।
Complete charge flow, webhook events और retry policies के लिए On-Demand Subscriptions देखें।

Mobile से Subscription Flows

Subscriptions उसी checkout session flow के माध्यम से बनाई जाती हैं जिसका उपयोग one-time payments के लिए होता है - mobile SDK hosted checkout खोलता है, customer subscribe करता है और आपका app deep-link return handle करता है। इसके बाद subscription lifecycle पूरी तरह backend पर manage किया जाता है।

Regular Recurring Subscriptions

Fixed-interval billing (monthly, annual) के लिए subscription product और deep-link return_url के साथ checkout session बनाएँ। Subscription confirm होने पर आपका backend subscription.active प्राप्त करता है।
Apple Pay और Cash App, non-zero recurring subscriptions के लिए supported हैं।
Complete backend webhook flow के लिए Subscription Integration Guide देखें।

On-Demand Subscriptions

On-demand subscriptions customer के payment method को एक बार authorize करके बाद में variable amounts charge करने देती हैं - wallet top-ups, pay-as-you-go और उन सभी scenarios के लिए आदर्श जहाँ charge amount पहले से ज्ञात नहीं होता। Complete request body के लिए ऊपर दिया गया On-Demand Mandate recipe देखें। मुख्य mobile considerations:
  • show_on_demand_tag: false set करें ताकि checkout page पर “subscription” या “on-demand” language दिखाई न दे। Card-tokenization use cases में customers subscription terminology की अपेक्षा नहीं करते।
  • Mandate authorize होने के बाद आपका backend subscription.active प्राप्त करता है। subscription_id store करें - सभी future charges के लिए इसका उपयोग होगा।
Minimum charge 1 USD (100 cents) है। 1 USD से कम के on-demand charges को "value out of range" के साथ reject कर दिया जाएगा। कम से कम 1 USD charge करें, या बिना charge किए authorize करने के लिए mandate_only: true का उपयोग करें और बाद में पहली वास्तविक amount collect करें।
Rapid-fire retries से बचें। यदि पिछला charge अभी भी processing में है, तो उसी subscription पर नया charge "Cannot create new charge as previous payment is not successful yet" के साथ fail हो जाता है। यह Indian payment methods (UPI, Indian debit/credit cards) के साथ विशेष रूप से सामान्य है, जहाँ RBI mandate rules किसी transaction को 48 घंटे तक processing state में रख सकते हैं। Retry करने से पहले अपने charge logic में cooldown check जोड़ें।
Complete charge endpoint, webhook events और retry policies के लिए On-Demand Subscriptions देखें।

Subscription with Free Trial

पहले billing cycle से पहले trial offer करने के लिए checkout session में subscription_data.trial_period_days pass करें। Customer trial signup के दौरान अपने payment method को authorize करता है; trial समाप्त होने पर पहला charge automatically होता है। Complete request body के लिए ऊपर दिया गया Subscription with Free Trial recipe देखें।

Upgrades और Downgrades

Plan changes आपके backend पर API के माध्यम से किए जाते हैं, किसी नए checkout session के माध्यम से नहीं। Dodo Payments proration automatically calculate करता है। Customers को self-service option देने के लिए Customer Portal embed करें या उसका link दें।

Subscription Integration Guide

Complete backend setup: webhook flow, access provisioning, cancellation

On-Demand Subscriptions

Mandate authorization, variable charges और retry policies

Upgrade / Downgrade

Proration strategies, plan changes और seat adjustments

Customer Portal

आपके customers के लिए self-service subscription management

Checkout Drop-Offs कम करना

Mobile checkouts में web की तुलना में abandonment अधिक होता है - छोटी screens, अधिक distractions और लंबे forms सभी इसमें योगदान देते हैं। सबसे तेज improvements checkout session configuration से ही मिलते हैं।

Form को Optimize करें

Customer Data Pre-Fill करें

Customer को जो field type नहीं करनी पड़ती, वह checkout abandon न करने का एक कारण है:
  • New customers - अपनी auth session से customer.email और customer.name set करें।
  • Returning customers - सभी stored details automatically pre-fill करने के लिए customer.customer_id set करें।
  • Currency - billing_currency और billing_address.country को हमेशा साथ pass करें।

Recovery Tools

Abandoned Cart Recovery

Incomplete checkouts के लिए automated email sequences

Payment Retries

Failed subscription renewals के लिए smart retry logic

Subscription Dunning

Lapsed subscriptions के लिए re-engagement emails

Recovery Overview

सभी recovery tools और उनका combined revenue impact
Cart abandonment emails को enable करने से पहले test करें। Live mode में checkout session बनाएँ और invalid card details enter करें। Failed payment recovery email flow trigger करेगा, जिससे आप ठीक वही preview कर सकेंगे जो आपके customers को प्राप्त होगा।

Best Practices

  • Security: अपने app में API key कभी ship न करें। Checkout sessions अपने backend पर बनाएँ और केवल resulting checkout_url client को pass करें।
  • Authority: CheckoutResult.status को UI hint मानें। Access केवल backend द्वारा payment confirm करने के बाद grant करें।
  • User Experience: Backend द्वारा session create किए जाने तक loading state दिखाएँ और cancelled को error के बजाय normal outcome के रूप में handle करें।
  • Testing: Test mode और test cards का उपयोग करें और real device तथा simulator दोनों पर return-URL round trip verify करें।
  • Conversion: Best mobile checkout completion rates के लिए show_order_details: false और minimal_address: true set करें। Payment methods को above the fold ले जाना और form fields कम करना, आपके द्वारा किए जा सकने वाले दो सबसे प्रभावी बदलाव हैं।
  • Currency: billing_currency और billing_address.country दोनों को हमेशा explicitly pass करें - इनमें से कोई missing होने पर adaptive currency customer के IP address के आधार पर billing currency बदल सकती है।
  • On-demand billing: Card tokenization के लिए on-demand subscriptions का उपयोग करते समय show_on_demand_tag: false set करें। Wallet top-up flow का उपयोग करने वाले customers “subscription” language देखने की अपेक्षा नहीं करते।
  • Recovery: Checkout पूरा न करने वाले customers को automatically re-engage करने के लिए अपने Dodo Payments dashboard में abandoned cart recovery enable करें।

Troubleshooting

सामान्य समस्याएँ

  • Callback कभी नहीं आता: returnUrl में scheme आपके registered scheme से match होना चाहिए। Android पर यह dodoCallbackScheme manifest placeholder है; iOS और React Native पर यह Info.plist URL type है।
  • Checkout आपके app के बजाय browser पर लौटता है (iOS): आपने incoming URL forward नहीं किया है। .onOpenURL, scene(_:openURLContexts:) या React Native Linking listener से DodoCheckout.handleOpenURL(url) call करें।
  • Android पर PLATFORM_ERROR: अधिकतर मामलों में यह scheme mismatch होता है। यह तब भी दिखाई दे सकता है जब आपका MainActivity android:taskAffinity="" set करता है (stock flutter create default), जिससे कुछ OEM builds in-flight checkout खो सकते हैं।
  • ALREADY_IN_PROGRESS: एक checkout अभी भी open है। दूसरा शुरू करने से पहले पिछले checkout का await या dismiss करें।
  • Unresolved placeholder के कारण build fail होता है: आपने Android SDK add किया, लेकिन manifestPlaceholders["dodoCallbackScheme"] set नहीं किया।
  • Payment सफल हुआ लेकिन access grant नहीं हुआ: यदि आप mobile result पर निर्भर हैं तो यह expected है। इसके बजाय payment.succeeded / subscription.active webhook से access grant करें।
  • Mobile पर Apple Pay / Google Pay दिखाई नहीं देते: Checkout embedded WebView (WKWebView / Android WebView) में load हो रहा है, जो wallets को suppress करता है और 3-D Secure को तोड़ सकता है। इसके बजाय SDK से या system browser (Custom Tabs / SFSafariViewController) में खोलें।

अतिरिक्त Resources

Questions या support के लिए support@dodopayments.com से contact करें।
अंतिम संशोधन 21 अगस्त 2026