Fitur Send Consumption Information dari Apple kini meminta lima kolom, bukan dua belas, dan inilah masing-masingnya

Daftar fakta yang diminta Apple dari Anda saat pelanggan menginginkan pengembalian dana menjadi jauh lebih pendek. Payload Send Consumption Information, satu-satunya jawaban yang boleh dikirim pengembang ke dalam keputusan pengembalian dana App Store, dulu memiliki dua belas kolom. Kini hanya lima. Apple memangkasnya sekitar WWDC24 dan meleburkan sebagian besar pertanyaan pemrofilan akun lama menjadi dua pertanyaan sederhana dan satu angka. Lebih sedikit kolom bukanlah suntingan kecil. Itu mengubah bukti apa yang ditimbang Apple, dan mengubah kolom mana yang tidak boleh Anda isi keliru.

Inilah alasan mengapa ini layak diperhatikan dan bukan sekadar catatan skema. Payload ini adalah satu-satunya momen dalam pengembalian dana Apple ketika versi cerita dari pihak Anda sampai ke keputusan. Pengembalian dana barang habis pakai membatalkan pendapatan yang sudah Anda keluarkan dengan uang sungguhan untuk mengirimkannya, dan lima kolom itu adalah cara Anda memberi tahu Apple bahwa produk telah dikirim dan digunakan. Lewatkan jendela 12 jam atau isi satu kolom secara keliru, dan Apple memutuskan hanya berdasarkan klaim pelanggan.

Apa itu Send Consumption Information

Send Consumption Information adalah endpoint App Store Server API yang Anda panggil setelah Apple mengirimkan notifikasi CONSUMPTION_REQUEST ke server Anda. Notifikasi itu berarti seorang pelanggan meminta pengembalian dana kepada Apple atas pembelian dalam aplikasi dan Apple menginginkan masukan Anda sebelum memutuskan. Anda menjawabnya dengan mengirimkan sebuah body JSON kecil, yaitu ConsumptionRequest, ke endpoint tersebut dengan PUT. Apple membacanya, menimbangnya terhadap riwayat pelanggan, dan membuat keputusan. Anda tidak pernah memutuskan pengembalian dana. Anda menyediakan fakta.

Body itu adalah keseluruhan antarmuka. Tidak ada formulir terpisah, tidak ada banding, dan tidak ada pengiriman kedua yang diperhitungkan. Apa pun yang Anda kirim dalam satu payload itu adalah keseluruhan kasus Anda, jadi makna setiap kolom lebih penting daripada yang disiratkan oleh jumlah kolomnya.

Lima kolom yang diminta Apple sekarang

ConsumptionRequest saat ini memiliki lima anggota. Tiga wajib dan dua opsional. Semua yang dulu ditanyakan Apple tentang akun pelanggan, masa berlangganannya, total belanja seumur hidupnya, total pengembalian dana seumur hidupnya, waktu bermainnya, telah dihapus dari apa yang Anda kirim.

customerConsented adalah gerbangnya

customerConsented adalah Boolean, dan itu adalah kolom yang menentukan apakah Anda mengirim sesuatu sama sekali. Kolom itu mencatat apakah pelanggan setuju mengizinkan Anda membagikan data konsumsi dengan Apple. Panduan Apple jelas: jika pelanggan tidak menyetujui, jangan kirim informasi konsumsi. Jadi ini bukan kolom yang Anda ubah menjadi true untuk memperkuat kasus Anda. Kolom ini mencerminkan ya atau tidak yang sesungguhnya yang harus sudah Anda pegang, dan nilai false di sini berarti sisa payload sebaiknya tidak dikirim.

deliveryStatus adalah kolom yang menggerakkan pengembalian dana

deliveryStatus adalah enum string, dan itu adalah tuas terkuat yang Anda miliki. Kolom itu memberi tahu Apple apakah aplikasi Anda benar-benar mengirimkan pembelian dalam aplikasi yang berfungsi. Satu nilai berkata ya. Empat nilai lainnya berkata tidak, masing-masing dengan alasan berbeda, dan masing-masing memberi tahu Apple bahwa pelanggan memiliki keluhan yang sah.

sampleContentProvided menjawab pertanyaan keadilan

sampleContentProvided adalah Boolean. Kolom itu mencatat apakah Anda memberi pelanggan sampel gratis, uji coba, atau informasi yang jelas tentang apa yang dilakukan pembelian sebelum mereka membelinya. Nilai true di sini adalah sinyal keadilan kecil: pelanggan punya kesempatan untuk tahu apa yang mereka beli. Kolom ini tidak memutuskan apa pun dengan sendirinya, tetapi ini salah satu dari hanya tiga kolom wajib, jadi Apple jelas menginginkannya dalam setiap jawaban.

consumptionPercentage kini sebuah angka, bukan status

Inilah kolom yang paling banyak berubah. Payload lama memiliki consumptionStatus, sebuah enum empat tingkat: UNDECLARED, NOT_CONSUMED, PARTIALLY_CONSUMED, FULLY_CONSUMED. Payload baru menggantinya dengan consumptionPercentage, sebuah integer yang diukur dalam milliunits. 100,000 milliunits berarti barang telah dikonsumsi sepenuhnya, jadi 50,000 adalah setengah dan 0 adalah belum tersentuh. Angka yang presisi lebih baik daripada empat kotak, karena memungkinkan Anda mengatakan seorang pelanggan menghabiskan 90 persen paket kredit alih-alih membulatkan ke bawah menjadi terkonsumsi sebagian.

Satu peringatan yang sering menjebak orang. Untuk langganan yang diperpanjang otomatis, Apple menghitung sendiri konsumsi dari waktu yang telah berlalu, jadi consumptionPercentage ditujukan untuk pembelian habis pakai dan yang tidak diperpanjang. Kirimkan di tempat yang berlaku, dan biarkan Apple menurunkannya di tempat yang tidak berlaku.

refundPreference menyatakan preferensi, bukan vonis

refundPreference adalah string opsional, dan di situlah Anda memberi tahu Apple hasil apa yang Anda inginkan. Kolom ini juga berubah bentuk. Kolom lama adalah angka dengan nilai seperti prefer-grant, prefer-decline, dan no-preference. Yang baru adalah string bernama dengan tiga nilai.

Apa yang dibuang Apple, dan mengapa itu penting

ConsumptionRequest lama memiliki dua belas kolom. Tujuh di antaranya hilang dari apa yang Anda kirim. accountTenure, lifetimeDollarsPurchased, lifetimeDollarsRefunded, playTime, userStatus, platform, dan appAccountToken adalah paruh pemrofilan akun dari payload, yaitu kolom-kolom yang meminta Anda mengelompokkan pelanggan berdasarkan berapa lama mereka punya akun, berapa banyak yang mereka belanjakan, berapa banyak yang telah dikembalikan kepada mereka, dan berapa lama mereka menggunakan aplikasi.

Apple memangkasnya dengan alasan yang patut dicatat. Kolom-kolom itu meminta pengembang menyerahkan profil pelanggan, dan sebagian besar pengembang entah membiarkannya tidak diisi atau menebak. Lima yang tersisa berkaitan dengan pembelian dan pengiriman, fakta yang benar-benar dapat Anda verifikasi dari sistem Anda sendiri. Pergeserannya adalah dari siapa pelanggan itu menjadi apa yang terjadi pada pembelian spesifik ini.

Endpoint dan jamnya

Anda mengirim payload dengan HTTP PUT ke endpoint Send Consumption Information, dikunci dengan id transaksi pembelian yang disengketakan: PUT /inApps/v1/transactions/consumption/{transactionId}. Keberhasilan mengembalikan 202 Accepted, dan body jawabannya kosong. Jawaban kosong itu memang diharapkan, bukan bug. Itu mengonfirmasi bahwa Apple mengantrekan data Anda, dan tidak memberi tahu apa pun tentang hasil akhirnya, yang datang kemudian sebagai notifikasi REFUND atau REFUND_DECLINED.

Jam adalah bagian yang tidak dapat Anda ulur. Apple memberi Anda 12 jam sejak CONSUMPTION_REQUEST untuk menjawab. Hanya jawaban pertama Anda yang digunakan, jadi payload pertama harus lengkap dan benar. Apple dapat mengirim CONSUMPTION_REQUEST lebih dari sekali untuk pembelian yang sama, tetapi tenggat pada masing-masing bersifat tetap, dan tinjauan manual jarang muat dalam 12 jam melintasi zona waktu dan akhir pekan.

Berapa harga sebuah kolom yang salah ditangani

Uang sudah keluar sebelum pengembalian dana terjadi

Pengembalian dana barang habis pakai bukanlah pembatalan yang bersih. Pada saat seorang pelanggan meminta uangnya kembali atas paket kredit atau sekumpulan generasi AI, Anda sudah mengeluarkan biaya untuk mengirimkannya: inferensi GPU pada setiap permintaan, panggilan API model pihak ketiga yang ditagih per token, penyimpanan untuk apa pun yang Anda hasilkan, dan pembayaran kreator atau mitra apa pun yang terkait dengan penggunaan itu. Harga toko kembali ke pelanggan. Biaya pengiriman Anda tidak kembali kepada Anda. Jadi pengembalian dana yang bisa Anda tantang bukanlah peristiwa impas, itu adalah kerugian bersih atas semua yang Anda bayarkan untuk melayani akun tersebut.

Lima kolom itu adalah cara Anda menghindari membayar dua kali

deliveryStatus yang disetel ke DELIVERED dan consumptionPercentage yang tinggi adalah dua fakta yang memberi tahu Apple bahwa pelanggan menerima dan menggunakan produk. Keduanya adalah bukti Anda bahwa komputasi, panggilan API, dan penyimpanan semuanya menjalankan tugasnya. Biarkan payload tidak terkirim dan Apple tidak akan pernah mendengarnya. Apple memutuskan berdasarkan klaim pelanggan, pengembalian dana lebih mungkin lolos, dan Anda menanggung baik pendapatan yang dibatalkan maupun biaya pengiriman di baliknya.

Chargeback adalah pintu yang lebih buruk, dan keheningan menunjuk ke sana

Pelanggan yang tidak puas melalui alur pengembalian dana Apple masih bisa menyengketakan tagihan itu dengan banknya. Chargeback kartu bersifat final, membawa biaya sengketa tetap, dan mengambil keputusan dari tangan Apple dan tangan Anda. Menjawab CONSUMPTION_REQUEST dengan baik menjaga sengketa tetap di dalam sistem Apple, tempat Anda punya suara. Mengabaikannya mendorong kasus-kasus di ambang batas menuju satu-satunya saluran tempat Anda tidak punya suara.

Bagaimana RefundHalt menanganinya

Lima kolom itu tampak sederhana sampai Anda harus mengisinya dengan benar, dalam 12 jam, pada setiap CONSUMPTION_REQUEST, terkunci ke transaksi yang tepat. RefundHalt menangkap notifikasi, membaca catatan pengiriman dan penggunaan Anda sendiri untuk pembelian itu, dan mengirim payload secara otomatis sebelum jendela tertutup. deliveryStatus mencerminkan apa yang benar-benar ditunjukkan log Anda, consumptionPercentage berasal dari penggunaan nyata alih-alih tebakan, dan refundPreference mengikuti kebijakan yang Anda tetapkan sekali. Anda mendapatkan pengembalian dana yang dapat ditantang ditinjau dengan bukti, bukan tenggat yang terlewat dan keputusan yang dibuat tanpa Anda.