Notifikasi refund yang terlewat bisa membuat Anda kehilangan satu-satunya refund yang boleh Anda sanggah, dan kedua toko memungkinkan Anda memulihkannya jika Anda memeriksa tepat waktu

Notifikasi refund yang terlewat adalah cara senyap developer kehilangan dua keputusan refund yang masih bisa mereka pengaruhi. CONSUMPTION_REQUEST dari Apple dan tinjauan chargeback dari Google Play sama-sama dimulai dengan notifikasi, dan keduanya ditutup dengan tenggat yang singkat: 12 jam di Apple, 24 jam di Google. Jika server Anda mati, lambat, atau salah konfigurasi saat pesan itu datang, toko tidak akan menunggu Anda. Toko akan memutuskan dengan informasi yang sudah dimilikinya.

Kabar baiknya, tidak ada toko yang membuang pesan pada kegagalan pertama. Apple mencoba ulang dan menyimpan riwayat 180 hari yang bisa Anda kueri. Google memublikasikan lewat Pub/Sub, yang menahan pesan yang belum di-acknowledge selama beberapa hari. Kabar buruknya, jadwal percobaan ulang tidak sejalan dengan batas waktu respons, dan salah satu dari dua alur itu sama sekali tidak punya API pemulihan.

Cara setiap toko mengirim notifikasi refund

Apple mengirim App Store Server Notifications langsung ke URL HTTPS yang Anda atur di App Store Connect. Google tidak memanggil server Anda secara langsung. Google memublikasikan Real-time developer notifications ke topik Google Cloud Pub/Sub, lalu subscription Anda pada topik itu akan mendorongnya ke endpoint Anda atau menunggu server Anda menariknya.

Apa yang dianggap gagal oleh Apple

Dokumentasi Apple cukup spesifik. Kembalikan status apa pun dari 200 sampai 206 dan pengiriman dianggap selesai. Kembalikan 40x atau 50x dan Apple akan mencoba ulang. Apple juga menganggap semua kode lain tidak berhasil. Setiap percobaan dicatat dengan sendAttemptResult, dan nilainya terbaca seperti daftar periksa gangguan nyata: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE, dan beberapa lainnya. Untuk TIMED_OUT, saran Apple sendiri adalah memastikan server Anda tidak memproses pesan secara langsung sebelum merespons.

Apa yang dianggap gagal oleh Google

Pada subscription push, kode respons sukses dari endpoint Anda adalah acknowledgement-nya. Pada subscription pull, server Anda harus meng-acknowledge setiap pesan yang ditariknya, atau Pub/Sub akan mengirimkannya lagi. Batas waktu acknowledgement default adalah 10 detik dan maksimalnya 600 detik. Panduan RTDN Google menambahkan satu aturan yang layak diulang: notifikasi hanya memberi tahu bahwa ada sesuatu yang berubah, jadi Anda tetap perlu memanggil Google Play Developer API untuk mendapatkan status pembelian lengkap.

Mengapa jadwal percobaan ulang Apple tidak cocok dengan batas waktu 12 jam

Interval percobaan ulang Apple dihitung dari percobaan sebelumnya, bukan dari percobaan pertama. Jika dijumlahkan, Anda mendapatkan linimasa berikut untuk satu notifikasi V2 yang terus gagal diterima server Anda.

Apple meminta Anda merespons dalam 12 jam sejak menerima CONSUMPTION_REQUEST. Jika server Anda mati saat pengiriman pertama dan saat percobaan ulang satu jam kemudian, percobaan berikutnya baru tiba 13 jam setelah yang pertama. Apple tidak menjelaskan apakah permintaan yang pertama kali diterima lewat percobaan ulang mendapat 12 jam baru. Tafsiran yang hati-hati adalah menganggap percobaan pertama sebagai awal hitungan, yang berarti percobaan ulang saja tidak akan menyelamatkan permintaan yang Anda lewatkan lebih dari satu jam.

Apakah Apple mencoba ulang setelah HTTP 400?

Ya, menurut dokumentasinya. Apple mencantumkan 40x dan 50x sebagai kode yang memicu percobaan ulang. Pada Maret 2026, seorang developer melaporkan di forum Apple bahwa percobaan ulang setelah respons 400 tampaknya berhenti, lalu mengatakan pengiriman kembali berjalan satu atau dua hari kemudian, dan Apple meminta laporan lewat Feedback Assistant. Jadikan perilaku yang terdokumentasi sebagai aturan, dan pemantauan Anda sendiri sebagai buktinya.

Pulihkan notifikasi App Store yang terlewat dengan Get Notification History

Get Notification History mengembalikan notifikasi versi 2 yang dicoba dikirim Apple ke server Anda dalam rentang waktu yang Anda pilih. Setiap record membawa payload lengkap yang ditandatangani, sehingga Anda bisa memasukkannya ke handler yang sama seperti notifikasi langsung. Setiap record juga menyertakan array sendAttempts hingga enam entri, satu untuk percobaan pertama dan satu untuk masing-masing dari lima percobaan ulang.

• startDate dan endDate wajib diisi, dan startDate harus berada dalam 180 hari terakhir di production atau 30 hari terakhir di sandbox.
• Atur onlyFailures ke true untuk hanya mendapatkan notifikasi yang belum sampai ke server Anda, ditambah yang masih dicoba ulang oleh Apple.
• Filter berdasarkan satu notificationType, seperti CONSUMPTION_REQUEST atau REFUND, atau berdasarkan transactionId untuk satu pelanggan, tetapi tidak keduanya dalam permintaan yang sama.
• Setiap panggilan mengembalikan hingga 20 record. Terus panggil dengan paginationToken selama hasMore bernilai true, dan kirim body permintaan yang sama setiap kali.

Ada satu catatan penting untuk refund. Apple menyatakan bahwa record riwayat mencerminkan status pembelian saat notifikasi pertama kali dikirim, bukan status saat ini. Jadi REFUND yang dipulihkan adalah fakta tentang masa lalu. Sebelum mencabut akses, periksa status terkini dengan endpoint status transaksi atau langganan.

Notifikasi V1 tidak bisa dipulihkan dengan cara ini

Get Notification History hanya mencakup versi 2. Apple mencoba ulang notifikasi V1 tiga kali, pada 6, 24, dan 48 jam setelah percobaan sebelumnya, dan jika semuanya gagal, tidak ada riwayat yang bisa diputar ulang. Itu satu alasan lagi untuk memindahkan aplikasi yang masih memakai V1 ke V2.

Pulihkan notifikasi refund Google Play yang terlewat

Jaring pengaman Google adalah Pub/Sub itu sendiri. Selama subscription Anda masih ada, pesan yang belum di-acknowledge siapa pun tetap tersimpan selama periode retensi, 7 hari secara default dan hingga 31 hari jika Anda menaikkannya. Saat endpoint Anda kembali aktif, pengiriman berlanjut. Ada dua pengaturan yang diam-diam bisa menggagalkan hal itu.

• Topik dead-letter memindahkan pesan keluar dari subscription Anda setelah sejumlah percobaan pengiriman gagal. Defaultnya 5, dan dengan kebijakan percobaan ulang default berupa pengiriman ulang langsung, lima percobaan bisa lewat dengan cepat. Jika Anda memakainya, pantau topik dead-letter seperti kotak masuk kedua.
• Subscription tanpa aktivitas subscriber, seperti koneksi terbuka, pull aktif, atau push yang berhasil, kedaluwarsa setelah 31 hari secara default. Endpoint yang rusak selama sebulan bisa kehilangan subscription itu sendiri, beserta semua yang menunggu di dalamnya.

Refund yang dibatalkan punya cadangan 30 hari

Untuk refund yang sudah terjadi, Voided Purchases API adalah cadangan berbasis pull. API ini menampilkan pembelian yang dibatalkan dari 30 hari terakhir, hingga 1.000 per halaman, dengan kuota 6.000 kueri per hari dan 30 kueri dalam setiap periode 30 detik untuk setiap aplikasi. Kirim type 1 untuk menyertakan langganan bersama produk sekali beli. Menjalankannya setiap hari akan menangkap refund apa pun yang terlewat oleh pipeline notifikasi Anda, sehingga hak akses dan angka pendapatan tetap akurat.

Tinjauan chargeback tidak punya cadangan

PendingRefundReviewNotification berbeda. Notifikasi ini membawa pendingRefundToken yang harus Anda kirim ke orders.reviewrefund, dan Anda punya 24 jam sejak menerimanya untuk mengirim preferensi refund dan bukti penggunaan. Google mencatat panggilan pertama Anda dan mengabaikan sisanya. Dokumentasi Google tidak menjelaskan endpoint apa pun yang menampilkan daftar tinjauan tertunda, jadi jika pesan Pub/Sub itu hilang, bukti Anda untuk chargeback tersebut ikut hilang.

Berapa biaya notifikasi refund yang terlewat

Notifikasi yang terlewat untuk refund yang sudah final hanya merepotkan pembukuan. Anda menemukannya belakangan di Voided Purchases API atau Get Notification History, mencabut akses jika kebijakan Anda mengharuskannya, dan laporan Anda menyusul. Merepotkan, tetapi murah.

Notifikasi yang terlewat di salah satu dari dua alur yang bisa disanggah menimbulkan kerugian uang yang nyata, karena toko memutuskan tanpa bukti Anda. Di Apple, artinya keputusan refund dibuat tanpa data konsumsi Anda. Di Google Play, untuk pesanan yang dibuat setelah 3 Agustus 2026, chargeback yang kalah membuat Anda kehilangan harga pembelian dikurangi biaya layanan Play, ditambah biaya chargeback yang dikenakan bank pembeli. Google hanya menanggung biaya layanannya sendiri.

Dan uang yang Anda keluarkan untuk memberikan pembelian itu sudah habis sebelum sengketa dimulai.

• Komputasi: waktu GPU dan server di balik setiap hasil generasi, render, atau respons model yang sudah dipakai pembeli.
• Panggilan API: permintaan ke pihak ketiga yang ditagih saat itu juga, sering kali per panggilan.
• Penyimpanan: file dan media yang dibuat pembeli, masih tercantum di tagihan hosting Anda.
• Pembayaran: bagi hasil yang sudah dibayarkan ke kreator, afiliasi, atau mitra atas penjualan itu.

Tidak satu pun dari itu kembali saat refund disetujui. Bukti yang Anda kirim dalam 12 atau 24 jam itu adalah satu-satunya alat yang Anda punya, dan notifikasi yang terlewat menghilangkannya.

Rutinitas pemulihan yang andal

• Acknowledge dulu. Simpan payload mentah, kembalikan kode sukses, lalu proses di antrean.
• Lakukan polling Get Notification History milik Apple dengan onlyFailures setiap beberapa menit untuk CONSUMPTION_REQUEST, sehingga gangguan hanya menghabiskan beberapa menit dari batas waktu 12 jam.
• Jalankan sapuan Get Notification History harian dengan onlyFailures untuk beberapa hari terakhir di semua tipe, lalu putar ulang apa yang Anda temukan.
• Jalankan panggilan Voided Purchases API harian dengan type 1 untuk setiap aplikasi Google Play, lalu cocokkan dengan refund yang sudah Anda catat.
• Di Pub/Sub, pertahankan retensi pesan 7 hari atau lebih, pasang peringatan pada topik dead-letter jika Anda memakainya, dan pasang peringatan saat pesan yang belum terkirim menumpuk.
• Uji seluruh jalurnya di production juga. Sandbox Apple mengirim setiap notifikasi sekali tanpa percobaan ulang, sedangkan Request a Test Notification bersama Get Test Notification Status menunjukkan persis bagaimana server Anda merespons.

RefundHalt menerima notifikasi dari kedua toko untuk Anda dan menjawab CONSUMPTION_REQUEST serta tinjauan chargeback secara otomatis dalam batas waktunya, jadi bukan Anda yang harus terus mengawasi jam.