Verifikasi notifikasi server App Store sebelum Anda menindaklanjuti refund, karena siapa pun dapat mengirim ke URL webhook Anda

Siapa pun yang mengetahui URL webhook Anda dapat mengirimkan refund ke sana. Itulah fakta yang tidak nyaman di balik setiap notifikasi server App Store dan setiap Real-time developer notification Google Play: sampai Anda memverifikasinya, pesan itu hanyalah HTTPS POST yang berisi JSON. Jika server Anda mencabut langganan, menarik kembali kredit, atau memblokir akun karena sebuah permintaan menyebut REFUND, Anda telah menyerahkan kewenangan itu kepada siapa saja yang bisa menulis perintah curl.

Kedua store menyediakan cara untuk memeriksanya. Apple menandatangani notifikasi itu sendiri, sehingga Anda dapat memverifikasi notifikasi server App Store hanya dengan sertifikat root Apple. Google Play menempuh jalan yang berbeda. Pesannya tidak ditandatangani, tetapi pengiriman Pub/Sub dapat ditandatangani, dan Google tetap meminta Anda mengonfirmasi setiap perubahan melalui API-nya. Berikut apa yang dibuktikan oleh masing-masing, dan berapa kerugiannya jika Anda keliru ke salah satu arah.

Apa yang sebenarnya ditandatangani oleh setiap store

Cara memverifikasi notifikasi server App Store

Dokumentasi Apple menggambarkan signedPayload sebagai string berisi tiga komponen yang dienkode Base64URL dan dipisahkan oleh titik: header, payload, dan tanda tangan, yang ditandatangani sesuai spesifikasi JSON Web Signature. Mendekode payload itu mudah. Memercayainya memerlukan empat pemeriksaan.

• Baca array x5c dari header yang telah didekode. Apple mendokumentasikan urutannya: pertama sertifikat dengan kunci penanda tangan, kemudian sertifikat perantara Apple, lalu sertifikat root Apple.
• Validasi rantai tersebut terhadap root Apple yang Anda unduh sendiri dari situs PKI Apple, dalam praktiknya Apple Root CA - G3. Jangan pernah memercayai root yang datang di dalam pesan, karena pemalsu dapat menaruh sertifikat apa pun di sana.
• Pastikan sertifikat perantara membawa ekstensi Apple Worldwide Developer Relations, 1.2.840.113635.100.6.2.1, lalu verifikasi tanda tangan JWS dengan kunci publik sertifikat leaf.
• Periksa data yang telah didekode terhadap aplikasi Anda: bundleId, appAppleId di produksi, dan environment. Tanda tangan Apple yang valid pada aplikasi developer lain, atau pada pembelian sandbox yang masuk ke endpoint produksi Anda, tetap bukan refund milik Anda.

Kemudian lakukan hal yang sama untuk isinya. Objek data memuat signedTransactionInfo dan signedRenewalInfo, dan masing-masing adalah JWS terpisah dengan rantai x5c-nya sendiri. Handler REFUND yang memverifikasi amplopnya tetapi membaca transaksi tanpa memverifikasinya telah meninggalkan celah di tengah.

Gunakan library Apple alih-alih menulisnya sendiri

Apple menerbitkan App Store Server Library untuk Swift, Java, Python, dan Node. SignedDataVerifier di dalamnya menerima sertifikat root Anda, flag pemeriksaan online, environment, bundle ID Anda, dan untuk produksi, appAppleId Anda. Kode sumber Node menunjukkan apa yang ditegakkannya: tepat tiga sertifikat dalam rantai, ekstensi leaf Apple 1.2.840.113635.100.6.11.1 dan ekstensi perantara, tanggal masa berlaku sertifikat, serta bundle ID, app ID, dan environment yang cocok. Dengan pemeriksaan online aktif, library ini juga menanyakan kepada responder OCSP apakah sertifikat leaf dan perantara telah dicabut.

Apakah daftar izin IP sudah cukup?

Tidak. Apple menyatakan bahwa jika server Anda memerlukan daftar izin, Anda sebaiknya menambahkan subnet 17.0.0.0/8, dan ini berlaku untuk sandbox maupun produksi. Itu mengurangi gangguan. Namun itu tidak membuktikan bahwa sebuah pesan asli, dan akan gagal begitu jaringan Apple berubah dengan cara yang tidak Anda ketahui. Pertahankan pemeriksaan tanda tangan sebagai gerbang yang sesungguhnya.

Cara memverifikasi notifikasi refund Google Play

Google Play memublikasikan pesan RTDN ke topik Pub/Sub milik Anda, dan hanya service account google-play-developer-notifications@system.gserviceaccount.com yang boleh memegang peran Pub/Sub Publisher pada topik tersebut. Subscription Anda kemudian mengirimkan pesan dengan salah satu dari dua cara, dan masing-masing memiliki buktinya sendiri.

• Pull subscription: server Anda membuka koneksi terautentikasi ke Pub/Sub dan mengambil pesan. Tidak ada endpoint publik, sehingga tidak ada tempat bagi orang asing untuk mengirim.
• Push subscription dengan autentikasi aktif: Pub/Sub menandatangani JSON Web Token dan mengirimkannya di header Authorization sebagai token Bearer. Panduan Google meminta Anda memvalidasi tanda tangan token dan memeriksa bahwa klaim email dan audience-nya cocok dengan nilai yang Anda konfigurasikan, dan contoh kodenya juga mensyaratkan email_verified bernilai true. Token tersebut bisa berumur hingga satu jam.
• Push subscription tanpa autentikasi: apa pun yang dapat menjangkau URL tersebut dapat mengirim pesan yang berbentuk seperti RTDN.

Mengapa Google ingin Anda mengonfirmasi dengan API

Bahkan RTDN yang terautentikasi sempurna pun tidak membawa cerita lengkapnya. Panduan penyiapan Google menyatakan dengan jelas bahwa notifikasi ini hanya memberi tahu Anda bahwa status pembelian telah berubah dan bahwa Anda harus memanggil Google Play Developer API untuk mendapatkan status lengkapnya. Untuk voidedPurchaseNotification, artinya Anda menemukan pembelian tersebut di Voided Purchases API, atau mengambil status terkininya, sebelum mencabut apa pun. Panggilan API diautentikasi dengan service account Anda sendiri, sehingga jawabannya tidak dapat dipalsukan oleh pemalsu.

Berapa kerugian finansial dari refund palsu atau refund yang ditolak

Notifikasi refund palsu yang Anda percayai membuat Anda kehilangan pelanggan yang membayar. Anda mengunci akses seseorang yang uangnya masih Anda pegang, mereka membuka tiket dukungan, dan sebagian akan pergi ke store untuk meminta refund yang sudah seolah-olah diberikan oleh sistem Anda. Pembelian atau perpanjangan palsu merugikan dari arah sebaliknya: Anda menyerahkan komputasi GPU, panggilan API pihak ketiga berbayar, penyimpanan, dan pembayaran kreator atas pendapatan yang tidak pernah ada.

Kegagalan sebaliknya lebih senyap dan sering kali lebih besar. Verifier yang menolak pesan asli, karena appAppleId yang salah, pengaturan sandbox di produksi, atau sertifikat root yang usang, menggugurkan dua alur refund di mana bukti Anda berpengaruh. Apple meminta data konsumsi dalam 12 jam sejak CONSUMPTION_REQUEST. Google memberi Anda 24 jam untuk menjawab peninjauan chargeback melalui orders.reviewrefund, dan untuk pesanan yang dibuat setelah 3 Agustus 2026, chargeback Google Play yang kalah membebani Anda sebesar harga pembelian dikurangi biaya layanan Play, ditambah biaya yang dikenakan bank pembeli.

Jangan biarkan bug verifikasi menghabiskan tenggat waktu

• Simpan permintaan mentah sebelum Anda memverifikasinya, sehingga pesan yang ditolak tidak pernah benar-benar hilang.
• Pasang peringatan untuk setiap kegagalan verifikasi. Satu pesan palsu hanyalah gangguan. Semua pesan gagal sekaligus berarti bug Anda sendiri.
• Di Apple, Anda dapat memutar ulang pesan yang Anda tolak. Get Notification History mengembalikan signedPayload asli untuk 180 hari terakhir, jadi perbaiki verifier Anda dan jalankan kembali payload yang tersimpan atau dipulihkan melaluinya.
• Di Google, peninjauan chargeback yang tertunda hanya ada di notifikasinya, sehingga audience push yang salah dikonfigurasi berarti peninjauan yang terlewat. Uji dengan Send Test Message di Play Console setiap kali ada perubahan.

RefundHalt memverifikasi notifikasi dari kedua store, mengonfirmasi refund dengan API store sebelum ada yang berubah, dan menjawab CONSUMPTION_REQUEST serta peninjauan chargeback dalam batas waktunya, sehingga pesan palsu tidak dapat membuat Anda kehilangan pelanggan dan pesan asli tidak dapat terlewat.