Skip to main content

Prasyarat

Sebelum memulai, Anda memerlukan:
  • Akun merchant Dodo Payments
  • API key dari Developer → API Keys di dashboard, disimpan di DODO_PAYMENTS_API_KEY
  • Secret webhook dari Developer → Webhooks, disimpan di DODO_PAYMENTS_WEBHOOK_KEY
  • Setidaknya satu produk subscription yang dibuat di Products
Untuk informasi selengkapnya, lihat Prasyarat Panduan Integrasi.

Integrasi API

Checkout Sessions

Buat subscription dengan membangun checkout session menggunakan produk subscription Anda. Pelanggan mengotorisasi metode pembayaran dan subscription aktif setelah mereka menyelesaikan checkout.
Anda dapat menggabungkan produk subscription dengan produk satu kali dalam checkout session yang sama. Hal ini memungkinkan biaya setup, bundel hardware dengan SaaS, dan kasus penggunaan serupa. Lihat Checkout Sessions untuk contoh.

Respons API

Respons mencakup checkout_url:
Arahkan pelanggan ke URL ini. Mereka mengotorisasi metode pembayaran dan subscription menjadi aktif.

Webhook

Webhook memberi tahu server Anda saat peristiwa subscription terjadi. Siapkan endpoint Anda di Developer → Webhooks pada dashboard. Untuk menyiapkan endpoint webhook, lihat Webhook.

Jenis Peristiwa Subscription

Pantau peristiwa berikut untuk mengelola siklus hidup subscription:
  1. subscription.active — Subscription diaktifkan
  2. subscription.updated — Sebuah field pada subscription berubah
  3. subscription.on_hold — Tagihan renewal atau perubahan plan gagal
  4. subscription.failed — Pembuatan subscription gagal (terminal; pelanggan harus berlangganan kembali)
  5. subscription.renewed — Tagihan berkala berhasil
  6. subscription.past_due — Renewal gagal dan masa tenggang dimulai; pelanggan tetap memiliki akses hingga past_due_ends_at
  7. subscription.plan_changed — Plan ditingkatkan, diturunkan, atau diubah
  8. subscription.cancelled — Subscription dibatalkan
  9. subscription.expired — Subscription mencapai akhir masa berlakunya
Ini adalah peristiwa inti. Untuk daftar lengkap, termasuk paused, unpaused, dan update_payment_method, lihat Webhook Subscription.
Gunakan subscription.updated untuk mendapatkan notifikasi real-time tentang setiap perubahan subscription, sehingga status aplikasi Anda tetap sinkron tanpa melakukan polling API.

Skenario Pembayaran

Alur Pembayaran Berhasil Urutan webhook bergantung pada apakah subscription memiliki trial. Penagihan langsung (0 hari trial):
  1. subscription.active: mandat diotorisasi dan subscription diaktifkan.
  2. payment.succeeded: mengonfirmasi tagihan pertama. Peristiwa ini biasanya diterima dalam 2–10 menit setelah checkout.
Dengan periode trial:
  1. Saat trial dimulai (checkout): subscription.active dipicu setelah metode pembayaran diotorisasi. Belum ada tagihan berkala yang diambil. Tagihan pertama ditunda hingga trial berakhir.
  2. Saat trial berakhir: jumlah berkala ditagihkan, dan Anda menerima payment.succeeded bersama dengan subscription.renewed.
Setiap renewal berikutnya:
  • subscription.renewed: dipicu pada setiap siklus penagihan saat pembayaran renewal dipotong, selalu bersama payment.succeeded. Peristiwa ini juga membawa next_billing_date yang telah diperbarui.
Setiap kali uang benar-benar dipotong untuk produk subscription, Anda menerima subscription.renewed dan payment.succeeded. Gunakan subscription.renewed (bukan hanya payment.succeeded) sebagai sinyal untuk memperpanjang akses ke siklus berikutnya.
Skenario Kegagalan Pembayaran
  1. Kegagalan Subscription
  • subscription.failed - Pembuatan subscription gagal karena mandat tidak berhasil dibuat.
  • payment.failed - Menunjukkan pembayaran gagal.
  1. Subscription Ditangguhkan
  • subscription.on_hold - Subscription ditangguhkan karena pembayaran renewal atau tagihan perubahan plan gagal. Jika bisnis Anda memiliki masa tenggang, renewal yang gagal terlebih dahulu memindahkan subscription ke past_due (subscription.past_due), lalu memindahkannya ke on_hold (atau cancelled, bergantung pada pengaturan masa tenggang) hanya setelah masa tenggang berakhir. Lihat Status Subscription.
  • Saat subscription ditangguhkan, subscription tidak akan diperbarui secara otomatis hingga metode pembayaran diperbarui.
Praktik Terbaik: Untuk menyederhanakan implementasi, kami menyarankan agar Anda terutama memantau peristiwa subscription untuk mengelola siklus hidup subscription.
Untuk panduan lengkap tentang cara membaca error_code/error_message, menentukan kapan harus mencoba kembali, dan menampilkan kegagalan kepada pelanggan, lihat Menangani Kegagalan Pembayaran.

subscription.failed vs. subscription.on_hold

Kedua peristiwa ini mudah tertukar, tetapi memerlukan penanganan yang sangat berbeda:
subscription.failed bersifat terminal. Subscription tidak dapat diaktifkan kembali. Pelanggan harus membuat subscription baru. Jangan pernah memberikan entitlement saat peristiwa ini dipicu.

Menangani Subscription yang Ditangguhkan

Saat subscription memasuki status on_hold, Anda perlu memperbarui metode pembayaran untuk mengaktifkannya kembali. Bagian ini menjelaskan kapan subscription ditangguhkan dan cara menanganinya.

Kapan Subscription Ditangguhkan

Subscription ditangguhkan ketika:
  • Pembayaran renewal gagal: Tagihan renewal otomatis gagal karena dana tidak mencukupi, kartu kedaluwarsa, atau penolakan bank
  • Tagihan perubahan plan gagal: Tagihan langsung saat upgrade/downgrade plan gagal
  • Otorisasi metode pembayaran gagal: Metode pembayaran tidak dapat diotorisasi untuk tagihan berkala
Subscription dalam status on_hold tidak akan diperbarui secara otomatis. Anda harus memperbarui metode pembayaran untuk mengaktifkan kembali subscription.

Mengaktifkan Kembali Subscription yang Ditangguhkan

Untuk mengaktifkan kembali subscription dari status on_hold, gunakan API Update Payment Method. API ini secara otomatis:
  1. Membuat tagihan untuk kewajiban yang tersisa
  2. Membuat invoice untuk tagihan tersebut
  3. Memproses pembayaran menggunakan metode pembayaran baru
  4. Mengaktifkan kembali subscription ke status active setelah pembayaran berhasil
1

Handle subscription.on_hold webhook

Saat menerima webhook subscription.on_hold, perbarui status aplikasi Anda dan beri tahu pelanggan:
2

Update payment method

Saat pelanggan siap memperbarui metode pembayaran, panggil API Update Payment Method:
Anda juga dapat menggunakan ID metode pembayaran yang sudah ada jika pelanggan menyimpan metode pembayaran:
3

Monitor webhook events

Setelah memperbarui metode pembayaran, pantau peristiwa webhook berikut:
  1. payment.succeeded - Tagihan untuk kewajiban yang tersisa berhasil
  2. subscription.active - Subscription telah diaktifkan kembali

Contoh Payload Peristiwa Subscription


Mengubah Plan Subscription

Anda dapat meng-upgrade atau men-downgrade plan subscription menggunakan endpoint API change plan. Endpoint ini memungkinkan Anda mengubah produk, kuantitas, dan menangani proration pada subscription.

Change Plan API Reference

Untuk informasi terperinci tentang perubahan plan subscription, lihat dokumentasi Change Plan API kami.

Opsi Proration

Saat mengubah plan subscription, Anda memiliki empat opsi untuk menangani tagihan langsung:

1. prorated_immediately

  • Mengkredit bagian siklus penagihan saat ini yang tidak terpakai, dengan prorata berdasarkan sisa waktu. Kredit mencakup base plan, kuantitas, dan add-on
  • Kemudian menagih satu siklus penuh dengan plan, kuantitas, dan add-on baru. Tagihan itu sendiri tidak pernah diprorata
  • Tagihan langsung bersih = (siklus baru penuh) dikurangi (fraksi tersisa x siklus lama penuh). Jika kredit lebih besar, selisihnya ditahan sebagai kredit dalam cakupan subscription untuk renewal mendatang
  • Selama periode trial, opsi ini segera memindahkan pengguna ke plan baru dan langsung menagih pelanggan

2. full_immediately

  • Menagih pelanggan sejumlah penuh subscription untuk plan baru tanpa kredit untuk siklus sebelumnya
  • Baik saat upgrade maupun downgrade, pelanggan membayar seluruh harga plan baru dari awal
  • Berguna jika Anda ingin menagih jumlah penuh terlepas dari sisa waktu pada plan lama

3. difference_immediately

  • Pelanggan hanya membayar selisih antara harga plan lama dan plan baru
  • Jumlahnya tidak bergantung pada kapan perubahan dilakukan dalam siklus. Upgrade yang sama memiliki biaya yang sama pada hari ke-1 maupun hari ke-29
  • Saat upgrade, pelanggan langsung ditagih selisihnya. Contoh, $30/bulan → $80/bulan = $50 langsung ditagihkan
  • Saat downgrade, selisih harga disimpan sebagai kredit dalam cakupan subscription dan diterapkan secara otomatis pada renewal mendatang. Contoh, $50/bulan → $20/bulan = $30 disimpan sebagai kredit

4. do_not_bill

  • Menerapkan perubahan plan segera tetapi tidak menagih apa pun saat perubahan dilakukan. Plan, kuantitas, dan add-on baru langsung dapat digunakan
  • Karena tidak ada tagihan sekarang, upgrade memberikan plan yang lebih tinggi secara gratis kepada pelanggan selama sisa siklus saat ini. Downgrade berlaku segera tanpa kredit untuk bagian siklus yang belum digunakan dan telah dibayar
  • Add-on yang diberikan melalui do_not_bill tidak dikreditkan pada perubahan plan berikutnya karena add-on tersebut belum pernah ditagihkan. Perubahan berikutnya menagih jumlah add-on baru secara penuh
  • Plan yang diperbarui (beserta kuantitas/add-on) ditagihkan pada renewal terjadwal berikutnya, dan tanggal penagihan asli dipertahankan
Ketiga mode “charge now” mereset siklus penagihan. prorated_immediately, difference_immediately, dan full_immediately memindahkan next_billing_date subscription ke tanggal perubahan. Hanya do_not_bill yang mempertahankan tanggal renewal asli, tetapi opsi ini tidak menerapkan tagihan langsung.

Perilaku

  • Saat Anda memanggil API ini, Dodo Payments segera memulai tagihan berdasarkan opsi proration yang dipilih
  • Dengan prorated_immediately, kredit untuk bagian siklus saat ini yang tidak terpakai dihitung pada setiap perubahan, baik upgrade maupun downgrade. Jika kredit tersebut melebihi tagihan siklus baru, sisanya ditambahkan ke saldo kredit subscription. Kredit ini khusus untuk subscription tersebut dan hanya digunakan untuk mengimbangi pembayaran berkala mendatang dari subscription yang sama
  • Dengan difference_immediately, nilai bersih selalu sama persis dengan selisih harga. Untuk downgrade, kelebihannya disimpan sebagai kredit dalam cakupan subscription, sama seperti prorated_immediately
  • Opsi full_immediately melewati perhitungan kredit dan menagih jumlah plan baru secara lengkap
  • Opsi do_not_bill menerapkan perubahan segera tetapi menunda penagihan hingga tanggal renewal berikutnya, yang tetap dipertahankan
Memilih mode proration:
  • difference_immediately — pelanggan membayar selisih harga. Opsi paling mudah diprediksi; tagihannya sama kapan pun perubahan dilakukan dalam siklus.
  • prorated_immediately — pelanggan hanya mendapat kredit untuk waktu yang belum digunakan pada siklus saat ini. Tagihan bervariasi berdasarkan waktu perubahan dilakukan dalam siklus.
  • full_immediately — pelanggan membayar jumlah penuh plan baru. Tidak ada kredit untuk siklus sebelumnya.
  • do_not_bill — tidak ada tagihan sekarang. Plan baru ditagihkan pada renewal berikutnya. Satu-satunya mode yang mempertahankan tanggal penagihan asli.

Pemrosesan Tagihan

  • Tagihan langsung yang dimulai setelah perubahan plan biasanya selesai diproses dalam waktu kurang dari 2 menit
  • Jika tagihan langsung ini gagal karena alasan apa pun, subscription secara otomatis ditangguhkan hingga masalah terselesaikan

Subscription On-Demand

Subscription on-demand memungkinkan Anda menagih pelanggan secara fleksibel, bukan hanya berdasarkan jadwal tetap. Fitur ini tersedia untuk semua akun.
Untuk membuat subscription on-demand: Untuk membuat subscription on-demand, gunakan endpoint API POST /checkouts dan sertakan field subscription_data.on_demand dalam request body Anda. Dengan demikian, Anda dapat mengotorisasi metode pembayaran tanpa tagihan langsung atau menetapkan harga awal khusus.
POST /subscriptions sudah deprecated. Fitur ini masih berfungsi untuk integrasi yang sudah ada, tetapi integrasi baru harus membuat subscription on-demand melalui Checkout Session (POST /checkouts) dengan subscription_data.on_demand. Lihat Panduan Subscription On-Demand untuk alur terbaru.
Untuk menagih subscription on-demand: Untuk tagihan berikutnya, gunakan endpoint POST /subscriptions//charge dan tentukan jumlah yang akan ditagihkan kepada pelanggan untuk transaksi tersebut.
Untuk panduan lengkap langkah demi langkah (termasuk contoh request/response, kebijakan retry yang aman, dan penanganan webhook), lihat Panduan Subscription On-Demand.

Hal Penting yang Perlu Diketahui tentang Penagihan Subscription

Tetapkan periode subscription lebih panjang daripada frekuensi pembayaran. Jika periode subscription sama dengan frekuensi pembayaran (misalnya period = 1 month, frequency = 1 month), subscription hanya berlaku selama satu siklus lalu berpindah ke expired alih-alih diperbarui. Untuk plan bulanan berkelanjutan, tetapkan periode subscription yang panjang (misalnya 20 tahun) dengan frekuensi pembayaran bulanan.
Mata uang terkunci pada tagihan pertama yang berhasil. Selalu kirim billing_currency dan billing_address.country secara eksplisit saat membuat checkout. Jika tidak disertakan, keduanya dideteksi dari IP pelanggan (Adaptive Currency), dan setelah subscription menerima tagihan pertamanya, mata uang tersebut ditetapkan untuk seluruh masa berlaku subscription. Pelanggan yang bepergian setelahnya tidak dapat menggantinya.
Trial menggunakan otorisasi $0, bukan tagihan. Saat subscription memiliki trial, dimulainya trial membuat otorisasi mandat $0 untuk menyimpan kartu; tagihan pertama yang sebenarnya terjadi saat trial berakhir. Dalam daftar pembayaran, subscription dalam free trial menampilkan tepat satu pembayaran dengan total_amount sebesar 0. Paid trial justru menagih trial_amount di muka.
Siklus hidup subscription: past_due = renewal gagal dan masa tenggang sedang berjalan (pelanggan tetap memiliki akses). on_hold = renewal gagal (dapat dipulihkan: minta pelanggan memperbarui metode pembayaran; retry dunning berlaku). expired = masa berlaku berakhir tanpa renewal dan tidak dapat diaktifkan kembali. Pelanggan harus berlangganan kembali. cancelled = diakhiri oleh pelanggan atau merchant. Sebagian besar kegagalan renewal merupakan penolakan dari issuer (dana tidak mencukupi, kartu ditolak), bukan kesalahan Dodo.
Kartu India menggunakan e-mandate RBI. Tagihan off-session (renewal dan tagihan perubahan plan) dapat memerlukan waktu hingga sekitar 48 jam untuk diselesaikan, dan auto-debit berkala di atas ₹15.000 memerlukan autentikasi pelanggan baru (sehingga upgrade yang melewati batas tersebut tidak dapat menggunakan mandat yang sudah ada). Saat satu tagihan masih berstatus processing, tagihan kedua pada subscription yang sama gagal dengan “Cannot create new charge as previous payment is not successful yet.” Kartu non-India dikonfirmasi hampir seketika.
Tagihan subscription memiliki minimum $1 (atau nilai setara dalam mata uang terkait). Jumlah sebesar $0.01–$0.99 ditolak dengan product_price: value out of range. Produk subscription dengan harga tepat $0 diperbolehkan; lihat Card-Optional at Zero Price. Untuk mengotorisasi kartu tanpa menagihnya, gunakan setup on-demand mandate_only.

Referensi API Terkait

Create Subscription (Deprecated)

API lama untuk membuat subscription secara langsung. Gunakan Checkout Sessions untuk integrasi baru

Change Subscription Plan

Referensi API untuk meng-upgrade, men-downgrade, atau mengubah plan subscription dengan opsi proration

Update Payment Method

Referensi API untuk memperbarui metode pembayaran dan mengaktifkan kembali subscription yang ditangguhkan

Patch Subscription

Referensi API untuk memperbarui detail dan konfigurasi subscription
Terakhir diubah pada 26 September 2026