Apple dapat membatalkan pengembalian dana yang sudah diberikannya, dan pengembalian dana yang dibatalkan yang diabaikan server Anda mengunci pelanggan yang telah membayar

Pengembalian dana tidak selalu menjadi keputusan akhir. App Store dapat membatalkan pengembalian dana yang sudah diberikannya, setelah pelanggan menyengketakannya, dan saat pengembalian dana yang dibatalkan itu tiba di server Anda, ia membawa satu instruksi: kembalikan aksesnya. Sebagian besar tim menyambungkan notifikasi REFUND biasa, memutus akses pelanggan, dan berhenti di situ. Mereka tidak pernah membangun separuh lainnya. Jadi saat pembatalan tiba, tidak ada yang berjalan, dan pelanggan yang membayar lagi tetap terkunci dari apa yang mereka beli. Berikut cara kerja rangkaian lengkap notifikasi pengembalian dana di App Store dan Google Play, serta biaya masing-masing saat Anda mengabaikannya.

App Store mengirim tiga notifikasi pengembalian dana, bukan satu

Sebagian besar penanganan pengembalian dana dibangun untuk satu peristiwa: uang telah dikembalikan, putus akses pelanggan. Umpan App Store Server Notifications V2 sebenarnya membawa tiga hasil pengembalian dana yang terpisah, dan ketiganya meminta tiga hal yang berbeda. Dua di antaranya mengubah apa yang bisa diakses pelanggan. Satu di antaranya membatalkan yang pertama. Berikut rangkaian lengkapnya, dalam kata-kata Apple sendiri.

REFUND, yang ditangani setiap tim

Saat App Store memproses pengembalian dana, ia mengirim notifikasi REFUND ke URL yang Anda konfigurasikan, dan definisi Apple jelas: 'menunjukkan bahwa App Store berhasil mengembalikan dana suatu transaksi untuk In-App Purchase yang dapat dikonsumsi, In-App Purchase yang tidak dapat dikonsumsi, langganan yang diperpanjang otomatis, atau langganan yang tidak diperpanjang.' Anda menyimpan transaksi yang dikembalikan dananya, mencabut apa pun yang dibelinya, dan Apple meminta Anda memberi tahu pelanggan apa yang berubah melalui pesan kontekstual di dalam aplikasi. Ini adalah notifikasi yang pertama kali disambungkan semua orang, dan sering kali satu-satunya.

REFUND_DECLINED, yang tidak membutuhkan apa pun dari Anda

REFUND_DECLINED berarti persis seperti yang dikatakannya: 'App Store menolak permintaan pengembalian dana.' Pelanggan meminta, Apple menolak, dan transaksi tetap berlaku. Tidak ada yang berubah tentang akses pelanggan, jadi logika hak akses Anda tidak melakukan apa pun di sini. Nilai notifikasi ini adalah pencatatan. Ia menutup lingkaran atas permintaan pengembalian dana yang mungkin telah Anda jawab dengan CONSUMPTION_REQUEST, dan mengonfirmasi bahwa pelanggan masih memiliki apa yang mereka bayar. Perlakukan sebagai catatan, bukan tindakan.

REFUND_REVERSED, yang membuat tim lengah

Ini adalah notifikasi yang tidak pernah ditangani sebagian besar pipeline pengembalian dana. Definisi Apple tidak ambigu: REFUND_REVERSED 'menunjukkan App Store membatalkan pengembalian dana yang sebelumnya diberikan karena sengketa yang diajukan pelanggan. Jika aplikasi Anda mencabut konten atau layanan akibat pengembalian dana terkait, ia perlu memulihkannya.' Baca itu dua kali. Apple memberi pelanggan pengembalian dana, Anda mencabut akses, lalu Apple memutuskan pengembalian dana itu tidak boleh berlaku dan menariknya kembali. Tagihannya aktif lagi. Pelanggan telah membayar, dan jika server Anda hanya tahu cara mencabut, mereka tetap terkunci. Pengembalian dana yang dibatalkan adalah satu-satunya peristiwa pengembalian dana yang menambahkan akses kembali, dan itu adalah yang hampir tidak ada orang membangunnya.

Berapa biaya sebenarnya dari pengembalian dana yang dibatalkan

Pembatalan yang terlewat bukanlah kesalahan pembulatan. Telusuri uang di kedua arah, karena salah menangani salah satu separuhnya memiliki harga.

Lewatkan pembatalannya dan Anda membiarkan pelanggan yang membayar tetap terkunci. Apple telah memulihkan tagihannya, jadi pelanggan kembali merugi, dan aplikasi Anda menolak memberi mereka hal yang mereka beli. Biaya langsungnya adalah waktu dukungan dan pengembalian dana niat baik yang mungkin kini Anda terbitkan sendiri, kali ini tanpa komisi toko yang kembali untuk meringankannya. Biaya yang lebih lambat adalah ulasan dan churn, dan di Google Play frustrasi terkunci yang sama itulah yang berubah menjadi chargeback.

Lewatkan pengembalian dana yang asli dan Anda terus melayani pelanggan yang tidak membayar apa pun. Kesalahan cerminnya adalah tidak pernah mencabut sama sekali. Pelanggan yang telah dikembalikan dananya yang masih menghasilkan gambar, memanggil API Anda, dan memenuhi penyimpanan Anda menimbulkan biaya nyata terhadap penjualan yang dibatalkan. Komputasi, panggilan pihak ketiga, dan penyimpanan adalah uang yang sudah Anda keluarkan, dan tidak satu pun kembali bersama pengembalian dana.

• Biaya dukungan: seorang manusia menjawab tiket untuk akses yang dihapus kode Anda sendiri dan tidak pernah dipulihkan.
• Pengembalian dana niat baik: menerbitkan kembali uang kepada pelanggan yang keliru Anda kunci, tanpa komisi toko yang dikembalikan atas gestur manual.
• Pengeluaran sia-sia: komputasi, panggilan API, dan penyimpanan yang dikonsumsi oleh akun yang telah dikembalikan dananya yang tidak pernah Anda putus.
• Risiko chargeback: di Google Play, pelanggan yang merasa ditagih dua kali dapat menyengketakan, dan sengketa yang kalah kini menjadi tanggungan Anda.

Pengembalian dana yang dibatalkan dan pengembalian dana biasa adalah umpan webhook yang sama menunjuk ke arah berlawanan. Tangani yang satu dan lewati yang lain dan Anda membayar di kedua ujung.

Mengapa Apple membatalkan pengembalian dana, dan cara membaca revocationReason

Pembatalan tidaklah acak. Apple mengaitkannya dengan 'sengketa yang diajukan pelanggan', yaitu pelanggan menantang keputusan pengembalian dana setelah kejadian. Saat pengembalian dana pertama kali diberikan, transaksi membawa revocationDate dan revocationReason, dan alasan itu layak dibaca sebelum apa pun di hilir bertindak atasnya.

• revocationReason 1: App Store mengembalikan dana 'karena masalah nyata atau yang dirasakan di dalam aplikasi Anda.' Itu adalah sinyal tentang produk Anda, bukan hanya pelanggan ini.
• revocationReason 0: App Store mengembalikan dana 'karena alasan lain, misalnya pembelian yang tidak disengaja.' Tidak ada sinyal kualitas aplikasi yang menyertai.

Saat REFUND_REVERSED tiba untuk transaksi itu, pencabutan sedang dibatalkan. Logika pemulihan Anda harus mencari id transaksi asli, mengonfirmasi bahwa Anda mencabutnya, dan mengembalikan hak akses persis seperti semula.

Google Play tidak mengirim pembatalan, jadi Anda merekonsiliasi sebagai gantinya

Model Google Play berbeda, dan perbedaannya penting jika Anda menjalankan kedua toko melalui satu penangan webhook. Tidak ada padanan Google untuk REFUND_REVERSED. Notifikasi developer real-time Google membagi peristiwa pengembalian dana menjadi dua pesan, dan pembatalan ditangani melalui rekonsiliasi, bukan push.

Notifikasi pembelian yang dibatalkan

Saat sebuah pembelian Google Play dibatalkan, server Anda menerima VoidedPurchaseNotification. Ia menyebutkan purchaseToken dan orderId, productType berupa subscription atau one-time, dan refundType yang berupa pembatalan penuh atau pengembalian dana parsial berbasis kuantitas pada pembelian multi-kuantitas. Google mengatakan data itu cukup untuk menemukan pembelian yang tepat dan menyesuaikan hak akses. Untuk apa pun yang lebih, ia mengarahkan Anda ke Voided Purchases API, sebuah model pull yang mendaftar pesanan yang dibatalkan dalam rentang timestamp yang Anda kueri.

Tinjauan chargeback, dan penghitung waktu 24 jamnya

Chargeback datang melalui pesan yang berbeda, PendingRefundReviewNotification. Saat pelanggan menyengketakan tagihan dengan bank mereka, Google Play mengirim notifikasi ini dan memulai penghitung waktu. Anda memiliki 24 hours untuk memanggil orders.reviewrefund dengan preferensi pengembalian dana dan bukti penggunaan apa pun, sehingga Google dapat menyanggah chargeback yang tidak sah atas nama Anda. Google mencatat panggilan pertama Anda dan mengabaikan sisanya. Ini adalah paralel Google terhadap CONSUMPTION_REQUEST milik Apple, satu-satunya jendela di mana pihak Anda dalam sengketa diperhitungkan.

Karena tidak ada push pembatalan, chargeback yang disanggah dan dimenangkan Google tidak tiba sebagai peristiwa pemulihan yang rapi. Anda merekonsiliasinya terhadap Voided Purchases API dan catatan Anda sendiri. Pelajarannya sama seperti di App Store: pesanan yang dibatalkan tidak selalu permanen, dan status hak akses Anda harus dapat bergerak mundur, bukan hanya maju.

Cara menangani setiap notifikasi pengembalian dana tanpa mengunci siapa pun

Anda tidak memerlukan pipeline terpisah per toko. Anda memerlukan penangan yang dapat memindahkan hak akses ke kedua arah dan memperlakukan setiap pesan sebagai kemungkinan duplikat.

• Bangun pemulihan, bukan hanya pencabutan. Untuk setiap jalur yang menghapus akses pada REFUND, tulis kebalikannya yang memulihkannya pada REFUND_REVERSED, dikaitkan ke id transaksi yang sama.
• Buat idempoten. Kedua toko dapat mengirimkan notifikasi yang sama lebih dari sekali, jadi kaitkan setiap pencabutan dan pemulihan ke id transaksi atau pesanan dan buat pengulangan tidak menghasilkan efek apa pun.
• Baca alasannya sebelum bertindak. Gunakan revocationReason untuk membedakan pengembalian dana karena kualitas aplikasi dari yang tidak disengaja, dan arahkan yang terkait kualitas aplikasi ke siapa pun yang memiliki kualitas produk.
• Jawab jendela bukti tepat waktu. Kirim data konsumsi Apple dalam 12 hours sejak CONSUMPTION_REQUEST, dan panggil orders.reviewrefund dalam 24 hours sejak PendingRefundReviewNotification.
• Simpan setiap peristiwa. Simpan REFUND_DECLINED dan notifikasi mentah, sehingga pembatalan yang tiba kemudian dapat dicocokkan dengan pengembalian dana yang dibatalkannya.

Tidak satu pun dari ini mengubah apakah pengembalian dana terjadi. Yang diubahnya adalah apakah pelanggan di sisi lain dari pengembalian dana yang dibatalkan pernah menyadari bahwa server Anda salah menanganinya.