Skip to main content

Quick Start

Jalankan integrasi pembayaran seluler Anda dalam 4 langkah sederhana

Platform Examples

Contoh kode lengkap untuk Android, iOS, React Native, dan Flutter

Checkout Customization

Konfigurasikan tema, pre-fill, dan 14 parameter khusus seluler

Mobile Recipes

Konfigurasi checkout siap salin-tempel untuk 5 skenario seluler umum
Dodo Payments menyediakan SDK checkout resmi untuk Android, iOS, React Native, dan Flutter. Masing-masing membungkus pola yang didokumentasikan di bawah ini (buka URL checkout, tangkap hasil pengembalian, lalu parsing hasilnya) di balik satu pemanggilan start(...) bertipe tunggal, dengan pemulihan sesi yang ditinggalkan bawaan. Gunakan WebView manual hanya jika tidak ada yang sesuai dengan stack Anda.

Prasyarat

Sebelum mengintegrasikan Dodo Payments ke aplikasi seluler Anda, pastikan Anda memiliki:
  • Akun Dodo Payments: Akun merchant aktif dengan akses API
  • Kredensial API: API key dan webhook secret key dari dashboard Anda
  • Proyek Aplikasi Seluler: Aplikasi Android, iOS, React Native, atau Flutter
  • Server Backend: Untuk menangani pembuatan sesi checkout secara aman

Alur Integrasi

Integrasi seluler mengikuti proses aman 4 langkah, dengan backend menangani pemanggilan API dan aplikasi seluler mengelola pengalaman pengguna.
Deep link status hanya petunjuk UI tentang apa yang harus ditampilkan kepada pengguna. Selalu berikan akses berdasarkan payment.succeeded / subscription.active webhook di backend Anda - jangan pernah hanya berdasarkan hasil dari aplikasi seluler.
1

Backend: Create Checkout Session

Checkout Session API Docs

Pelajari cara membuat sesi checkout di backend menggunakan Node.js, Python, dan lainnya. Lihat contoh lengkap dan referensi parameter dalam dokumentasi khusus Checkout Sessions API.
Keamanan: Sesi checkout harus dibuat di server backend, bukan di aplikasi seluler. Ini melindungi API key Anda dan memastikan validasi yang tepat.
2

Mobile: Get Checkout URL

Aplikasi seluler Anda memanggil backend untuk mendapatkan URL checkout. Autentikasi permintaan ini dengan token sesi milik pengguna yang sedang login.
Keamanan: Aplikasi seluler hanya berkomunikasi dengan backend Anda, tidak pernah langsung dengan Dodo Payments API.
3

Mobile: Open Checkout in Browser

Buka URL checkout di browser dalam aplikasi yang aman untuk memproses pembayaran. Atau lewati seluruh penyiapan manual dengan SDK checkout resmi untuk platform Anda.

Pick your mobile SDK

Langkah instalasi dan petunjuk penyiapan untuk Android, iOS, React Native, dan Flutter.
4

Backend: Handle Payment Completion

Proses penyelesaian pembayaran melalui webhook dan URL pengalihan untuk mengonfirmasi status pembayaran.

Pilih SDK Anda

Setiap SDK seluler menyediakan kontrak yang sama: satu pemanggilan start(...) membuka checkout ter-host Dodo di permukaan browser native platform dan mengembalikan CheckoutResult bertipe dengan status berupa succeeded, failed, cancelled, pending, atau expired. Tidak ada yang menyimpan API key atau memanggil Dodo Payments API, dan keempatnya mendukung pemulihan sesi yang ditinggalkan.

Android

com.dodopayments.api:checkout-android membuka Chrome Custom Tab. Memerlukan minSdk 23.

iOS

dodopayments-mobile-sdk-ios membuka SFSafariViewController. Memerlukan iOS 16+.

React Native

@dodopayments/react-native-checkout, Turbo Module pada kedua core native. Memerlukan React Native 0.76+.

Flutter

dodopayments_checkout, channel Pigeon pada kedua core native. Memerlukan Flutter 3.44+.
status yang Anda terima adalah petunjuk UI, bukan bukti pembayaran. Konfirmasikan setiap pembayaran dari backend melalui payment.succeeded / subscription.active webhook, atau dengan mengambil pembayaran menggunakan secret key Anda.

Mendaftarkan URL Scheme Callback

Keempat SDK mengembalikan kontrol ke aplikasi Anda melalui custom URL scheme yang Anda pilih, misalnya myapp://checkout/return. Daftarkan sekali untuk setiap platform:
android/app/build.gradle
Manifest SDK sudah mendeklarasikan redirect activity, jadi tidak ada XML manifest yang perlu ditambahkan.
Lebih memilih membuatnya sendiri? Buka checkout_url di browser sistem platform (Android Custom Tabs / iOS SFSafariViewController), lalu cegat navigasi ke return_url dan baca parameter query status serta payment_id. SDK di atas melakukan semua ini untuk Anda.
Jangan buka checkout di dalam embedded WebView (WKWebView / Android WebView). Ini adalah masalah integrasi seluler yang paling umum: embedded WebView menonaktifkan Apple Pay dan Google Pay, serta dapat mengganggu challenge 3-D Secure dan pengisian otomatis kartu tersimpan - sehingga pelanggan melihat lebih sedikit opsi pembayaran dan lebih banyak kegagalan. Selalu gunakan SDK, atau buka checkout_url di browser sistem (Custom Tabs / SFSafariViewController). Permukaan browser native itulah yang membuat Apple Pay dan Google Pay tetap berfungsi.

Kustomisasi Tampilan

Setiap SDK menerima parameter opsional customization pada start(...) / CheckoutParams yang mengontrol tampilan dan perilaku permukaan browser native - toolbar, tombol, dan presentasi. Ini terpisah dari tema halaman checkout itu sendiri, yang Anda konfigurasikan di server melalui customization.theme_config pada checkout session. Opsi dikelompokkan berdasarkan platform karena Android Custom Tab dan iOS SFSafariViewController menyediakan kontrol native yang berbeda. Semua field bersifat opsional; jika customization tidak disertakan sama sekali, tampilan default platform akan digunakan.
Color
Warna latar belakang toolbar.
Color
Warna navigation bar.
Color
Warna pemisah di atas navigation bar.
'default' | 'back'
default menampilkan ikon sistem “X”; back menggambar panah kembali.
'start' | 'end'
Menentukan sisi toolbar tempat tombol tutup muncul.
boolean
Menampilkan ikon bagikan pada toolbar.
boolean
Menampilkan judul halaman di bawah URL pada toolbar.
boolean
Memungkinkan toolbar tersembunyi otomatis saat halaman digulir.
boolean
Menampilkan “Bookmark this page” di menu overflow.
boolean
Menampilkan “Download page” di menu overflow.
'system' | 'light' | 'dark'
Memaksa tampilan terang atau gelap terlepas dari pengaturan sistem perangkat.
'done' | 'close' | 'cancel'
Label atau ikon untuk tombol tutup.
'pageSheet' | 'fullScreen'
pageSheet ditampilkan sebagai kartu dengan swipe-to-dismiss; fullScreen menutupi seluruh layar.
boolean
Memungkinkan toolbar diciutkan saat menggulir. Hanya terlihat ketika presentationStyle adalah fullScreen - pageSheet menjaga bar tetap tertambat terlepas dari pengaturan ini.
'system' | 'light' | 'dark'
Memaksa tampilan terang atau gelap terlepas dari pengaturan sistem perangkat.

Kustomisasi Halaman Checkout

Bagian Kustomisasi Tampilan di atas mengontrol permukaan browser native - toolbar, tombol, dan skema warna. Halaman checkout itu sendiri - field yang ditampilkan, tema, dan metode pembayaran yang muncul - dikonfigurasi di server saat Anda membuat sesi checkout. Parameter ini memberikan dampak terbesar pada konversi seluler. Parameter di bawah berada di tiga tempat berbeda dalam permintaan sesi checkout - kolom Lokasinya memberi tahu Anda objek tempat setiap parameter berada. Kesalahan ini adalah kekeliruan yang paling umum: parameter yang ditempatkan di objek yang salah akan diabaikan secara diam-diam.
Selalu teruskan billing_currency dan billing_address.country secara bersamaan. Jika salah satunya tidak disertakan, Adaptive Currency dapat mengubah mata uang penagihan secara diam-diam berdasarkan alamat IP pelanggan. Seorang merchant melihat subscription AS berubah menjadi EUR saat pelanggannya bepergian ke Eropa - karena negara penagihan tidak ditetapkan secara eksplisit.
Peningkatan konversi tunggal terbesar di seluler: atur show_order_details: false dan minimal_address: true. Memindahkan metode pembayaran ke bagian atas layar dan mengurangi field formulir adalah dua perubahan yang paling berdampak.
Checkout berdampingan: detail pesanan diperluas (field di bawah layar) vs diciutkan (field di bagian atas)

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

Atur minimal_address: true untuk hanya mengumpulkan kode pos, bukan field jalan, kota, dan provinsi lengkap:
Checkout berdampingan: formulir alamat penagihan lengkap vs hanya kode pos

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

Atur theme: "system" agar checkout mengikuti preferensi mode terang atau gelap perangkat:
Checkout berdampingan: halaman yang sama ditampilkan dalam mode terang dan gelap

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

Ketersediaan metode pembayaran bervariasi berdasarkan jenis produk. Apple Pay dan Cash App didukung untuk subscription berulang dengan nilai non-nol. Untuk pembayaran satu kali, semua metode yang diaktifkan tersedia.

Full checkout session parameter reference

Lihat setiap parameter, jenis, dan nilai default yang tersedia dalam panduan Checkout Sessions.

Resep yang Dioptimalkan untuk Seluler

Setiap resep di bawah merupakan body permintaan sesi checkout lengkap. Salin yang sesuai dengan skenario Anda, ganti dengan ID produk Anda, lalu teruskan ke endpoint pembuatan sesi di backend.
Gunakan ini saat Anda menginginkan formulir sesingkat mungkin: metode pembayaran di bagian atas, hanya kode pos yang diperlukan untuk alamat, tanpa field diskon, dan tema yang mengikuti perangkat.
Lihat Checkout Sessions untuk semua parameter yang tersedia dan nilai defaultnya.
Gunakan ini saat halaman checkout harus terasa sebagai bagian dari aplikasi Anda. Atur warna brand, font kustom, dan label tombol bayar yang dilokalkan.
Checkout seluler bermerek dengan palet dark navy kustom yang diterapkan melalui theme_config
theme_config menerima objek dark dan light terpisah agar palet menyesuaikan tampilan perangkat saat ini. Lihat Checkout Sessions untuk referensi lengkap kunci warna.
Gunakan ini untuk pengguna yang login dan pernah membayar sebelumnya. Gabungkan ID pelanggan, metode pembayaran tersimpan mereka, dan confirm: true untuk melewati formulir checkout sepenuhnya.
status dalam pengembalian deep link hanya merupakan petunjuk UI. Konfirmasikan akses dengan mendengarkan webhook payment.succeeded di backend Anda.
Gunakan ini untuk produk subscription yang menawarkan masa uji coba gratis sebelum siklus penagihan pertama.
Berikan akses fitur saat backend menerima webhook subscription.active - bukan saat SDK seluler mengembalikan hasil. Lihat Subscription Integration Guide untuk alur webhook lengkap.
Gunakan ini untuk melakukan tokenisasi kartu pelanggan untuk tagihan di kemudian hari (isi ulang dompet, pay-as-you-go, BNPL) tanpa menampilkan label “subscription”. Pelanggan mengotorisasi metode pembayaran mereka sekali; Anda menagih jumlah variabel secara on-demand di kemudian hari.
Ini adalah pola yang digunakan aplikasi yang menagih berdasarkan penggunaan - misalnya aplikasi astrologi yang menagih per sesi dari kartu yang telah diotorisasi sebelumnya, bukan berdasarkan jadwal tetap.
Tagihan on-demand memerlukan minimum 1 USD (100 sen). Jumlah di bawah 1 USD akan ditolak dengan "value out of range". Untuk otorisasi dengan jumlah nol, gunakan mandate_only: true seperti yang ditunjukkan di atas, lalu tagih setidaknya 1 USD pada pemanggilan berikutnya.
Lihat On-Demand Subscriptions untuk alur penagihan lengkap, event webhook, dan kebijakan percobaan ulang.

Alur Subscription dari Seluler

Subscription dibuat melalui alur sesi checkout yang sama seperti pembayaran satu kali - SDK seluler membuka checkout ter-host, pelanggan berlangganan, dan aplikasi Anda menangani pengembalian deep link. Siklus hidup subscription kemudian dikelola sepenuhnya di backend.

Subscription Berulang Reguler

Untuk penagihan dengan interval tetap (bulanan, tahunan), buat sesi checkout dengan produk subscription dan deep link return_url. Backend Anda menerima subscription.active saat subscription dikonfirmasi.
Apple Pay dan Cash App didukung untuk subscription berulang dengan nilai non-nol.
Untuk alur webhook backend lengkap, lihat Subscription Integration Guide.

Subscription On-Demand

Subscription on-demand memungkinkan Anda mengotorisasi metode pembayaran pelanggan sekali lalu menagih jumlah variabel di kemudian hari - ideal untuk isi ulang dompet, pay-as-you-go, dan skenario apa pun ketika jumlah tagihan belum diketahui sebelumnya. Lihat resep On-Demand Mandate di atas untuk body permintaan lengkap. Pertimbangan seluler utama:
  • Atur show_on_demand_tag: false agar halaman checkout tidak menampilkan bahasa “subscription” atau “on-demand”. Untuk kasus tokenisasi kartu, pelanggan tidak mengharapkan istilah subscription.
  • Setelah mandate diotorisasi, backend Anda menerima subscription.active. Simpan subscription_id - Anda akan menggunakannya untuk semua tagihan berikutnya.
Tagihan minimum adalah 1 USD (100 sen). Tagihan on-demand di bawah 1 USD akan ditolak dengan "value out of range". Tagih setidaknya 1 USD, atau gunakan mandate_only: true untuk mengotorisasi tanpa menagih dan mengumpulkan jumlah pertama yang sebenarnya di kemudian hari.
Hindari percobaan ulang bertubi-tubi. Jika tagihan sebelumnya masih diproses, tagihan baru pada subscription yang sama akan gagal dengan "Cannot create new charge as previous payment is not successful yet". Hal ini terutama umum pada metode pembayaran India (UPI, kartu debit/kredit India), karena aturan mandate RBI dapat menahan transaksi dalam status pemrosesan hingga 48 jam. Tambahkan pemeriksaan cooldown dalam logika penagihan sebelum mencoba lagi.
Lihat On-Demand Subscriptions untuk endpoint penagihan lengkap, event webhook, dan kebijakan percobaan ulang.

Subscription dengan Free Trial

Teruskan subscription_data.trial_period_days dalam sesi checkout untuk menawarkan trial sebelum siklus penagihan pertama. Pelanggan mengotorisasi metode pembayaran mereka saat mendaftar trial; tagihan pertama terjadi otomatis saat trial berakhir. Lihat resep Subscription with Free Trial di atas untuk body permintaan lengkap.

Upgrade dan Downgrade

Perubahan paket dilakukan melalui API di backend Anda, bukan melalui sesi checkout baru. Dodo Payments menghitung prorata secara otomatis. Untuk menyediakan opsi layanan mandiri, sematkan atau tautkan ke Customer Portal.

Subscription Integration Guide

Penyiapan backend lengkap: alur webhook, penyediaan akses, pembatalan

On-Demand Subscriptions

Otorisasi mandate, tagihan variabel, dan kebijakan percobaan ulang

Upgrade / Downgrade

Strategi prorata, perubahan paket, dan penyesuaian seat

Customer Portal

Pengelolaan subscription mandiri untuk pelanggan Anda

Mengurangi Drop-Off Checkout

Checkout seluler mengalami abandonment yang lebih tinggi daripada web - layar yang lebih kecil, lebih banyak gangguan, dan formulir yang lebih panjang semuanya berkontribusi. Perbaikan tercepat berasal dari konfigurasi sesi checkout itu sendiri.

Optimalkan Formulir

Isi Awal Data Pelanggan

Setiap field yang tidak perlu diketik pelanggan adalah alasan untuk tidak membatalkan:
  • Pelanggan baru - atur customer.email dan customer.name dari sesi autentikasi Anda.
  • Pelanggan yang kembali - atur customer.customer_id untuk mengisi otomatis semua detail yang tersimpan.
  • Mata uang - selalu teruskan billing_currency dan billing_address.country secara bersamaan.

Alat Pemulihan

Abandoned Cart Recovery

Urutan email otomatis untuk checkout yang belum selesai

Payment Retries

Logika percobaan ulang cerdas untuk perpanjangan subscription yang gagal

Subscription Dunning

Email re-engagement untuk subscription yang tidak aktif

Recovery Overview

Semua alat pemulihan dan dampak gabungan terhadap pendapatan
Uji email cart abandonment sebelum mengaktifkannya. Buat sesi checkout dalam live mode dan masukkan detail kartu yang tidak valid. Pembayaran yang gagal akan memicu alur email pemulihan, sehingga Anda dapat melihat pratinjau persis seperti yang diterima pelanggan.

Praktik Terbaik

  • Keamanan: Jangan pernah menyertakan API key dalam aplikasi Anda. Buat sesi checkout di backend dan teruskan hanya checkout_url yang dihasilkan ke client.
  • Otoritas: Perlakukan CheckoutResult.status sebagai petunjuk UI. Berikan akses hanya setelah backend mengonfirmasi pembayaran.
  • Pengalaman Pengguna: Tampilkan status loading saat backend membuat sesi, dan tangani cancelled sebagai hasil normal, bukan error.
  • Pengujian: Gunakan test mode dan kartu pengujian, lalu verifikasi round trip return-URL pada perangkat nyata maupun simulator.
  • Konversi: Atur show_order_details: false dan minimal_address: true untuk tingkat penyelesaian checkout seluler terbaik. Memindahkan metode pembayaran ke bagian atas layar dan mengurangi field formulir adalah dua perubahan yang paling berdampak.
  • Mata Uang: Selalu teruskan billing_currency dan billing_address.country secara eksplisit - jika salah satunya tidak ada, Adaptive Currency dapat mengubah mata uang penagihan berdasarkan alamat IP pelanggan.
  • Penagihan on-demand: Atur show_on_demand_tag: false saat menggunakan subscription on-demand untuk tokenisasi kartu. Pelanggan dalam alur isi ulang dompet tidak mengharapkan bahasa “subscription”.
  • Pemulihan: Aktifkan pemulihan cart yang ditinggalkan di dashboard Dodo Payments untuk otomatis menghubungi kembali pelanggan yang tidak menyelesaikan checkout.

Pemecahan Masalah

Masalah Umum

  • Callback tidak pernah tiba: Scheme di returnUrl harus cocok dengan yang Anda daftarkan. Di Android, itu adalah placeholder manifest dodoCallbackScheme; di iOS dan React Native, itu adalah jenis URL Info.plist.
  • Checkout kembali ke browser, bukan ke aplikasi Anda (iOS): Anda belum meneruskan URL masuk. Panggil DodoCheckout.handleOpenURL(url) dari .onOpenURL, scene(_:openURLContexts:), atau listener React Native Linking.
  • PLATFORM_ERROR di Android: Biasanya disebabkan ketidakcocokan scheme. Hal ini juga dapat terjadi jika MainActivity menetapkan android:taskAffinity="" (default bawaan flutter create), yang dapat membuat beberapa build OEM kehilangan checkout yang sedang berlangsung.
  • ALREADY_IN_PROGRESS: Checkout masih terbuka. Tunggu atau tutup checkout sebelumnya sebelum memulai yang baru.
  • Build gagal karena placeholder tidak teratasi: Anda menambahkan Android SDK tetapi belum menetapkan manifestPlaceholders["dodoCallbackScheme"].
  • Pembayaran berhasil tetapi akses tidak diberikan: Ini wajar jika Anda mengandalkan hasil dari perangkat seluler. Berikan akses dari webhook payment.succeeded / subscription.active.
  • Apple Pay / Google Pay tidak muncul di seluler: Checkout dimuat di dalam embedded WebView (WKWebView / Android WebView), yang menonaktifkan wallet dan dapat mengganggu 3-D Secure. Buka menggunakan SDK atau browser sistem (Custom Tabs / SFSafariViewController).

Sumber Daya Tambahan

Untuk pertanyaan atau dukungan, hubungi support@dodopayments.com.
Terakhir diubah pada 21 Agustus 2026