Ada satu endpoint yang mengembalikan seluruh riwayat refund App Store milik seorang pelanggan, dan inilah yang diberikannya

Apple menyimpan catatan yang dapat dikueri atas setiap refund yang telah diberikannya pada akun seorang pelanggan untuk aplikasi Anda, dan satu panggilan mengembalikannya. Endpoint-nya adalah Get Refund History, bagian dari App Store Server API, dan ia memberi Anda riwayat refund App Store lengkap milik pelanggan itu sebagai daftar transaksi bertanda tangan. Anda mengirim sebuah id transaksi, Anda menerima kembali apa yang di-refund Apple, dan Anda merekonsiliasinya terhadap apa yang masih Anda aktifkan.

Inilah alasan mengapa Anda perlu repot. Sebuah refund yang tidak pernah Anda lihat adalah refund yang terus Anda bayar. Uangnya sudah hilang, tetapi akun tetap aktif, dan setiap jam ia begitu Anda terus mengeluarkan biaya untuk komputasi, panggilan model API, penyimpanan, dan pembayaran apa pun yang terkait dengan pelanggan itu. Notifikasi refund Anda dimaksudkan untuk menangkap ini saat ia terjadi. Get Refund History adalah pengaman untuk saat mereka gagal, setelah gangguan, sebuah deploy yang menjatuhkan webhook, atau sebuah kasus dukungan tempat Anda butuh gambaran utuh dalam satu panggilan.

Apa yang dikembalikan endpoint riwayat refund App Store

Anda memanggil GET /inApps/v2/refund/lookup/{transactionId} terhadap App Store Server API, ditandatangani dengan JWT yang sama seperti setiap panggilan lain kepadanya. Id transaksi dalam path bisa berupa transaksi apa pun milik pelanggan. Apple membacanya sebagai identitas, bukan filter, dan mengembalikan pembelian pelanggan itu yang telah di-refund di seluruh aplikasi Anda: consumable, non-consumable, langganan yang diperpanjang otomatis maupun yang tidak diperpanjang, semuanya. Versi V1 lama dari endpoint ini mengembalikan hingga 50 refund dalam satu respons dan sudah tidak digunakan lagi. Versi saat ini melakukan paginasi, sehingga Anda menangani pelanggan dengan riwayat panjang tanpa payload raksasa.

Respons terdiri dari tiga field

Apa yang diberitahukan satu transaksi yang di-refund

Setiap entri di signedTransactions adalah sebuah JWS. Verifikasi terhadap rantai sertifikat Apple, dekode, dan Anda punya payload transaksi biasa dengan field refund yang terisi. Inilah yang penting di sini.

Token revision adalah cara Anda berhenti membaca ulang seluruh daftar

Cara naif menggunakan endpoint ini adalah mencari seorang pelanggan dan menelusuri setiap halaman setiap kali. Itu berhasil, dan pada pelanggan dengan lima puluh refund itu adalah lima puluh baris yang sudah Anda ketahui ditambah satu yang baru. Token revision ada untuk menghapus pemborosan itu. Setiap respons membawa sebuah revision. Saat hasMore bernilai true, Anda mengirimkannya kembali untuk mendapatkan halaman berikutnya. Saat Anda mencapai akhir, Anda menyimpan revision terakhir yang Anda lihat.

Apa yang tidak akan dilakukan endpoint ini

Ada satu ekspektasi yang harus Anda buang sebelum membangun di atasnya. Get Refund History bersifat per pelanggan, bukan per aplikasi. Anda tidak bisa memintanya setiap refund yang diterima aplikasi Anda minggu lalu. Ia menjawab satu pertanyaan, refund mana yang dimiliki akun ini, dan Anda harus datang dengan sebuah id transaksi untuk akun itu untuk menanyakannya. Developer terus-menerus menabrak dinding ini dan pergi mencari endpoint refund seluruh aplikasi yang tidak ada.

Tampilan seluruh aplikasi berada di tempat lain. Feed App Store Server Notifications Anda mengirim sebuah notifikasi REFUND saat Apple memberikan masing-masing, dan Get Notification History memungkinkan Anda memutar ulang feed itu yang difilter ke jenis refund pada suatu rentang tanggal. Jadi pembagiannya bersih. Notifikasi dan riwayatnya memberi Anda aliran seluruh aplikasi. Get Refund History memberi Anda daftar otoritatif satu akun, sesuai permintaan, yang persis Anda inginkan di meja dukungan atau setelah gangguan.

Berapa biaya sebuah refund yang terlewat dalam uang

Endpoint adalah pipa. Tagihannya adalah alasan Anda memasang pipa. Setiap refund dalam daftar itu adalah uang yang sudah dikembalikan, dan satu-satunya variabel yang tersisa dalam kendali Anda adalah berapa lama Anda terus mengeluarkan biaya untuk akun yang tidak lagi membayar.

Anda terus membayar untuk melayani akun yang di-refund

Harga pembelian hilang seketika Apple memberikan refund. Yang terus berjalan adalah biaya pengiriman. Untuk aplikasi yang melakukan pekerjaan nyata per pengguna, itu adalah komputasi, panggilan model API, penyimpanan, dan pembayaran kreator atau mitra apa pun yang terkait dengan penggunaan mereka. Pelanggan yang di-refund yang aksesnya tidak pernah Anda putus adalah langganan yang Anda danai dari kantong sendiri. Merekonsiliasi terhadap Get Refund History dan mencabut berdasarkan apa yang Anda temukan adalah cara Anda mematikan meteran itu saat sebuah notifikasi terlewat.

Alasan refund 1 adalah laporan cacat yang menyamar

revocationReason menelan biaya dua kali jika Anda mengabaikannya. Biaya pertama adalah refund itu sendiri. Yang kedua adalah setiap refund mendatang dari penyebab yang sama. Ketika sebuah produk terus kembali dengan revocationReason 1, sebuah masalah nyata atau yang dirasakan pada aplikasi Anda, Apple sedang menyerahkan kepada Anda sampel berlabel tentang apa yang membuat pelanggan meminta uang mereka kembali. Buat trennya per produk dan Anda dapat memperbaiki kebocoran alih-alih membayarnya satu refund pada satu waktu.

Menangkapnya terlambat tetap lebih baik daripada tidak menangkapnya

Sebuah chargeback bersifat final dengan bank dan, di toko yang lain, kini membawa biaya yang ditanggung developer. Sebuah refund App Store bukan itu. Ia sudah selesai, tetapi entitlement adalah milik Anda untuk dicabut saat Anda mengetahuinya. Jadi bahkan sebuah refund yang Anda temukan terlambat beberapa hari melalui endpoint ini pantas ditemukan. Anda tidak bisa menarik kembali uangnya, tetapi Anda bisa menghentikan pengeluaran yang masih berjalan di belakangnya.

Bagaimana ini cocok dengan notifikasi, dan dengan Google

Anggap potongan-potongan itu sebagai satu sistem. Notifikasi REFUND adalah sinyal langsung, didorong ke server Anda saat Apple memutuskan. Get Refund History adalah sumber kebenaran berbasis tarik untuk satu pelanggan, panggilan yang Anda buat saat push gagal atau saat seorang manusia butuh akun lengkap di depannya. Di sisi Google Play bentuknya adalah ide yang sama dengan nama berbeda: sebuah VoidedPurchaseNotification didorong secara real time, dan Voided Purchases API adalah daftar yang Anda tarik. Kedua toko memberi Anda sebuah aliran dan sebuah buku besar. Kesalahannya adalah hanya mempercayai aliran, karena aliran bisa terputus.

Memasangnya dengan cara RefundHalt

Loop-nya kecil begitu setiap potongan sudah pada tempatnya. Ambil sebuah notifikasi REFUND sebagai pemicu. Rekonsiliasi terhadap Get Refund History agar webhook yang terjatuh tidak pernah membiarkan akun yang di-refund tetap aktif. Dekode setiap transaksi, kunci pada appAccountToken atau transactionId kembali ke pengguna Anda, baca revocationReason agar refund cacat ditandai dan bukan sekadar diarsipkan, dan cabut entitlement yang persis, bukan seluruh akun. Lakukan paginasi dengan token revision agar Anda membaca refund baru, bukan yang lama.

Inilah bagian yang dijalankan RefundHalt untuk Anda. Ia mendengarkan notifikasi refund, mundur ke Get Refund History saat butuh daftar otoritatif, memverifikasi setiap transaksi bertanda tangan, mencabut pembelian yang tepat, dan menyimpan revision agar setiap lintasan hanya membaca apa yang berubah. Anda mendapat akses yang diputus dalam hitungan detik dan catatan bersih tentang siapa yang di-refund, untuk apa, dan mengapa, tanpa Anda sendiri harus menyiapkan polling dan verifikasi JWS.