Retention Messaging API dari Apple menaruh pesan Anda di layar pembatalan, tetapi permintaan refund tidak pernah melewatinya

Pelanggan yang mengetuk Cancel di iPhone kini bisa melihat pesan pilihan Anda, paket yang lebih murah, atau diskon, sebelum mereka mengonfirmasi. Itulah Retention Messaging API dari Apple, dan untuk pertama kalinya developer punya suara di layar pembatalan milik Apple sendiri. Fitur ini masih pra-rilis dan Anda harus meminta untuk ikut. Fitur ini juga punya batas tegas yang penting jika Anda peduli soal refund: ia berbicara kepada orang yang akan berhenti membayar, bukan kepada orang yang meminta uangnya kembali. Permintaan itu sampai ke Apple lewat jalan lain.

Apa yang dilakukan Retention Messaging API dari Apple

Retention Messaging API adalah layanan server-ke-server. Anda mengunggah teks pesan dan gambar ke Apple terlebih dahulu, Apple meninjaunya, lalu Anda memilih pesan yang sudah disetujui mana yang dilihat pelanggan saat mereka akan membatalkan langganan yang diperpanjang otomatis. Dokumentasi Apple mencantumkan empat jenis pesan:

• Pesan teks, yang dapat berisi poin-poin.
• Pesan teks dengan gambar.
• Pesan ganti paket, yang menyarankan langganan lain dalam grup langganan yang sama.
• Pesan penawaran promosi, yang menawarkan harga diskon di tingkat yang sama atau berbeda, memakai penawaran promosi yang Anda siapkan di App Store Connect dan tandatangani di server Anda.

Pesan muncul setelah pelanggan mengetuk Cancel Subscription di halaman detail langganan. Apple lalu menampilkan halaman Confirm Cancellation. Pelanggan tetap bisa membatalkan, mengetuk Keep Subscription, atau menerima penawaran atau paket yang Anda sarankan. Anda tidak bisa menyembunyikan jalan keluar, dan Apple meminta developer tidak mengunggah konten yang menyesatkan atau tidak akurat.

Pesan default dan alur real-time

Ada dua cara menjalankannya. Yang sederhana adalah pesan default: teks, dengan atau tanpa gambar atau poin-poin, yang ditetapkan untuk setiap produk dan bahasa. Yang lebih kaya adalah alur real-time, di mana Apple memanggil endpoint Get Retention Message di server Anda dan Anda menjawab dengan ID pesan. Hanya alur real-time yang bisa menampilkan pesan ganti paket dan penawaran promosi.

Dalam praktiknya, pesan default tidak opsional. Apple memakainya sebagai cadangan setiap kali panggilan real-time gagal, dan Apple sama sekali tidak menampilkan pesan retensi untuk produk di bahasa mana pun yang tidak punya pesan default.

Apa yang diberitahukan Apple ke server Anda dalam panggilan real-time

Permintaannya berupa JWS yang ditandatangani App Store. Setelah didekode, isinya originalTransactionId, appAppleId, productId, userLocale, requestIdentifier berupa UUID, environment, dan signedDate. Apple meminta Anda memastikan appAppleId cocok dengan aplikasi Anda dan tidak menjawab jika tidak cocok. Bagian yang berguna adalah originalTransactionId, karena dengan itu Anda bisa melihat apa yang benar-benar dilakukan pelanggan ini di aplikasi Anda sebelum memilih apa yang akan disampaikan.

Di mana pesan retensi muncul, dan di mana tidak

Apple menempatkan pesan di satu layar, yaitu langkah Confirm Cancellation setelah pelanggan mengetuk Cancel Subscription, misalnya dari Apple Account > Subscriptions atau dari halaman langganan di App Store. Layar itu menyangkut apakah perpanjangan berikutnya terjadi. Layar itu tidak menyentuh uang yang sudah ditagih.

Permintaan refund adalah tindakan terpisah. Halaman dukungan Apple mengarahkan pelanggan ke reportaproblem.apple.com, tempat mereka memilih "Request a refund" (Minta refund), memilih alasan dan item, lalu menunggu kabar dalam 24 hingga 48 jam. Di dalam aplikasi Anda, beginRefundRequest dari StoreKit membuka lembar refund Apple, dan Apple menyatakan App Store butuh hingga 48 jam untuk menyetujui atau menolak. Tidak satu pun dari kedua jalur itu melewati layar Confirm Cancellation.

Bisakah pesan retensi menghentikan permintaan refund?

Tidak. Permintaan refund tidak pernah sampai ke layar tempat pesan itu berada. Ada detail dalam dokumentasi notifikasi Apple yang membuat hal ini jelas. Saat pelanggan meminta refund melalui aplikasi Anda dengan API permintaan refund, Apple sendiri mematikan perpanjangan otomatis dan mengirim DID_CHANGE_RENEWAL_STATUS dengan subtipe AUTO_RENEW_DISABLED. Pelanggan yang membatalkan dari halaman pengaturan Subscriptions menghasilkan tipe dan subtipe yang sama. Server Anda melihat satu notifikasi untuk dua pelanggan yang sangat berbeda, dan hanya satu dari mereka yang melihat pesan retensi Anda.

Jika permintaan refund berlanjut, saluran buktinya adalah CONSUMPTION_REQUEST. Apple mengirimnya untuk permintaan refund pada jenis produk apa pun, dan Anda punya waktu 12 jam untuk menjawab dengan Send Consumption Information. Anda hanya boleh menjawab jika pelanggan memberi persetujuan. Setelah itu, keputusan Apple datang sebagai notifikasi REFUND, atau REFUND_DECLINED jika Apple menolak refund yang dimulai pelanggan di aplikasi Anda.

Apakah Google Play punya API pesan pembatalan?

Tidak ada dalam dokumentasi siklus hidup langganan Google. Pelanggan Google Play membatalkan dari pusat langganan Play, tetap punya akses sampai akhir siklus penagihan saat ini, dan bisa mengetuk Resubscribe untuk membatalkannya sebelum itu, yang oleh Google disebut pemulihan (restore). Anda baru mengetahuinya setelahnya melalui notifikasi SUBSCRIPTION_CANCELED, dan kolom userInitiatedCancellation di resource langganan memberi tahu alasan pengguna pergi. Jeda (pause), yang menurut Google aktif secara default untuk semua langganan, adalah cara bawaan utamanya untuk mengurangi churn sukarela.

Di sisi refund, Google Play punya saluran buktinya sendiri. PendingRefundReviewNotification datang saat chargeback perlu ditinjau developer, dan Anda punya waktu 24 jam untuk menjawab melalui orders.reviewrefund. Untuk pesanan yang dibuat setelah 3 Agustus 2026, Google membebankan harga pembelian, dikurangi biaya layanan Play, ditambah biaya chargeback dari bank kepada developer saat chargeback berhasil.

Berapa biaya layar pembatalan bagi Anda

Pesan retensi tampak gratis. Kenyataannya tidak, dan tagihannya muncul di tiga tempat.

Komputasi di setiap tampilan halaman

Apple memanggil endpoint Anda saat pelanggan aktif membuka halaman detail langganan yang memiliki tombol Cancel, bukan hanya saat mereka membatalkan. Setiap kunjungan adalah permintaan yang harus diautentikasi, dicari datanya, dan dijawab server Anda dalam 700 ms, atau Apple memakai pesan default. Artinya, fungsi dengan cold start yang kadang butuh dua detik tidak bisa dipakai. Anda membayar kapasitas yang selalu siap, ditambah pembacaan database dan panggilan API pihak ketiga berbayar yang dilakukan logika keputusan Anda di setiap permintaan.

Diskon adalah pendapatan yang Anda pilih untuk tidak ditagih

Penawaran promosi yang mempertahankan pelanggan adalah uang nyata yang tetap Anda pegang. Penawaran yang jatuh ke orang yang toh akan bertahan hanyalah diskon. Berikut ilustrasi, bukan tolok ukur. Paket bulanan $9.99 yang ditawarkan setengah harga selama tiga bulan melepaskan $14.99 per penawaran yang diterima. Jika satu dari tiga orang yang menerima sebenarnya akan bertahan dengan harga penuh, seribu penerimaan menghabiskan sekitar $5,000 diskon untuk orang yang tidak pernah membutuhkannya. Sisi lain neracanya adalah pelanggan yang memang benar-benar akan pergi.

Refund yang dipicu oleh jalan keluar yang menyebalkan

Apple tetap menampilkan tombol Cancel Subscription di halaman, jadi Anda tidak bisa menjebak siapa pun, tetapi Anda tetap bisa membuat orang kesal. Pelanggan yang merasa didesak punya pilihan lain, yaitu meminta Apple mengembalikan tagihan terakhir. Saat refund benar-benar terjadi, uangnya kembali, sementara komputasi, penyimpanan, panggilan API, dan komisi afiliasi yang terkait dengan pelanggan itu tetap sudah terpakai. Itulah biaya yang tidak bisa dipulihkan oleh pesan retensi mana pun.

Cara memakai pesan retensi tanpa menaikkan tingkat refund

Perlakukan layar pembatalan sebagai tempat untuk bersikap akurat, bukan cerdik. Beberapa aturan berikut menjaganya tetap di sisi aman dari garis refund:

• Putuskan per pelanggan. Gunakan originalTransactionId dalam permintaan Apple untuk melihat penggunaan terbaru. Tawarkan diskon atau paket lebih murah kepada orang yang memakai produk. Berikan pesan singkat dan jujur kepada orang yang sudah berminggu-minggu tidak membukanya.
• Jaga jawaban tetap cepat. Hitung keputusan di muka saat data penggunaan Anda berubah, sehingga permintaannya cukup berupa satu pencarian yang jauh di bawah 700 ms.
• Tulis pesan default untuk setiap produk dan bahasa. Tanpa itu, panggilan yang gagal berarti tidak ada pesan sama sekali.
• Pantau AUTO_RENEW_DISABLED dengan cermat. Jika CONSUMPTION_REQUEST menyusul untuk originalTransactionId yang sama, Anda sedang melihat permintaan refund, bukan pembatalan, dan hitungan 12 jam sudah dimulai.
• Jawab setiap CONSUMPTION_REQUEST yang boleh Anda jawab. RefundHalt mengirim data konsumsi yang akurat ke Apple dalam jendela 12 jam dan menjawab peninjauan chargeback Google Play dalam 24 jam, karena hanya pada dua momen itulah kedua toko meminta keterangan dari pihak Anda.

Apakah layak meminta akses ke Apple?

Jika Anda menjual langganan yang diperpanjang otomatis dan sudah menangani App Store Server Notifications V2, kemungkinan besar ya. Layar pembatalan adalah tempat terakhir Anda bisa menjangkau pelanggan sebelum mereka pergi, dan saran ganti paket lebih murah bagi Anda daripada kehilangan mereka sepenuhnya. Hanya saja, siapkan anggaran untuk endpoint yang menjawab di setiap tampilan halaman langganan, dan tempatkan pertahanan refund Anda di tempat refund benar-benar terjadi.