Mencabut Akses Setelah Refund: Langkah yang Tidak Diambil Apple dan Google untuk Anda

Menyetujui refund dan mencabut akses adalah dua langkah yang terpisah, dan hanya salah satunya yang terjadi secara otomatis. Developer yang menganggap refund yang sudah diproses berarti pembelian sudah dicabut aksesnya keliru di kedua toko besar, dengan cara dan alasan yang berbeda. Mengetahui persis di mana otomatisasi berhenti adalah yang dibutuhkan untuk mencabut akses setelah refund, alih-alih baru menyadarinya berbulan-bulan kemudian bahwa hal itu tidak pernah terjadi.

Mengapa refund tidak secara default mencabut akses

Apple dan Google sama-sama memperlakukan uang dan akses sebagai dua operasi yang berbeda. Sisi uang adalah kebijakan toko, begitu refund disetujui, statusnya final dan buku besar diperbarui. Sisi akses bersifat opsional, atau menjadi tugas developer, atau keduanya, tergantung pada platform dan jenis pembelian. Tidak ada toko yang berasumsi Anda ingin akses langsung hilang begitu refund selesai diproses, karena banyak kasus yang sah (refund sebagian, kredit itikad baik, gestur dukungan pelanggan) yang memang tidak dimaksudkan untuk mengambil kembali produknya sama sekali.

Google Play: kotak centang yang tidak disadari siapa pun

Di Play Console, me-refund sebuah pesanan adalah formulir dua bagian, pilih jumlah refund, lalu tentukan secara terpisah apakah akan mencentang "Remove entitlement". Membiarkannya tidak tercentang adalah jalur default yang diambil sebagian besar agen support, karena kebanyakan permintaan refund adalah gestur itikad baik di mana pelanggan tetap memiliki apa yang mereka beli. Masalahnya, tidak ada apa pun di layar konfirmasi refund yang memberi tahu Anda bahwa ini juga cara pelanggan tetap memiliki subscription atau item in-app setelah refund yang seharusnya Anda maksudkan sebagai final.

Jalur API memiliki jebakan yang sama

Pilihan yang sama ada di dalam kode. Endpoint orders.refund menerima parameter query revoke yang bersifat opsional, ketika nilainya true, akses ke item tersebut langsung dihentikan, dan untuk subscription berulang, setiap pembayaran di masa depan juga ikut dibatalkan. Jika parameter ini dihilangkan, nilainya default ke false, refund tetap diproses, catatan pembelian diperbarui, dan pengguna tetap dapat menggunakan produk persis seperti sebelumnya.

Baris terakhir itulah yang menjebak banyak integrasi. Voided Purchases API dibuat agar Anda bisa membangun pipeline revocation tanpa harus memeriksa Play Console secara manual, tetapi API ini hanya mendaftar pesanan yang benar-benar dibatalkan dengan revocation. Refund yang diproses tanpa kotak centang itu, atau tanpa revoke=true, memang sengaja tidak terlihat oleh feed tersebut, bukan karena bug.

Membaca field voidedReason Ketika sebuah pembelian memang muncul sebagai voided, field voidedReason memberi tahu Anda alasannya, dalam skala sembilan nilai: other, remorse, not_received, defective, accidental_purchase, fraud, friendly_fraud, chargeback, dan unacknowledged_purchase. Itu bukan sekadar pencatatan. Remorse dan accidental_purchase adalah refund biasa. Fraud, friendly_fraud, dan chargeback adalah nilai-nilai yang layak diarahkan ke antrean review fraud, bukan ke jalur revoke-and-forget biasa, karena akun yang sama secara statistik lebih mungkin mengulanginya.

Ada satu detail operasional yang penting jika Anda membangun sistem langsung di atas feed ini, purchases.voidedpurchases.list dibatasi hingga 6.000 query per hari dan 30 query dalam jendela 30 detik mana pun. Desain yang melakukan polling dalam loop ketat akan cepat mencapai batas itu. Pola yang dimaksudkan adalah pull terjadwal dengan pagination token, bukan polling terus-menerus.

Apple: App Store dapat mencabut lisensi, tetapi tidak untuk consumable

App Store Server Notifications V2 milik Apple mengirimkan notifikasi REFUND begitu sebuah refund selesai diproses, baik untuk consumable, non-consumable, subscription auto-renewable, maupun subscription non-renewing. Apa yang terjadi setelah notifikasi itu sepenuhnya bergantung pada jenis pembeliannya, karena mekanisme revocation milik StoreKit sendiri hanya mencakup dua dari empat jenis tersebut.

Mengapa consumable menjadi pengecualian

Non-consumable atau subscription memiliki entitlement yang tetap ada dan bisa dimatikan oleh sistem Apple. Consumable tidak demikian, begitu digunakan, ia dianggap sudah terkirim, dan tidak ada lagi yang tersisa di StoreKit untuk dicabut. Jika seorang pelanggan membeli 500 coins, menghabiskannya, lalu mendapatkan refund, coins tersebut sudah dianggap tuntas dari sudut pandang Apple. Satu-satunya buku besar yang masih mencatatnya adalah milik Anda. Notifikasi REFUND adalah satu-satunya sinyal bagi Anda untuk menemukan original transaction ID yang cocok dan mengurangi saldo tersebut dari catatan Anda sendiri, tidak ada apa pun di sisi Apple yang akan melakukannya untuk Anda.

Notifikasi yang hampir tidak pernah ditangani siapa pun

REFUND_REVERSED adalah notifikasi yang paling sering diabaikan sepenuhnya oleh kebanyakan integrasi, karena ia menggambarkan Apple membatalkan keputusannya sendiri, sebuah kasus yang jarang dirancang oleh developer sejak awal. Ketika notifikasi ini tiba, revocationDate pada transaksi tersebut kembali menjadi null, sejauh yang Apple ketahui, pembelian itu kembali sah. Jika server Anda menghapus entitlement, membatalkan catatan subscription, atau menolkan saldo consumable saat REFUND awal masuk, REFUND_REVERSED adalah sinyal untuk mengembalikan semuanya.

Cara menutup celah ini, langkah demi langkah

• Di Google Play, jadikan revoke=true sebagai default untuk setiap jalur refund, baik melalui Play Console maupun API, kecuali ada kasus support tertentu yang memang mengharuskan pelanggan tetap memiliki akses.
• Lakukan polling purchases.voidedpurchases.list secara terjadwal dengan pagination token, bukan dalam loop ketat, dan tetap di bawah 6.000 request per hari serta 30 per 30 detik.
• Arahkan nilai voidedReason berupa fraud, friendly_fraud, dan chargeback ke antrean review, bukan ke revoke-and-close otomatis.
• Di Apple, berlangganan App Store Server Notifications V2 dan cabut akses non-consumable serta subscription begitu notifikasi REFUND menyebutkannya.
• Simpan original transaction ID untuk setiap pembelian consumable agar notifikasi REFUND bisa menemukan saldo yang tepat untuk dikurangi tanpa pencarian manual.
• Tangani REFUND_REVERSED secara eksplisit dan catat setiap revocation berdasarkan transaction atau order ID-nya, agar pembatalan dapat memulihkan persis apa yang telah dihapus.

Apa sebenarnya biaya dari celah ini

Semua ini bukan soal keadilan bagi pelanggan, ini soal apa yang tetap berjalan setelah uangnya sudah hilang. Subscription yang sudah di-refund tetapi masih memanggil API Anda, menyimpan data, dan menghabiskan compute bukanlah masalah moral, itu adalah pos biaya, Anda membayar tagihan infrastruktur untuk pembelian yang pendapatannya sudah Anda kembalikan. Toko tidak melacak biaya itu untuk Anda, karena dari sisi mereka, refund sudah selesai begitu uangnya berpindah. Sisi akses sepenuhnya menjadi tagihan yang harus Anda kendalikan sendiri.

Inilah alasan yang sama mengapa RefundHalt memperlakukan revocation sebagai bagian dari pipeline refund, bukan sebagai renungan belakangan, sebuah event REFUND dan perubahan akses dicatat sebagai satu tindakan, dan sebuah event REFUND_REVERSED memulihkan state secara otomatis, alih-alih menunggu seseorang menyadari bahwa pelanggan masih terkunci dari sesuatu yang sudah dikembalikan oleh Apple.