Tiga notifikasi pengembalian dana App Store tiba setelah Apple memutuskan, dan REFUND_REVERSED mengembalikan penjualan kepada Anda

Apple memutuskan pengembalian dana Anda, lalu terus berbicara. Setelah hasilnya ditetapkan, App Store mengirim server Anda salah satu dari tiga notifikasi pengembalian dana App Store, dan masing-masing meminta langkah yang berbeda. REFUND mengatakan uang sudah pergi dan Anda harus mencabut akses. REFUND_DECLINED mengatakan pelanggan kalah dalam permintaan dan Anda mempertahankan penjualan. REFUND_REVERSED mengatakan Apple membatalkan pengembalian dana yang sudah diberikannya, jadi penjualan menjadi milik Anda lagi dan Anda perlu mengembalikan apa pun yang Anda ambil. Sebagian besar aplikasi menyambungkan yang pertama dan diam-diam mengabaikan dua lainnya. Begitulah cara pelanggan yang membayar berakhir terkunci dari sesuatu yang telah mereka bayar.

Ketiganya terpisah dari CONSUMPTION_REQUEST, satu-satunya pesan pengembalian dana yang meminta Anda membalas. Notifikasi pasca-keputusan tidak menginginkan perdebatan. Mereka menginginkan HTTP 200 dan perubahan yang tepat pada akses pelanggan. Inilah arti masing-masing, field persis yang membawa fakta, dan di mana uang bocor ketika Anda menanganinya dengan salah.

Empat notifikasi pengembalian dana, dan mana yang meminta balasan

App Store Server Notifications V2 adalah satu umpan tunggal. Anda mengarahkannya ke satu URL dan Apple mengirim setiap jenis notifikasi ke sana, jadi Anda sudah menerima keempat pesan pengembalian dana entah Anda menanganinya atau tidak. Empat dari jenis-jenis itu menyentuh pengembalian dana, dan hanya satu yang merupakan pertanyaan.

Apa yang sebenarnya disampaikan notifikasi REFUND kepada Anda

REFUND terpicu ketika App Store telah berhasil mengembalikan dana atas suatu transaksi kepada pelanggan. Ia berlaku untuk setiap jenis pembelian: consumable, non-consumable, langganan yang diperbarui otomatis, dan langganan yang tidak diperbarui. Transaksi tertanda tangan di dalam notifikasi sekarang membawa dua field yang tidak dimilikinya sebelum pengembalian dana, dan kedua field itu adalah keseluruhan ceritanya.

revocationDate dan revocationReason membawa fakta

revocationDate adalah waktu UNIX, dalam milidetik, saat App Store mengembalikan dana transaksi atau mencabutnya. revocationReason memberi tahu Anda kategori pengembalian dana, dan ia mengambil tepat dua nilai.

Keberadaan revocationDate pada suatu transaksi itu sendiri adalah penandanya. Jika Anda mengambil suatu transaksi kemudian dan ia memiliki revocationDate, pembelian itu telah dikembalikan dananya, ada notifikasi atau tidak. Baca alasannya bersamaan agar gelombang pengembalian dana bernilai 1 pada satu rilis tidak lolos dari Anda sebagai kebisingan.

Cabut berdasarkan transaksi, bukan berdasarkan produk

Jebakan di sini adalah mencabut terlalu banyak. REFUND menyebut satu transaksi. Ia tidak menyuruh Anda menonaktifkan setiap pembelian yang pernah dilakukan pelanggan atas id produk itu. Panduan Apple sendiri adalah memeriksa akses apa yang masih dimiliki pelanggan sebelum Anda memutus apa pun, karena hak-hak saling tumpang tindih. Kasus klasiknya adalah langganan: pengembalian dana jatuh pada perpanjangan bulan lalu sementara perpanjangan bulan ini aktif dan lunas. Cabut berdasarkan produk dan Anda baru saja memutus pelanggan yang membayar dan masih berjalan karena pengembalian dana untuk periode yang sudah berakhir.

REFUND_DECLINED berarti Anda sudah menang, jadi jangan batalkan itu

REFUND_DECLINED tiba ketika App Store menolak permintaan pengembalian dana pelanggan. Pelanggan meminta, Apple berkata tidak, dan Anda mempertahankan penjualan. Sekilas tidak ada yang perlu dilakukan, dan itulah intinya. Kesalahan yang diungkap notifikasi ini adalah kesalahan yang berbeda: mencabut akses terlalu dini.

Jika kode Anda bereaksi terhadap CONSUMPTION_REQUEST dengan mencabut akses pelanggan sebelum Apple memutuskan, REFUND_DECLINED adalah momen ketika keputusan itu meledak. Apple menahan uang Anda, dan Anda mengunci pelanggan yang pengembalian dananya ditolak. Pelanggan itu sekarang membayar untuk produk yang tidak bisa mereka gunakan, membuka tiket dukungan, dan mengingatnya. Perbaikannya adalah aturan, bukan fitur: cabut pada REFUND, jangan pernah pada permintaan. REFUND_DECLINED hanyalah Apple mengonfirmasi bahwa pencabutan dini akan menjadi keputusan yang salah.

REFUND_REVERSED adalah notifikasi yang membayar Anda kembali

REFUND_REVERSED adalah yang hampir tidak ada yang menanganinya, dan itulah yang mengembalikan uang kepada Anda. Apple mengirimnya ketika membalikkan pengembalian dana yang sebelumnya diberikannya, biasanya setelah pelanggan menyanggah pengembalian dana itu. Field pencabutan yang ditambahkan REFUND ke transaksi dihapus kembali, sehingga pembelian terbaca sebagai lunas lagi. Apple menyatakan tugas pengembang dalam satu baris: jika aplikasi Anda mencabut konten atau layanan sebagai akibat dari pengembalian dana terkait, ia perlu memulihkannya. Ia berlaku untuk jenis pembelian apa pun, dari consumable hingga langganan yang diperbarui otomatis.

Masalah beberapa minggu kemudian

Pertanyaan sebenarnya yang diangkat pengembang, di forum Apple sendiri, adalah waktu. REFUND_REVERSED bisa tiba berminggu-minggu setelah REFUND asli, jauh setelah periode langganan berakhir. Apakah Anda memulihkan akses saat itu? Pulihkan apa yang sebenarnya diberikan transaksi itu, dibatasi pada apa yang dicakup transaksi tersebut. Untuk consumable atau non-consumable, nyalakan kembali pembukaannya. Untuk periode langganan yang sudah berlalu, Anda tidak membagikan waktu baru, Anda mengoreksi catatan agar riwayat pelanggan akurat dan setiap hak yang masih berlaku aktif kembali. Pulihkan transaksi spesifik, dan logika tumpang tindih Anda yang memutuskan apa yang aktif saat ini.

Di mana uangnya jika menangani ini dengan benar

Masing-masing notifikasi ini memetakan ke angka nyata, dan biaya salah menanganinya bukan hanya harga penjualan.

REFUND: berhenti membayar untuk melayani pelanggan yang dananya dikembalikan

Harga penjualan hilang saat REFUND tiba. Yang masih bisa Anda kendalikan adalah biaya untuk terus mengirimkan layanan. Setiap jam sebuah hak yang dikembalikan dananya tetap aktif, Anda terus mengeluarkan biaya untuk hal-hal yang tidak lagi dibayar pelanggan: komputasi, panggilan API model, penyimpanan, dan pembayaran kreator atau mitra apa pun yang terkait dengan penggunaan mereka. Mencabut dengan cepat pada REFUND menghentikan meteran itu. Mengabaikan notifikasi berarti Anda mendanai sebuah produk untuk seseorang yang sudah dituntaskan oleh toko.

REFUND_DECLINED: jangan ubah kemenangan menjadi pengembalian dana niat baik

Ketika Anda mencabut terlalu dini dan pengembalian dana kemudian ditolak, Anda mempertahankan penjualan di atas kertas dan kehilangannya dalam praktik. Pelanggan yang membayar tidak bisa menggunakan produk, jadi Anda mewarisi percakapan dukungan dan, sering kali, pengembalian dana diskresioner untuk memperbaikinya. Itu membayar dua kali untuk satu penjualan yang tidak pernah dalam bahaya. Menangani REFUND_DECLINED dengan benar tidak memakan biaya apa pun, yang justru mengapa membiarkan akses tak tersentuh sampai REFUND adalah aturan termurah yang dapat Anda adopsi.

REFUND_REVERSED: pasangan terburuk adalah uang mereka dan akses mereka sama-sama hilang

Abaikan REFUND_REVERSED dan Anda mencapai hasil terburuk di papan. Anda telah dibayar, dan pelanggan tidak punya apa-apa. Mereka menghubungi bank sekali untuk membalikkan pengembalian dana, dan seseorang yang terkunci dari produk yang kini ditagih kepadanya adalah orang yang kemungkinan menghubungi bank untuk kedua kalinya. Sanggahan berikutnya itu bisa menjadi chargeback kartu, yang final di sisi bank dan memakan biaya lebih besar daripada penjualannya. Memulihkan akses saat REFUND_REVERSED tiba adalah asuransi termurah dalam seluruh alur pengembalian dana.

Apa yang harus disambungkan

Penanganannya kecil begitu modelnya benar. Kunci hak pada id transaksi agar setiap notifikasi menunjuk ke satu pembelian. Pada CONSUMPTION_REQUEST, kirim data Anda dalam 12 jam. Pada REFUND, cabut transaksi itu. Pada REFUND_DECLINED, jangan lakukan apa pun. Pada REFUND_REVERSED, pulihkan. Kembalikan HTTP 200 dengan cepat pada semuanya dan lakukan perubahan akses pada waktu Anda sendiri.

Untuk celah yang ditinggalkan notifikasi, gunakan endpoint Get Refund History. Jika server Anda mati saat pemadaman dan melewatkan sebuah REFUND, panggil pencarian pengembalian dana App Store Server API untuk sebuah id transaksi, di /inApps/v2/refund/lookup/{transactionId}, dan baca kembali transaksi tertanda tangan dengan revocationDate dan revocationReason mereka. Ia merekonsiliasi satu transaksi sekaligus dan membuka halaman melalui pembelian yang dikembalikan dananya milik pelanggan, sehingga webhook yang terlewat tidak menjadi hak yang salah setelan secara permanen.

Inilah bagian yang dijalankan RefundHalt untuk Anda. Ia mendengarkan keempat jenis, mencabut pada REFUND, menahan akses tak tersentuh pada REFUND_DECLINED, dan memulihkan secara otomatis pada REFUND_REVERSED, masing-masing dikunci ke transaksi yang persis. Pengembalian dana yang dibalikkan tidak terduduk di antrean sementara pelanggan yang membayar tetap terkunci, dan yang ditolak tidak pernah memicu pencabutan yang harus Anda tarik kembali.