> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Percobaan Ulang Pembayaran Langganan
> Secara otomatis mencoba kembali pembayaran perpanjangan langganan yang gagal berdasarkan jadwal back-off cerdas untuk memulihkan pendapatan tanpa pekerjaan integrasi.
Payment Retries secara otomatis mencoba kembali pembayaran **perpanjangan** langganan yang gagal berdasarkan jadwal back-off progresif. Saat percobaan ulang berhasil, langganan diaktifkan kembali secara otomatis — tanpa tindakan pelanggan atau pekerjaan integrasi.
## Apa Itu Payment Retries?
Saat pembayaran perpanjangan langganan gagal, langganan ditempatkan dalam status **on hold**. Dengan Payment Retries yang diaktifkan, Dodo Payments secara otomatis menagih kembali metode pembayaran pelanggan yang sudah ada berdasarkan jadwal cerdas hingga pembayaran berhasil atau periode pemulihan berakhir.
Ini memulihkan pendapatan yang hilang akibat kegagalan sementara — penangguhan kartu yang kedaluwarsa, dana tidak mencukupi yang kemudian ditambahkan, kesalahan jaringan sementara — tanpa mengirim email kepada pelanggan atau meminta mereka memperbarui apa pun.
Payment Retries hanya berlaku untuk pembayaran **perpanjangan** langganan. Pembayaran pertama (penyiapan mandat), pembayaran satu kali, biaya perubahan paket, dan biaya on-demand tidak dicoba kembali oleh fitur ini.
## Cara Kerja Payment Retries
Pembayaran perpanjangan langganan gagal dan langganan berpindah ke status `on_hold`.
Kode error kegagalan diperiksa. **Soft decline** (dana tidak mencukupi, penolakan umum, error pemrosesan atau jaringan, dan sebagainya) dapat dicoba kembali. **Hard decline** langsung mengakhiri rangkaian percobaan ulang, karena percobaan ulang tidak akan mengubah hasilnya.
Jika penolakan dapat dicoba kembali dan periode pemulihan masih memungkinkannya, percobaan berikutnya dijadwalkan. Percobaan ulang dijalankan off-session menggunakan metode pembayaran pelanggan yang sudah ada berdasarkan jadwal back-off progresif.
Pada percobaan ulang pertama yang berhasil, langganan kembali ke `active` dan tanggal penagihan berikutnya dimajukan seperti biasa. Jika periode tersebut berakhir sebelum percobaan ulang berhasil, percobaan ulang dihentikan dan langganan tetap dalam status on hold.
## Mengonfigurasi Payment Retries
Aktifkan dan konfigurasikan Payment Retries dari **Settings → Recovery** di dashboard Anda.
| Pengaturan | Deskripsi | Default |
| -------------------------- | --------------------------------------------------------------------------------------------------------- | ------------ |
| **Enable Payment Retries** | Secara otomatis mencoba kembali pembayaran perpanjangan langganan yang gagal untuk memulihkan pendapatan. | Off (opt-in) |
| **Recovery window (days)** | Durasi percobaan ulang pembayaran yang gagal sebelum dihentikan. Harus antara **1 dan 30**. | 13 |
**Periode pemulihan** dihitung sejak waktu invoice perpanjangan yang gagal dibuat. Percobaan ulang hanya dijadwalkan selama total penundaan back-off masih berada dalam periode tersebut.
## Jadwal Percobaan Ulang
Penundaan percobaan ulang meningkat secara progresif. Hingga **8 percobaan** dilakukan, selama masing-masing masih berada dalam periode pemulihan Anda:
| Percobaan | Penundaan setelah percobaan sebelumnya | Perkiraan waktu sejak kegagalan |
| --------- | -------------------------------------- | ------------------------------- |
| 1 | 12 jam | 12 jam |
| 2 | 24 jam | 36 jam |
| 3 | 48 jam | \~3,5 hari |
| 4 | 72 jam | \~6,5 hari |
| 5 | 96 jam | \~10,5 hari |
| 6 | 120 jam | \~15,5 hari |
| 7 | 7 hari | \~22,5 hari |
| 8 | 7 hari | \~29,5 hari |
Periode pemulihan selama **13 hari** (default) mencakup percobaan 1 hingga 5 (percobaan 5 dijalankan sekitar 10,5 hari setelah kegagalan). Tingkatkan periode tersebut hingga maksimum 30 hari jika Anda ingin percobaan berikutnya yang berjarak lebih panjang (6 hingga 8) dijalankan.
## Transisi Status Langganan
| Peristiwa | Status langganan |
| ----------------------------- | ----------------------------------------------------------------------------------------- |
| Pembayaran perpanjangan gagal | `active` → `on_hold` |
| Percobaan ulang gagal | tetap `on_hold` (percobaan ulang berikutnya dijadwalkan jika periode memungkinkannya) |
| Percobaan ulang berhasil | `on_hold` → `active`, tanggal penagihan berikutnya dimajukan |
| Periode pemulihan berakhir | tetap `on_hold` |
| Langganan dibatalkan | percobaan ulang terjadwal langsung dihentikan (terminal — tidak ada percobaan berikutnya) |
Jika langganan dibatalkan saat percobaan ulang masih dijadwalkan, rangkaian percobaan ulang langsung berakhir dan tidak ada percobaan berikutnya. Status nonaktif lainnya (`on_hold`, `expired`, `pending`, `failed`) tetap menjalani percobaan ulang, karena invoice perpanjangan yang terbuka mewakili utang untuk periode yang telah digunakan pelanggan.
Transisi ini memicu event webhook langganan standar, sehingga Anda dapat menggunakannya untuk menjalankan logika hak akses tanpa penanganan percobaan ulang khusus:
| Peristiwa | Dipicu saat |
| ---------------------- | ----------------------------------------------------------------- |
| `subscription.on_hold` | Perpanjangan gagal dan langganan ditempatkan dalam status on hold |
| `subscription.active` | Percobaan ulang berhasil dan langganan diaktifkan kembali |
Lihat skema payload webhook lengkap untuk event siklus hidup langganan.
## Kegagalan yang Dapat dan Tidak Dapat Dicoba Kembali
| Jenis kegagalan | Contoh | Dicoba kembali? |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
| **Soft decline** | Dana tidak mencukupi, penolakan umum, batas penggunaan kartu terlampaui, error pemrosesan, error/timeout jaringan, coba lagi nanti | Ya |
| **Hard decline** | Kartu dicuri/hilang, kartu tidak valid, do-not-honor, akun ditutup, dan penolakan terminal lainnya | Tidak — rangkaian langsung berakhir |
Mencoba kembali hard decline tidak akan mengubah hasilnya, sehingga rangkaian percobaan ulang berakhir segera setelah hard decline terdeteksi. Gunakan Payment Retries bersama [Subscription Dunning](/features/recovery/subscription-dunning) untuk meminta pelanggan memperbarui metode pembayaran mereka dalam kasus tersebut.
## Payment Retries vs. Dunning
Payment Retries dan [Subscription Dunning](/features/recovery/subscription-dunning) adalah alat pemulihan yang saling melengkapi:
| | Payment Retries | Subscription Dunning |
| ----------------------- | --------------------------------------------------------------- | -------------------------------------------------------------------------- |
| **Mekanisme** | Menagih ulang metode pembayaran yang sudah ada secara diam-diam | Mengirim email kepada pelanggan untuk memperbarui metode pembayaran mereka |
| **Tindakan pelanggan** | Tidak diperlukan | Pelanggan memperbarui metode pembayaran di portal |
| **Paling sesuai untuk** | Penolakan sementara/soft decline yang dapat pulih sendiri | Kartu kedaluwarsa atau tidak valid yang perlu diganti |
Mengaktifkan keduanya memberikan cakupan pemulihan terluas: percobaan ulang otomatis menangani kegagalan sementara, sementara dunning mengembalikan pelanggan yang metode pembayarannya memang perlu diperbarui.
## Terkait
Urutan email yang meminta pelanggan memperbarui metode pembayaran mereka.
Pulihkan checkout satu kali yang belum selesai atau gagal dengan email yang ditargetkan.
Pahami status langganan yang terlibat dalam alur pemulihan.
Tanggapi event `subscription.on_hold` dan `subscription.active`.