BillingMeld: Kenapa Pembelian Perlu Diperiksa Oleh Pelayan Bukan Aplikasi

Pembelian di dalam aplikasi mudah alih biasanya kelihatan mudah untuk pengguna sahaja. Dia menekan butang, mengesahkan pembayaran, mendapatkan akses kepada fungsi atau langganan — dan menunggu segala-galanya berfungsi secara automatik.

Bagi pembangun, di sebalik butang ini bermula proses yang jauh lebih kompleks. Mereka perlu mengesahkan pembelian itu sendiri, mengambil kira pembaharuan, tamatnya langganan, pulangan, ulasan operasi, penggantian peranti dan perbezaan antara kedai Apple dan Google.

Masalah utama timbul apabila pelayan mula menganggap aplikasi pelanggan sebagai sumber utama kebenaran.

Jika aplikasi memberitahu: "Pembelian selesai", pelayan membuka akses dan terus bergantung pada status yang pernah diterima. Tetapi kitar hayat pembelian tidak berhenti di situ.

Langganan boleh diperbaharui, pembaharuan automatik boleh dimatikan, pembayaran boleh dikembalikan, dan operasi itu sendiri boleh dibatalkan oleh kedai.

Itulah sebabnya dalam BillingMeld, pembelian disahkan bukan oleh aplikasi, tetapi oleh pelayan.

Pelanggan Melaporkan tetapi Tidak Menentukan

Dalam seni bina BillingMeld, aplikasi mudah alih tidak merupakan sumber utama maklumat tentang pembelian.

Pelanggan boleh menghantar data tentang operasi yang dilakukan, tetapi ini hanyalah asas untuk pemeriksaan. Keputusan terakhir diambil oleh bahagian pelayan BillingMeld, yang memeriksa maklumat melalui infrastruktur Apple atau Google.

Ini adalah perbezaan prinsip.

Aplikasi di telefon boleh berfungsi dengan keadaan lama, tidak menerima perubahan seterusnya tepat pada waktunya atau menghantar data yang sudah tidak sesuai dengan keadaan pembelian terkini.

Selain itu, pelanggan tidak seharusnya mempunyai kuasa untuk memutuskan sendiri sama ada pengguna layak mendapatkan akses berbayar.

BillingMeld memeriksa, sebagai contoh:

• adakah pembelian itu benar-benar wujud;

• berkaitan dengan aplikasi dan produk yang betul;

• adakah tempoh bayar untuknya sedang berlangsung;

• adakah pembaharuan seterusnya telah berlaku;

• adakah pembaharuan automatik telah dimatikan;

• adakah pengembalian telah dilakukan;

• adakah operasi telah dibatalkan;

• adakah tempoh bayar masih berlangsung.

Dengan cara ini, mesej dari pelanggan bukan lagi bukti pembelian, tetapi alasan untuk memeriksa keadaan sebenar pembelian tersebut.

Sumber Kebenaran Tunggal Untuk Pelayan

Perkhidmatan yang disambungkan tidak perlu melaksanakan sepenuhnya integrasi yang kompleks dengan Apple dan Google secara serentak.

Mereka hanya beraksi kepada BillingMeld dan mendapatkan keadaan pembelian yang telah dinormalisasi.

Contohnya: akses aktif, tempoh bayar tamat, pembaharuan seterusnya disahkan, pembaharuan automatik dinyahdayakan atau pembelian dibatalkan.

Ini membolehkan tanggungjawab dibahagikan dengan jelas.

Apple dan Google menjadi sumber status operasi kedai itu sendiri. BillingMeld memeriksa maklumat ini, menyesuaikannya ke dalam model umum dan menyimpan status terkini. Produk akhir membuat keputusan tentang akses berdasarkan status BillingMeld.

Untuk pelayan produk, ini bermaksud kontrak tunggal menggantikan pelbagai integrasi yang berasingan.

Tiada lagi keperluan untuk melaksanakan aturan App Store dan Google Play secara berasingan dalam setiap perkhidmatan, kemudian cuba menyamakan format, kejadian dan status yang berbeza ke dalam logik umum.

Mengapa Tidak Boleh Percaya Penuh Pada Pelanggan

Aplikasi pelanggan beroperasi di peranti pengguna.

Ia boleh ditutup, dimulakan semula, dipulihkan dari sandaran, dikemas kini kemudian atau dilancarkan di peranti lain. Ia mungkin berfungsi selama beberapa waktu dengan maklumat lama atau tidak menerima acara yang berlaku selepas pembelian asal.

Bahkan tanpa campur tangan pengguna, ini menjadikan pelanggan sebagai sumber keadaan akhir langganan yang tidak boleh dipercayai.

Contohnya, pengguna melanggan dan mendapat akses. Kemudian, ada pemulangan atau operasi diambil balik oleh kedai.

Jika pelayan hanya tahu tentang maklumat awal dari pelanggan, ia akan terus menganggap pembelian itu masih sah.

Satu lagi situasi, pengguna boleh mematikan auto-renewal. Sekalipun, tempoh berbayar yang sudah dibayar mesti kekal aktif sehingga tamatnya.

Jika sistem hanya beroperasi dengan status primitif “langganan ada / tiada langganan”, ia mudah untuk menutup akses terlalu awal atau sebaliknya, mengekalkannya selepas hak penggunaan tamat.

BillingMeld dibina berdasarkan logik lain: pelanggan tidak mengesahkan haknya sendiri. Ia melaporkan acara, dan pelayan menentukan keadaan sebenar pembelian.

Pembelian Bukan Satu Acara

Salah satu kesilapan utama dalam seni bina pengebilan ialah menganggap pembelian sebagai acara tunggal.

Padahal, ia mempunyai kitar hayatnya sendiri.

Mula-mula muncul operasi. Kemudian ia disahkan oleh kedai. Untuk langganan, tempoh bayar bermula. Kemudian ia mungkin diperbaharui lagi.

Pengguna boleh mematikan auto-renewal, tetapi tetap menggunakan langganan sehingga tempoh bayar yang dibayar berakhir.

Pembayaran mungkin gagal semasa pembaharuan seterusnya.

Mungkin berlaku pemulangan.

Dalam beberapa kes, pembelian boleh ditarik balik.

Oleh itu, satu kenyataan tentang “pembelian ini pernah wujud” tidak cukup.

Pelayan perlu memahami apa yang sedang berlaku sekarang.

Pengembalian dan Penarikan Masih Diketahui

Keperluan untuk seni bina pelayan sangat jelas apabila berlaku pemulangan dan penarikan balik operasi.

Pembelian awal mungkin sudah betul dan lengkap. Pengguna benar-benar telah membayar produk dan mendapat akses.

Namun, kemudian status operasi berubah.

Jika BillingMeld menerima maklumat tentang perubahan, ia mengemaskini status pembelian sendiri dan, jika perlu, memeriksa maklumat melalui kedai.

Selepas itu, perkhidmatan yang disambungkan berfungsi berdasarkan status baharu tersebut.

Dengan cara ini, aplikasi tidak terus mempercayai bahawa beberapa minggu atau bulan yang lalu, pelanggan pernah melaporkan pembelian yang berjaya.

Jika kedai tidak lagi menganggap hak itu sah, BillingMeld akan mencerminkan ini dalam statusnya.

Pembatalan Langganan dan Tamat Akses Bukanlah Sama

Ada perbezaan penting di sini.

Jika pengguna mematikan auto-renewal langganan, ini tidak bermakna akses mesti dihentikan serta-merta.

Tempoh bayar semasa mungkin masih berlaku.

Dalam kes ini, BillingMeld perlu menyimpan maklumat bahawa pembaharuan seterusnya dimatikan, tetapi juga perlu mengetahui tarikh tamat tempoh bayaran yang sedang berlangsung.

Hanya selepas tamat tempoh ini, akses tidak lagi diangggap aktif, jika tiada pembaharuan disahkan yang berlaku.

Ini antara contoh mengapa nilai boolean ringkas seperti subscription = true tidak mencukupi untuk pengebilan yang normal.

Status langganan sentiasa berkaitan dengan masa dan kejadian dalam kitar hayatnya.

Pelanjutan Juga Satu Pemeriksaan Berasingan

Langganan tidak berakhir pada pembayaran pertama sahaja.

Pelayan perlu memahami sama ada pembaharuan seterusnya berlaku dan sama ada tempoh bayar seterusnya benar-benar disahkan oleh kedai.

BillingMeld mengesan perubahan ini dan mengemaskini status langganan.

Jika pembaharuan disahkan, hak akses diteruskan.

Jika pembayaran selepas itu tidak berlaku ataupun kedai tidak lagi mengesahkan tempoh yang seterusnya, sistem tidak seharusnya meneruskan akses hanya berdasarkan jangkaan.

Ini kelihatan semula jadi kepada pengguna: akses berlaku selama langganan dilaksanakan secara sah.

Bagi pembangun, ini bermakna mereka tidak perlu melaksanakan logik pelanjutan yang sama berulang dalam setiap aplikasi.

Contoh Senario Biasa

Pengguna melanggan melalui aplikasi mudah alih.

Pelanggan menerima maklumat mengenai pembelian dan membekalkan data yang diperlukan kepada BillingMeld. Tetapi maklumat ini sendiri belum merupakan asas untuk menganggap pembelian itu sah secara akhir.

BillingMeld memeriksa operasi melalui kedai yang berkaitan.

Jika App Store atau Google Play mengesahkan pembelian itu dan statusnya sesuai dengan syarat produk, BillingMeld merekod hak aktif.

Selepas itu, perkhidmatan yang disambungkan membekalkan pengguna dengan kebolehan yang dibayar.

Seterusnya, status akan terus berlanjutan walaupun mesej asal dari pelanggan sudah tidak relevan.

Jika langganan diperbaharui, BillingMeld menganggap tempoh bayar baharu.

Jika pengguna mematikan auto-renewal, tempoh semasa akan berlanjutan sehingga tamat.

Jika operasi pemulangan atau penarikan berlaku, status akan diubah lagi.

Dalam skema ini, aplikasi tidak menyimpan “kebenaran” berasingan tentang pembelian. Ia berfungsi berdasarkan status yang disahkan dan disimpan oleh BillingMeld.

Apa Berlaku Apabila Bertukar Peranti

Model pelayan sangat berguna apabila pengguna menukar telefon atau memasang semula aplikasi.

Hak pembelian tidak boleh hanya bergantung kepada kejadian transaksi yang berjaya dilihat oleh aplikasi tertentu.

Sebaliknya, pemasangan semula aplikasi tidak sepatutnya membatalkan hak yang telah disahkan oleh pengguna.

Jika status pembelian disimpan di pelayan dan berkaitan dengan operasi kedai yang disahkan, peranti baharu boleh mendapatkan status terkini melalui pelayan.

Ini adalah satu lagi sebab mengapa logik akses tidak harus hanya disimpan dalam aplikasi mudah alih.

Keuntungan Untuk Pembangun

Bagi pasukan yang membangunkan beberapa aplikasi mudah alih atau bekerja dengan iOS dan Android serentak, pengebilan dengan cepat menjadi satu infrastruktur berasingan.

Mereka perlu mengambil kira:

• format data berbeza dari Apple dan Google;

• pengesahan pembelian awal;

• pelanjutan langganan;

• tamatnya tempoh bayar;

• matikan auto-renewal;

• pemulangan;

• penarikan operasi;

• pemasangan semula aplikasi;

• pertukaran peranti;

• pemulihan pembelian;

• perubahan status tanpa penglibatan pelanggan.

BillingMeld membawakan logik ini kepada satu lapisan khusus.

Pelayan produk beroperasi dengannya melalui kontrak tunggal dan tidak perlu mentafsirkan setiap ciri khas kedai satu persatu.

Ini mengurangkan duplikasi kod dan yang lebih penting, mengurangkan kemungkinan pelbagai aplikasi dari syarikat yang sama memahami satu scenarion pembayaran yang sama secara berbeza.

Bukan Cek, Tetapi Hak Terkini

Perkara paling menarik dalam seni bina ini ialah peralihan daripada pemeriksaan pembelian tunggal kepada kawalan keadaan terkini.

Sejarah pembayaran tidak lagi menjawab soalan utama produk:

adakah pengguna mempunyai hak untuk fungsi berbayar sekarang?

Pembelian boleh mempunyai kejayaan awal, tetapi tempoh tamat.

Langganan mungkin tidak mempunyai auto-renewal, tetapi tempoh berbayar sudah aktif.

Mungkin ada pembaharuan disahkan.

Boleh berlaku pemulangan.

Kedai boleh membatalkan operasi tersebut.

Oleh itu, objek utama bukan lagi cek dan jawapan awal dari pelanggan, tetapi hak pengguna yang terkini berdasarkan keadaan pembelian yang disahkan.

Inilah status yang diberi oleh BillingMeld kepada perkhidmatan lain.

BillingMeld Sebagai Sempadan Antara Kedai dan Produk

Hasilnya nampak satu garis seni bina yang cukup jelas.

Di satu pihak ada App Store dan Google Play beserta format, kejadian, peraturan dan kitar hayat pembelian mereka masing-masing.

Di pihak satu lagi adalah aplikasi dan perkhidmatan dalaman, yang kebanyakannya memerlukan jawapan yang lebih ringkas: hak apa yang ada pada pengguna sekarang.

Di antara keduanya ada BillingMeld.

Dia menerima data kedai, memeriksa, menyesuaikan ke dalam model sendiri dan membekalkan hasil yang telah dinormalisasi kepada infrastruktur lain.

Ini membebaskan produk daripada keperluan mengetahui setiap ciri kedai dan platform pembayaran tertentu.

Mengapa Ia Penting Untuk Pengguna

Bagi pengguna, seni bina pengebilan yang betul secara ideal harus kekal tidak disedari.

Jika pembelian disahkan dan tempoh bayar aktif, akses harus berfungsi.

Jika pengguna mematikan auto-renewal, tempoh bayar yang sudah dibayar tidak seharusnya hilang sebelum waktunya.

Jika pembaharuan baharu berlaku, akses harus diteruskan.

Jika kedai mengesahkan pemulangan atau penarikan, sistem harus mengemas kini hak pengguna dengan betul.

Apabila bertukar peranti atau memasang semula aplikasi, pengguna tidak perlu membuktikan kepada seluruh infrastruktur bahawa pembelian benar-benar berlaku.

Akhirnya, peraturan menjadi cukup ringkas:

pelanggan melaporkan pembelian, kedai adalah sumber luar keadaan, BillingMeld memeriksa dan menormalisasi keadaan itu, dan perkhidmatan lain membuat keputusan berdasarkan data yang disahkan oleh BillingMeld.

Oleh sebab itu, BillingMeld bukan sekadar modul pembayaran lagi.

Ini adalah lapisan pelayan kepercayaan antara aplikasi mudah alih, kedai Apple dan Google, serta produk yang perlu mengetahui dengan tepat hak berbayar yang dimiliki pengguna pada masa ini.

Selanjutnya mengenai projek ini: billingmeld.de.