> ## 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.
# v1.101.0 (2 Juni 2026)
> Upaya pembayaran langganan otomatis untuk memulihkan pendapatan pembaruan yang gagal, default prorata tingkat bisnis dengan penggantian per koleksi produk, dan pengumpulan nama bisnis untuk faktur B2B — plus perbaikan bug dan peningkatan.
## 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 |
**Cara kerjanya**
1. Pembayaran pembaruan langganan gagal dan langganan berpindah ke `on_hold`.
2. Jika penolakan dapat diulang (penolakan lunak seperti dana tidak mencukupi atau kesalahan jaringan sementara), upaya berikutnya dijadwalkan secara otomatis.
3. Pengulangan dilakukan di luar sesi pada jadwal back-off, dibatasi oleh jendela pemulihan Anda.
4. 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.
Ini melengkapi alat pemulihan yang ada — **Subscription Dunning** mengirim email kepada pelanggan untuk memperbarui metode pembayaran mereka, sementara Pengulangan Pembayaran diam-diam mencoba ulang yang sudah ada. Mereka bekerja dengan baik bersama.
Pelajari lebih lanjut: [Pengulangan Pembayaran Langganan](/features/recovery/payment-retries) | [Subscription Dunning](/features/recovery/subscription-dunning)
### 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` |
**Kapan rencana baru dimulai** (`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. |
**Bagaimana pelanggan dikenakan biaya** (`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. |
**Jika pembayaran pelanggan gagal** (`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. |
**Penggantian per-koleksi**
Setiap koleksi produk dapat menggantikan salah satu default ini. Setiap bidang bersifat independen — biarkan pada **Turunkan dari bisnis** untuk mengikuti default bisnis, atau tetapkan nilai eksplisit untuk menggantinya hanya untuk koleksi itu.
Setiap pengaturan diselesaikan dalam urutan ini:
```
per-request value (Change Plan API) → collection field (if set) → business field → system default
```
Nilai per-permintaan yang diteruskan ke [API Ubah Rencana](/api-reference/subscriptions/change-plan) (`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.
Pelajari lebih lanjut: [Peningkatan & Penurunan Langganan](/developer-resources/subscription-upgrade-downgrade) | [Koleksi Produk](/features/product-collections)
### 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:
1. Transaksi adalah B2B (`b2b = true`)
2. `tax_id` hadir
3. `customer_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:
```typescript theme={null}
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'
});
```
**Tempat diterapkannya**
| 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.
Pelajari lebih lanjut: [Pembayaran B2B](/features/b2b-payments) | [Pengelolaan Faktur](/features/invoice-generation) | [Sesi Checkout](/developer-resources/checkout-session)
## Perbaikan Bug & Peningkatan
* Perbaikan bug minor dan peningkatan stabilitas di seluruh platform.