Aplikasi Anda bisa menampilkan lembar permintaan refund di dalam aplikasi, dan inilah yang Apple lakukan setelah pelanggan menekan kirim

Apple membiarkan pelanggan meminta refund tanpa pernah keluar dari aplikasi Anda. Satu panggilan StoreKit, beginRefundRequest, menampilkan lembar refund milik Apple sendiri langsung di dalam antarmuka Anda, pelanggan memilih alasan, lalu permintaan itu pergi ke Apple untuk ditinjau. Anda tidak membangun formulirnya, Anda tidak menyentuh uangnya, dan Anda tidak menentukan hasilnya. Yang Anda dapatkan adalah cara menempatkan jalur refund di tempat pelanggan yang frustrasi sudah berada, alih-alih kehilangannya ke banknya. Inilah permintaan refund di dalam aplikasi, dan layak dipahami sebelum Anda memutuskan apakah akan merilis tombolnya.

Inilah bagian yang penting bagi pendapatan Anda. Tombol itu tidak merefund apa pun dengan sendirinya. Ia membuka sebuah permintaan, Apple mengambil waktu hingga 48 jam untuk menyetujui atau menolak, dan untuk pembelian consumable ia lebih dulu menembakkan CONSUMPTION_REQUEST ke server Anda. Jadi lembar itu bukan pemberian cuma-cuma. Ia adalah corong menuju peninjauan refund yang sama yang sudah bisa Anda pengaruhi, dan ia bisa menarik sengketa kembali dari jaringan kartu sebelum menjadi chargeback yang tidak bisa Anda sanggah.

Apa sebenarnya lembar permintaan refund di dalam aplikasi itu

beginRefundRequest adalah metode StoreKit 2 yang menampilkan lembar permintaan refund untuk sebuah transaksi dalam sebuah window scene. Tanda tangannya singkat: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. Ketika Anda memanggilnya, sistem menampilkan sebuah lembar berisi detail pembelian pelanggan dan daftar kode alasan untuk mereka pilih. Apple membangun dan mengendalikan antarmuka itu. Anda memasok scene dan transaksinya, tidak lebih.

Panduan Apple soal di mana menaruhnya bersifat eksplisit. Panggil fungsi ini dari pengaturan akun atau menu bantuan, supaya pelanggan yang menginginkan refund menemukannya di tempat mereka akan mencari dukungan. Ia hadir di iOS 15 dan iPadOS 15, Mac Catalyst 15, serta visionOS 1, jadi aplikasi apa pun yang menargetkan versi-versi itu bisa menampilkannya hari ini.

Dua cara membuka lembar itu

Ada dua titik masuk. Anda bisa memanggil beginRefundRequest(in:) pada sebuah transaksi spesifik yang sudah Anda pegang, yang membatasi lembar itu pada satu pembelian tersebut. Anda juga bisa membuka lembar itu berdasarkan pengidentifikasi produk ketika Anda ingin pelanggan merefund pembelian sebuah produk tertentu. Bagaimanapun, lembar, daftar alasan, dan keputusannya milik Apple. Tugas Anda berakhir pada menampilkannya dan membaca hasilnya.

Apa yang dikembalikan panggilan itu, dan apa yang bisa salah

Metode ini bertanda async throws, jadi ia entah mengembalikan sebuah status atau melempar sebuah kesalahan. Keduanya daftar pendek, dan keduanya layak ditangani supaya antarmuka Anda mengatakan sesuatu yang benar setelah lembar itu tertutup.

Apa yang terjadi di server Anda setelah pelanggan menekan kirim

Tertutupnya lembar itu adalah awal proses, bukan akhirnya. Apple meninjau permintaan itu dan mengambil waktu hingga 48 jam untuk menyetujui atau menolak. Untuk sebuah pembelian consumable di dalam aplikasi, sebelum memutuskan, App Store mengirim notifikasi CONSUMPTION_REQUEST ke server Anda meminta data penggunaan. Jika pelanggan menyetujui untuk berbagi data itu, Anda menjawab lewat endpoint Send Consumption Information. Jika mereka tidak menyetujui, instruksi Apple sendiri adalah untuk tidak menanggapi notifikasi itu sama sekali.

Begitu Apple memutuskan, hasilnya mendarat di server Anda sebagai App Store Server Notification. Itu adalah feed yang sama yang sudah Anda terima, dan permintaan di dalam aplikasi masuk ke sana persis seperti refund yang dimulai pelanggan di halaman reportaproblem milik Apple. Tidak ada yang berubah soal penanganannya hanya karena permintaan itu bermula di dalam aplikasi Anda.

Apa yang tombol itu bebankan pada Anda, dan apa yang bisa dihematnya

Refund yang bisa Anda sanggah lebih baik daripada chargeback yang tidak bisa

Pelanggan yang tidak bisa menemukan jalur refund di dalam aplikasi Anda tidak menyerah. Mereka pergi ke banknya. Sebuah chargeback kartu bersifat final dengan bank, membawa biaya sengketa, dan mengambil keputusan itu dari tangan Anda maupun tangan Apple. Sebuah permintaan refund di dalam aplikasi menahan pelanggan yang sama di dalam sistem Apple, tempat pembelian consumable memicu CONSUMPTION_REQUEST yang bisa Anda jawab dan keputusan yang bisa Anda pengaruhi. Menukar chargeback yang tidak bisa disanggah dengan peninjauan Apple yang bisa disanggah adalah keseluruhan argumen finansial demi tombol itu.

Anda menurunkan gesekan pada sebuah refund

Penyeimbang yang jujur adalah bahwa jalur refund yang terlihat dan sekali ketuk menghasilkan lebih banyak permintaan refund daripada email dukungan yang terkubur. Sebagian di antaranya tidak akan pernah terjadi. Itu adalah biaya nyata, dan itulah sebabnya Apple menyuruh Anda menempatkan titik masuknya di pengaturan akun atau menu bantuan alih-alih di layar pembelian. Anda ingin pelanggan yang sudah tidak puas menemukannya, bukan pelanggan yang sekadar penasaran.

Biaya yang berjalan sepanjang waktu adalah melayani akun yang telah direfund

Ke arah mana pun keputusan itu jatuh, meteran pada pengiriman terus berjalan sampai Anda bertindak atas hasilnya. Setiap jam sebuah hak akses yang telah direfund tetap aktif, Anda terus membayar biaya nyata di baliknya: komputasi, panggilan API model, penyimpanan, dan setiap pembayaran ke kreator atau mitra yang terikat pada penggunaan pelanggan itu. Permintaan di dalam aplikasi tidak mengubah itu. Mencabut dengan cepat pada notifikasi REFUND yang mengubahnya. Tombol itu semurah penanganan Anda atas notifikasi yang akhirnya dihasilkannya, tidak lebih.

Haruskah Anda merilis permintaan refund di dalam aplikasi

Taruh di tempat dukungan berada, bukan di tempat penjualan berada

Ikuti panduan penempatan Apple. Pengaturan akun dan menu bantuan adalah rumah yang tepat. Tautan refund di sebelah paywall melatih orang untuk mengharapkan uang mereka kembali, dan mengundang refund penasaran yang tidak pernah perlu Anda tawarkan.

Uji seluruh alur di sandbox sebelum Anda memercayainya

Anda bisa menyimulasikan seluruh jalur di sandbox dan di pengujian StoreKit milik Xcode, memindahkan sebuah permintaan dari tertunda ke disetujui atau ditolak. Sebuah persetujuan mengirimkan notifikasi REFUND ke server Anda, dan sebuah penolakan mengirimkan REFUND_DECLINED, jadi Anda bisa membuktikan penangan Anda bereaksi dengan benar sebelum pelanggan sungguhan pernah menekan kirim.

Tangani setiap hasil, dan jangan pernah melebih-lebihkan

Tampilkan tertunda saat success, tawarkan coba lagi saat failed, katakan tidak ada yang berubah saat userCancelled, dan perlakukan duplicateRequest sebagai catatan tenang bahwa permintaan pelanggan yang lebih awal masih berlaku. Satu kesalahan yang menyakiti adalah memberi tahu pelanggan bahwa refund mereka selesai padahal yang Anda pegang hanyalah sebuah permintaan yang terkirim.

Bagaimana RefundHalt menangani sisanya

Lembar di dalam aplikasi itu milik Apple. Apa yang datang setelahnya milik Anda, dan itulah bagian yang dijalankan RefundHalt. Ketika seorang pelanggan mengirim refund dari dalam aplikasi Anda, RefundHalt menangkap CONSUMPTION_REQUEST untuk pembelian consumable dan menjawabnya dalam jendela 12 jam dengan bukti penggunaan yang membantu Apple memutuskan. Ketika Apple memutuskan, ia mencabut pada REFUND dan menjaga akses tetap utuh pada REFUND_DECLINED, masing-masing terkait pada transaksi yang persis. Anda bisa menawarkan jalur refund di dalam aplikasi yang lebih ramah tanpa menyerahkan peninjauan, bukti, atau pencabutan pada kerepotan manual.