Fitur Baru
1. Pengulangan Pembayaran Langganan
Pembayaran pembaruan langganan yang gagal sekarang dapat diulang secara otomatis untuk memulihkan pendapatan, tanpa memerlukan pekerjaan integrasi. Aktifkan dari Pengaturan → Pemulihan, tetapkan jendela pemulihan, dan Dodo Payments mencoba ulang pembaruan pada jadwal pintar hingga berhasil atau jendela ditutup.
| Pengaturan | Deskripsi | Default |
|---|
| Aktifkan Ulang Pembayaran | Mengulangi secara otomatis pembayaran pembaruan langganan yang gagal untuk memulihkan pendapatan. | Mati (opt-in) |
| Jendela pemulihan (hari) | Berapa lama waktu untuk mengulang pembayaran yang gagal sebelum menyerah (1–30). | 13 |
- Pembayaran pembaruan langganan gagal dan langganan berpindah ke
on_hold.
- Jika penolakan dapat diulang (penolakan lunak seperti dana tidak mencukupi atau kesalahan jaringan sementara), upaya berikutnya dijadwalkan secara otomatis.
- Pengulangan dilakukan di luar sesi pada jadwal back-off, dibatasi oleh jendela pemulihan Anda.
- Pada pengulangan pertama yang berhasil, langganan kembali ke
active dan tanggal penagihan berikutnya melanjutkan seperti biasa.
Jadwal pengulangan
Pengulangan ditunda progresif, terikat pada waktu faktur yang gagal dibuat. Hingga 8 upaya dilakukan, selama cocok dengan jendela pemulihan Anda:
| Upaya | Penundaan setelah sebelumnya |
|---|
| 1 | 12 jam |
| 2 | 24 jam |
| 3 | 48 jam |
| 4 | 72 jam |
| 5 | 96 jam |
| 6 | 120 jam |
| 7 | 7 hari |
| 8 | 7 hari |
Hanya penolakan lunak yang diulang (misalnya dana tidak mencukupi, penolakan umum, kesalahan pemrosesan atau jaringan). Penolakan keras mengakhiri rantai pengulangan segera, karena mengulang tidak akan mengubah hasilnya.
2. Pengaturan Prorata Bisnis
Anda sekarang dapat menetapkan perilaku peningkatan & penurunan default sekali di tingkat bisnis daripada melewati parameter prorata pada setiap perubahan paket. Default ini berlaku setiap kali pelanggan mengubah paket mereka dari portal pelanggan, dan Anda dapat menggantinya per koleksi produk.
Setiap arah (peningkatan dan penurunan) memiliki dua kontrol independen, ditambah kebijakan kegagalan pembayaran bersama:
| Pengaturan | Bidang | Default (peningkatan) | Default (penurunan) |
|---|
| Kapan rencana baru dimulai | effective_at_on_upgrade / effective_at_on_downgrade | immediately | next_billing_date |
| Bagaimana pelanggan dikenakan biaya | proration_billing_mode_on_upgrade / proration_billing_mode_on_downgrade | difference_immediately | difference_immediately |
| Jika pembayaran pelanggan gagal | on_payment_failure | apply_change | apply_change |
effective_at)
| Nilai | Perilaku |
|---|
immediately | Pelanggan pindah ke rencana baru segera. |
next_billing_date | Pelanggan tetap pada rencana saat ini hingga tanggal penagihan berikutnya, lalu beralih ke yang baru. |
proration_billing_mode)
| Nilai | Perilaku |
|---|
prorated_immediately | Mematok jumlah yang dihitung sekarang, berdasarkan waktu tersisa dalam siklus penagihan saat ini. |
full_immediately | Mematok harga penuh dari rencana baru sekarang. |
difference_immediately | Mematok hanya selisih harga antara rencana baru dan yang saat ini. |
do_not_bill | Tidak mematok apa pun sekarang. Penyesuaian diterapkan pada faktur berikutnya. |
on_payment_failure)
| Nilai | Perilaku |
|---|
prevent_change | Tetap memegang pelanggan pada rencana saat ini jika pembayaran gagal. |
apply_change | Pindahkan pelanggan ke rencana baru meskipun pembayaran gagal. Anda dapat mengumpulkan jumlahnya nanti. |
per-request value (Change Plan API) → collection field (if set) → business field → system default
Nilai per-permintaan yang diteruskan ke API Ubah Rencana (proration_billing_mode, effective_at, on_payment_failure) selalu lebih tinggi daripada baik default koleksi maupun bisnis. Pengaturan baru hanya mengubah apa yang terjadi ketika tidak ada nilai eksplisit yang disediakan — yang merupakan kasus untuk semua perubahan rencana portal pelanggan. 3. Mengumpulkan Nama Bisnis untuk Faktur B2B
Pelanggan B2B sekarang dapat memiliki nama bisnis resmi mereka ditampilkan pada faktur alih-alih nama pribadi pembeli. Ketika ID Pajak yang valid diberikan saat checkout, Anda juga dapat mengumpulkan customer_business_name terkait sehingga faktur mencerminkan entitas pembelian.
Ketika pelanggan memilih Membeli sebagai bisnis saat checkout, mereka diminta untuk memberikan Nama Bisnis dan Nomor ID Pajak.
Nama bisnis muncul pada faktur hanya ketika tiga kondisi berikut terpenuhi:
- Transaksi adalah B2B (
b2b = true)
tax_id hadircustomer_business_name yang tidak kosong disediakan
Jika tidak, nama pribadi pelanggan yang digunakan.
Mengumpulkannya saat checkout
Tetapkan customer_business_name secara langsung, dan/atau aktifkan allow_customer_editing_business_name untuk membiarkan pelanggan memasukkan atau mengeditnya pada halaman checkout bersamaan dengan ID Pajak mereka:
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_abc', quantity: 1 }],
customer: { email: 'buyer@acme.com' },
tax_id: 'GB123456789',
customer_business_name: 'Acme Corp Ltd',
feature_flags: {
allow_tax_id: true,
allow_customer_editing_business_name: true // let the customer enter/edit it
},
return_url: 'https://yoursite.com/return'
});
| Permukaan | Bidang | Catatan |
|---|
| Sesi Checkout | customer_business_name, feature_flags.allow_customer_editing_business_name | Maks 250 karakter; flag default ke false |
| Pembayaran | customer_business_name | Maks 250 karakter |
| Langganan | customer_business_name | Tetapkan atau hapus melalui PATCH /subscriptions/{id} |
customer_business_name tidak dapat ditetapkan tanpa tax_id. Mengirimkan nama bisnis tanpa ID Pajak ditolak. Menghapus tax_id juga menghapus nama bisnis, karena keduanya terkait pada faktur.
Spasi di sekitarnya akan dipotong, dan nilai yang hanya berisi spasi dianggap sebagai penghapusan eksplisit — sehingga data yang disimpan selalu sesuai dengan yang ditampilkan pada faktur.
Perbaikan Bug & Peningkatan
- Perbaikan bug minor dan peningkatan stabilitas di seluruh platform.
