BillingMeld: mengapa server harus memverifikasi pembelian daripada aplikasi

Pembelian dalam aplikasi seluler biasanya terlihat sederhana bagi pengguna. Mereka menekan tombol, mengonfirmasi pembayaran, mendapatkan akses ke fitur atau langganan — dan berharap semuanya akan berjalan otomatis selanjutnya.

Bagi pengembang, di balik tombol ini mulai proses yang jauh lebih kompleks. Mereka harus memverifikasi pembelian itu sendiri, mempertimbangkan perpanjangan, berakhirnya langganan, pengembalian uang, review operasi, perubahan perangkat, dan perbedaan antara toko Apple dan Google.

Masalah utama muncul ketika server mulai menganggap aplikasi klien sebagai sumber kebenaran.

Jika aplikasi melaporkan: «Pembelian berhasil», server membuka akses dan terus mengandalkan status yang pernah diterima. Tetapi kehidupan siklus pembelian tidak berakhir di situ.

Langganan bisa diperpanjang, perpanjangan otomatis bisa dimatikan, pembayaran bisa dikembalikan, dan operasi itu sendiri bisa dibatalkan oleh toko.

Itulah sebabnya di BillingMeld, pembelian diverifikasi bukan oleh aplikasi, melainkan oleh server.

Klien melaporkan, tetapi tidak memutuskan

Dalam arsitektur BillingMeld, aplikasi mobile bukan sumber utama informasi mengenai pembelian.

Klien bisa mengirim data tentang operasi yang dilakukan, tetapi ini hanyalah dasar untuk verifikasi. Keputusan akhir diambil oleh bagian server BillingMeld, yang memverifikasi informasi tersebut melalui infrastruktur Apple atau Google.

Ini adalah perbedaan prinsip.

Aplikasi di ponsel bisa bekerja dengan status lama, tidak menerima pembaruan terbaru tepat waktu, atau mengirim data yang sudah tidak sesuai dengan status pembelian saat ini.

Selain itu, klien tidak seharusnya memiliki hak untuk memutuskan secara mandiri apakah pengguna berhak mengakses fitur berbayar.

BillingMeld memverifikasi, misalnya:

• apakah pembelian tersebut benar-benar ada;

• apakah terkait dengan aplikasi dan produk yang tepat;

• apakah periode yang dibayar masih berlaku;

• apakah terjadi perpanjangan terakhir;

• apakah perpanjangan otomatis dimatikan;

• apakah dilakukan pengembalian uang;

• apakah operasi tersebut dibatalkan;

• apakah periode pembayaran sudah berakhir.

Dengan demikian, pesan dari klien bukan lagi bukti pembelian, melainkan alasan untuk memeriksa statusnya secara aktual.

Sumber kebenaran tunggal untuk server

Layanan yang terhubung tidak perlu mengimplementasikan seluruh rangkaian integrasi dengan Apple dan Google secara sekaligus.

Mereka cukup merujuk ke BillingMeld dan menerima status pembelian yang sudah dinormalisasi.

Misalnya: akses aktif, periode bayar sudah berakhir, perpanjangan terakhir dikonfirmasi, perpanjangan otomatis dimatikan, atau pembelian dibatalkan.

Ini memungkinkan pemisahan tanggung jawab yang jelas.

Apple dan Google adalah sumber status operasi toko itu sendiri. BillingMeld memeriksa data tersebut, menyesuaikannya ke model umum, dan menyimpan status terkini. Produk akhir kemudian membuat keputusan tentang akses berdasarkan status BillingMeld.

Bagi server produk, ini berarti kontrak tunggal alih-alih banyak integrasi independen.

Pengembang tidak perlu lagi mengimplementasikan aturan App Store dan Google Play secara terpisah, lalu berusaha menyesuaikan format, peristiwa, dan status yang berbeda ke logika umum.

Mengapa klien tidak bisa dipercaya sepenuhnya

Aplikasi klien berjalan di perangkat pengguna.

Ia dapat ditutup, di-restart, dipulihkan dari cadangan, diperbarui nanti, atau dijalankan di perangkat lain. Ia mungkin bekerja dengan data lama, atau tidak menerima peristiwa yang terjadi setelah pembelian awal.

Tanpa campur tangan pengguna, ini membuat aplikasi klien menjadi sumber kondisi langganan yang tidak sepenuhnya akurat.

Misalnya, pengguna membeli langganan dan mendapatkan akses. Kemudian, pembelian tersebut dibatalkan atau operasi di toko diambil kembali.

Jika server hanya mengetahui pesan awal dari klien, ia akan tetap menganggap pembelian tersebut aktif.

Dalam situasi lain, pengguna bisa mematikan perpanjangan otomatis. Namun, periode yang telah dibayar tetap aktif hingga akhir waktunya.

Jika sistem hanya mengoperasikan status sederhana «langganan ada / tidak ada», bisa saja akses ditutup terlalu dini atau tetap terbuka setelah hak penggunaan usai.

BillingMeld didasarkan pada logika lain: klien tidak mengonfirmasi hak mereka sendiri. Klien melaporkan peristiwa, dan server menentukan kondisi aktual pembelian.

Pembelian — bukan satu kejadian saja

Salah satu kesalahan utama dalam arsitektur billing adalah menganggap pembelian sebagai kejadian tunggal.

Sebenarnya, ia memiliki siklus hidup.

Awalnya muncul operasi. Kemudian dikonfirmasi oleh toko. Untuk langganan, periode bayar dimulai. Kemudian bisa terjadi perpanjangan berikutnya.

Pengguna bisa mematikan perpanjangan otomatis, tetapi tetap menggunakan langganan sampai periode yang sudah dibayar berakhir.

Pembayaran bisa gagal saat perpanjangan berikutnya.

Pengembalian uang bisa dilakukan.

Dalam beberapa kasus, pembelian bisa dibatalkan.

Oleh karena itu, satu fakta bahwa «pembelian ini pernah ada» tidak cukup.

Server perlu memahami apa yang sebenarnya terjadi saat ini.

Pengembalian dan pembatalan tidak luput dari perhatian

Kebutuhan akan arsitektur server menjadi sangat jelas terutama dalam kasus pengembalian dan pembatalan operasi.

Pembelian awal mungkin sudah benar dan lengkap — pengguna benar-benar membayar dan mendapatkan akses.

Tetapi kemudian, status operasi berubah.

Jika BillingMeld menerima informasi perubahan, ia akan memperbarui status pembeliannya dan, jika perlu, melakukan verifikasi tambahan melalui toko.

Setelah itu, layanan yang terhubung menggunakan status baru tersebut.

Dengan cara ini, aplikasi tidak lagi harus sepenuhnya percaya pada fakta bahwa beberapa minggu atau bulan lalu, klien pernah melaporkan pembelian berhasil.

Jika toko tidak lagi menganggap hak tersebut berlaku, BillingMeld akan mencerminkan hal ini dalam statusnya.

Pembatalan langganan dan berakhirnya akses — bukan satu dan sama

Ada perbedaan penting di sini.

Jika pengguna mematikan perpanjangan otomatis, ini biasanya tidak berarti bahwa akses harus langsung dihentikan.

Periode bayar saat ini dapat terus berlangsung.

Dalam kasus tersebut, BillingMeld harus menyimpan informasi bahwa perpanjangan otomatis telah dimatikan, sekaligus memahami tanggal akhir periode yang sudah dibayar.

Hanya setelah periode tersebut berakhir, akses dianggap tidak aktif lagi, kecuali ada konfirmasi perpanjangan baru.

Ini salah satu alasan mengapa status langganan tidak cukup hanya dengan nilai boolean subscription = true.

Status langganan selalu terkait dengan waktu dan peristiwa siklus hidupnya.

Perpanjangan juga memerlukan verifikasi terpisah

Langganan tidak berakhir saat pembayaran pertama.

Server harus mengetahui apakah ada perpanjangan berikutnya yang dilakukan dan apakah periode bayar berikutnya benar-benar dikonfirmasi oleh toko.

BillingMeld memantau perubahan tersebut dan memperbarui status langganan.

Jika perpanjangan dikonfirmasi, hak akses tetap berlaku.

Jika pembayaran gagal atau toko tidak lagi mengonfirmasi periode berikutnya, sistem tidak boleh hanya memperpanjang akses berdasarkan asumsi sendiri.

Bagi pengguna, ini tampak alami: akses berlangsung selama langganan yang memang aktif secara pembayaran.

Bagi pengembang, ini berarti mereka tidak perlu lagi mengimplementasikan logika perpanjangan yang sama di setiap aplikasi.

Bagaimana skenario normal biasanya berjalan

Pengguna membeli langganan dalam aplikasi mobile.

Klien menerima informasi pembelian dan mengirimkan data yang diperlukan ke BillingMeld. Tetapi, pesan ini sendiri belum menjadi dasar untuk menganggap pembelian sudah dikonfirmasi secara final.

BillingMeld memverifikasi operasi melalui toko terkait.

Jika App Store atau Google Play mengonfirmasi pembelian dan statusnya memenuhi aturan produk, BillingMeld mencatat hak aktif.

Setelah itu, layanan yang terhubung menyediakan fitur berbayar kepada pengguna.

Status ini kemudian terus berlaku independen dari pesan awal dari klien.

Jika langganan diperpanjang, BillingMeld memperhitungkan periode bayar baru.

Jika pengguna mematikan perpanjangan otomatis, periode berjalan tetap aktif sampai berakhir.

Jika terjadi pengembalian atau pembatalan operasi, status akan diubah lagi.

Dalam skema ini, aplikasi tidak menyimpan versi «kebenaran» sendiri terkait pembelian. Ia bekerja dengan status yang diverifikasi dan disimpan oleh BillingMeld.

Apa yang terjadi saat berganti perangkat

Model server sangat membantu ketika pengguna berganti ponsel atau menginstal ulang aplikasi.

Hak atas pembelian tidak seharusnya hanya ada karena perangkat tertentu pernah melakukan transaksi berhasil.

Sebaliknya, penginstalan ulang aplikasi tidak boleh menghapus hak yang sudah dikonfirmasi pengguna.

Jika status pembelian berlokasi di server dan terkait dengan operasi toko yang sudah dikonfirmasi, perangkat baru dapat memperoleh status terkini melalui server.

Ini juga alasan lain untuk tidak menyimpan logika akses sepenuhnya di dalam aplikasi klien.

Manfaatnya untuk pengembang

Bagi tim yang mengelola beberapa aplikasi mobile atau bekerja dengan iOS dan Android sekaligus, billing dengan cepat menjadi tugas infrastruktur tersendiri.

Mereka perlu mempertimbangkan:

• format data berbeda dari Apple dan Google;

• verifikasi pembelian awal;

• perpanjangan langganan;

• berakhirnya periode bayar;

• pemutusan otomatis;

• pengembalian uang;

• pembatalan operasi;

• instalasi ulang aplikasi;

• ganti perangkat;

• pemulihan pembelian;

• perubahan status tanpa intervensi klien.

BillingMeld mengangkat logika ini ke lapisan terpisah yang khusus.

Server produk berinteraksi dengannya melalui kontrak tunggal dan tidak perlu mengartikan semua fitur masing-masing toko secara mandiri.

Ini mengurangi duplikasi kode dan yang lebih penting lagi, mengurangi risiko bahwa aplikasi dari perusahaan yang sama menafsirkan skenario pembayaran yang sama secara berbeda.

Yang utama bukan cek, tetapi hak terkini

Perubahan terbesar dari arsitektur ini yang paling menarik bagi saya adalah pergeseran dari verifikasi pembelian tunggal ke pengelolaan status terkini.

Faktanya, pembayaran awal saja tidak menjawab pertanyaan utama dari produk:

apakah pengguna berhak menggunakan fungsi berbayar saat ini?

Pada operasi mungkin sudah dilakukan pembayaran awal yang sukses, tetapi periode berlangganan sudah berakhir.

Langganan mungkin telah dimatikan perpanjang otomatisnya, tetapi periode pembayaran yang sudah dibayar tetap berlaku.

Perpanjangan yang dikonfirmasi juga bisa berlangsung.

Pengembalian uang bisa dilakukan.

Toko juga bisa membatalkan operasi tersebut.

Karena itu, yang menjadi fokus utama bukan cek dan jawaban awal dari klien, melainkan hak pengguna terkini berdasarkan status pembelian yang sudah dikonfirmasi.

Inilah keadaan yang benar-benar dipastikan oleh BillingMeld dan disampaikan ke layanan lain.

BillingMeld sebagai batas antara toko dan produk

Akibatnya, muncul batas arsitektur yang cukup jelas.

Di satu sisi ada App Store dan Google Play dengan format, peristiwa, aturan, dan siklus hidup pembelian mereka masing-masing.

Di sisi lain — aplikasi dan layanan internal, yang dalam kebanyakan kasus hanya membutuhkan jawaban yang jauh lebih sederhana: hak apa yang saat ini dimiliki pengguna.

Di antaranya adalah BillingMeld.

Ia menerima data toko, memverifikasi, menyesuaikan ke model internal, dan menyediakan hasil yang sudah dinormalisasi ke infrastruktur lainnya.

Ini membantu produk tidak perlu mengetahui semua fitur internal dari masing-masing platform pembayaran.

Mengapa ini penting bagi pengguna

Bagi pengguna, arsitektur billing yang benar ideally harus tetap tidak terlihat.

Jika pembelian dikonfirmasi dan periode bayar aktif, akses harus berfungsi.

Jika pengguna mematikan perpanjangan otomatis, periode yang sudah dibayar tidak boleh berakhir lebih awal dari jadwal.

Jika terjadi perpanjangan baru yang berhasil, akses harus terus berlanjut.

Jika toko mengonfirmasi pengembalian atau pembatalan, sistem harus secara tepat mencerminkan perubahan hak.

Saat berganti perangkat atau menginstal ulang aplikasi, pengguna tidak seharusnya perlu membuktikan secara manual kepada setiap bagian infrastruktur bahwa pembelian itu benar-benar ada.

Simpulnya, aturannya cukup sederhana:

klien melaporkan pembelian, toko adalah sumber eksternal statusnya, BillingMeld memverifikasi dan menormalisasi status tersebut, dan layanan lain membuat keputusan berdasarkan data yang sudah dikonfirmasi oleh BillingMeld.

Itulah sebabnya BillingMeld bukan sekadar modul pembayaran lainnya.

Ini adalah lapisan kepercayaan server antara aplikasi mobile, toko Apple dan Google, serta produk yang perlu memahami secara tepat hak berbayar apa yang dimiliki pengguna saat ini.

Pelajari lebih lanjut tentang proyek ini di: billingmeld.de.