Bagaimana tidak kehilangan uang di kotak hitam: metode pengujian penagihan

Validasi layanan berbayar adalah salah satu masalah teknis utama dalam pengujian Badoo. Aplikasi kami terintegrasi dengan 70 penyedia pembayaran di 250 negara di dunia, dan bug di setidaknya satu dari mereka dapat menyebabkan konsekuensi yang tidak terduga.

Pada artikel ini, saya akan berbicara tentang metode pengujian yang kami gunakan di Badoo, dan batasan penerapan metode ini - tahapan pengujian yang paling efektif.

Artikel ini akan berguna untuk penguji, pengembang dan manajer produk, yang proyeknya sudah terintegrasi dengan penyedia pembayaran, atau proses integrasi baru saja dimulai. Jika dalam pekerjaan Anda Anda dihadapkan dengan masalah memilih metode pengujian untuk integrasi seperti itu, selamat datang!




Nama saya Vladimir Solodov, saya Billing QA Engineer di Badoo: Saya terlibat dalam verifikasi integrasi pengujian dan pemrosesan pembayaran. Kolega saya, Viktor Koronevich, membantu saya menyiapkan teks: bersama dengannya kami membuat laporan di konferensi Heisenbug ( video ). Dalam artikel tersebut, kami memperluas area deskripsi ke semua integrasi dengan penyedia pembayaran yang digunakan di Badoo, mengklasifikasikan dan menjelaskan praktik menghapus ketergantungan eksternal secara lebih rinci.

Menggunakan studi kasus bisnis sebagai contoh, saya akan menjelaskan mengapa Anda harus lebih memperhatikan pengujian layanan berbayar dan bagaimana tidak memperparah masalah jika tetap muncul. Dan kemudian kita akan menjelaskan masalah teknis dari integrasi pengujian dan cara untuk menyelesaikannya.

Bagian kedua dari artikel ini, di mana kita berbicara lebih banyak tentang otomatisasi pengujian layanan berbayar di aplikasi iOS, ada di sini .

Ayo pergi!

Spesifikasi Tes Penagihan

Biasanya, tujuan bisnis adalah untuk menghasilkan pendapatan. Di Badoo, jejaring sosial untuk kencan, pendapatan diperoleh dari pinjaman dan langganan premium. Pinjaman adalah mata uang internal Badoo. Dengan bantuan mereka, misalnya, Anda dapat meningkatkan profil Anda di hasil pencarian di tempat pertama, membuat hadiah kepada pengguna lain, dan banyak lagi. Langganan premium berlaku untuk jangka waktu tertentu dan memberi Anda beberapa opsi sekaligus: nyalakan mode "tak terlihat", lihat orang-orang yang menunjukkan minat pada Anda, konfirmasikan keaslian akun Anda dan banyak lagi.

Agar layanan berbayar ini berfungsi, kami menggunakan integrasi dengan lebih dari 70 penyedia pembayaran. Pilihan penyedia tergantung pada platform, negara, perangkat, operator seluler dan faktor lainnya. Karena itu, masalah pengujian layanan berbayar sangat mendesak.

Untuk memulai, pertimbangkan mengapa pengujian layanan berbayar harus didekati dengan perhatian khusus. Ada dua alasan.

1. Bug penagihan sangat penting untuk bisnis.

Masalah pertama adalah reputasi. Pengguna yang membayar layanan menjadi lebih sensitif (dan kurang toleran) terhadap bug dalam aplikasi. Setiap umpan balik di ruang publik, apakah itu ulasan aplikasi blog atau komentar di App Store atau Google Play, dari pengguna yang menemukan bug di layanan berbayar, akan lebih emosional - ini adalah faktor yang menyebabkan kehilangan reputasi.

Masalah kedua adalah, segera setelah Anda mulai menerima uang dari pengguna untuk suatu layanan, Anda menjadi objek hukum yang melindungi konsumen dari layanan tersebut. Dan kerugian reputasi dapat dengan mudah berubah menjadi kerugian finansial.

Perusahaan kehilangan uang dalam tiga cara.

Cara pertama adalah pengembalian uang . Misalkan seorang pengguna menemukan bahwa Anda telah menjualnya layanan yang tidak memenuhi harapannya. Dalam hal ini, dia akan menghubungi tim dukungan Anda. Karyawannya melakukan penyelidikan dan mengetahui bahwa harapan pengguna benar-benar tidak terwujud karena bug dalam aplikasi. Anda melakukan pengembalian uang. Dalam hal ini, ada pengembalian uang: sebagai hasilnya, perusahaan dihadapkan pada untung yang hilang, dan ini adalah cara yang paling tidak berbahaya untuk kehilangan uang.

Cara kedua adalah tolak bayar . Misalkan situasi yang sama terjadi, hanya pengguna yang tidak menghubungi layanan dukungan Anda, tetapi bank yang mengeluarkannya kartu, atau penyedia pembayaran. Bank / penyedia memulai pengembalian uang. Dalam hal ini, kami berurusan dengan tolak bayar. Bahaya untuk bisnis di sini bukan hanya pada untung yang hilang. Setelah sejumlah tolak bayar tertentu, perusahaan menerima denda, dan peringkat risikonya menurun. Penurunan peringkat, pada gilirannya, menyebabkan kenaikan biaya layanan penyedia pembayaran.

Cara ketiga - tuntutan hukum (klaim) . Dalam kasus-kasus yang paling diabaikan, tuntutan hukum (termasuk yang kolektif) dapat terjadi, yang mengarah ke konsekuensi paling serius. Jadi, pada 2015, setelah gugatan oleh regulator Ofgem, British Gas terpaksa membayar kompensasi jutaan dolar kepada pengguna yang membebankan biaya lebih tinggi karena kesalahan dalam sistem pengisian. Baca lebih lanjut tentang ini di sini .

2. Untuk menguji integrasi, diperlukan pengetahuan dan keahlian.

Tim yang baru memulai proses integrasi dengan penyedia pembayaran sering menghadapi masalah ini. Tidak mengetahui semua kemungkinan kasus tagihan, mereka kehilangan nuansa penting ketika mereka menyadari reaksi sistem terhadap pemberitahuan penyedia pembayaran.

Ini dapat menyebabkan konsekuensi yang tidak terduga - mulai dari untung yang hilang hingga pengguna yang tidak puas.

Mari kita lihat skema yang mencantumkan jenis layanan berbayar, dan pertimbangkan masalahnya dengan lebih cermat.


Gambar 1. Kasing penagihan yang memungkinkan

Ada tiga kasus utama: kesalahan, pembayaran yang berhasil, dan pengembalian uang kepada pengguna. Tetapi setiap case memiliki detail, setiap case yang harus ditangani oleh sistem Anda secara berbeda.

Kesalahan bisa menjadi kritis dan tidak kritis. Kesalahan pemberitahuan dapat dikaitkan dengan non-kritis - ketika penyedia pembayaran menginformasikan tentang kurangnya dana di akun pengguna, dan pemblokiran kritis terhadap metode pembayaran pengguna. Dan jika dalam kasus pertama Anda dapat mencoba untuk membayar nanti, maka dalam yang kedua - akan lebih baik untuk mencari tahu mengapa metode ini diblokir. Mungkin pengguna terlihat dalam penipuan dan Anda harus lebih berhati-hati tentang transaksinya.

Pengembalian uang . Anda sudah tahu bahwa ada dua jenis pengembalian: pengembalian uang dan tagihan balik. Sistem Anda harus merespons secara berbeda terhadap mereka. Misalnya, setelah tolak bayar, masuk akal untuk berpikir tentang memblokir beberapa fungsi aplikasi Anda untuk pengguna, karena tolak bayar adalah salah satu metode penipuan paling populer.

Pembayaran yang berhasil mungkin merupakan pembayaran satu kali, atau mungkin berlangganan.

Pembayaran sekali saja dapat dikonsumsi dan tidak dapat dikonsumsi. Sebagai contoh pembayaran yang dihabiskan, kami memeriksa di awal artikel - ini adalah pinjaman di Badoo. Contoh pembayaran yang tidak dapat dihabiskan dapat diberikan dari game. Misalkan Anda memiliki karakter yang Anda mainkan. Anda ingin membeli untuknya kekuatan super yang telah ada selama beberapa waktu. Dalam hal ini, pembelian termasuk dalam kelas pembayaran yang tidak dapat dibuang.

Berlangganan Ini adalah variasi terbesar kasus. Selain pembelian awal berlangganan, Anda mungkin memiliki:

• pembaruan langganan (perpanjangan);
  
• tutup langganan (batal berlangganan);
  
• langganan uji coba (uji coba);
  
• berlangganan masa tenggang: ketika kami tidak dapat memperbarui berlangganan dan mencoba membayar lagi untuk jangka waktu yang disebut masa tenggang. Untuk pengguna, masa tenggang terlihat seperti ini. Misalkan Anda membeli langganan koran bulanan. Perusahaan yang mengirimi Anda surat kabar mencoba menghapus pembayaran untuk bulan berlangganan berikutnya setelah akhir bulan pertama, tetapi tidak dapat melakukan ini (karena kunci kartu, kurangnya dana di akun, dll.). Jika masa berlaku masa tenggang adalah sepuluh hari, maka selama waktu ini perusahaan mencoba untuk menghapus pembayaran, sementara langganan tetap berlaku. Jika perusahaan tidak dapat menghapus uang, langganan dibatalkan. Jika ya, langganan diperbarui dari tanggal pembayaran terakhir;
  
• pembayaran parsial (tagihan parsial). Misalnya, PayPal memungkinkan Anda melakukan pembayaran sebagian jika akun pengguna tidak memiliki cukup dana (pembayaran sebagian), atau memecah pembayaran menjadi beberapa bagian (sebagian faktur).
  

Anda juga perlu mempertimbangkan dua karakteristik yang sepenuhnya bergantung pada penyedia pembayaran: langganan dapat dikontrol oleh aplikasi Anda atau dikelola secara eksternal.

• Langganan yang dikelola secara internal adalah, misalnya, langganan yang menggunakan kartu kredit atau PayPal, ketika setelah pembayaran pertama Anda diberikan token yang Anda gunakan untuk mendaftar ulang ke penyedia, tanpa memiliki rincian pembayaran pengguna.
  
• Langganan yang dikelola secara eksternal adalah ketika agregator pembayaran mengambil kendali penuh atas langganan Anda dan hanya mengirimi Anda pemberitahuan tentang status mereka saat ini.
  

Dalam gambar, area yang paling jelas, reaksi yang biasanya diwujudkan pada awalnya, disorot dengan warna ungu. Semua yang lain mulai diperhitungkan jauh kemudian, sebagai akumulasi keahlian. Ini sebagian besar difasilitasi oleh aplikasi yang salah dari metodologi pengembangan berulang di bidang penagihan.


Gambar 2. Kasus penagihan yang terutama diimplementasikan dalam sistem

Implementasi bertahap seperti itu dapat menyebabkan konsekuensi yang tidak terduga. Misalnya, dalam salah satu proyek yang saya kerjakan sebelum Badoo, kemungkinan untuk melakukan pengembalian dana tidak diperhitungkan. Akibatnya, semua pengembalian dilakukan bukan melalui pengembalian uang, tetapi melalui tolak bayar, yang secara negatif mempengaruhi peringkat risiko perusahaan dan menyebabkan kegagalan dalam mengumpulkan statistik pendapatan. Ketidaktahuan tentang seluruh ragam kasus tagihan dapat menyebabkan hilangnya keuntungan atau kerentanan perusahaan terhadap pengguna yang merasa ditipu.

Jadi, di satu sisi, bug dalam pemrosesan pembayaran harus ditemukan sebelum dirilis, karena mereka dapat menyebabkan konsekuensi paling negatif. Jika tidak memungkinkan untuk melakukan ini, penting untuk segera menyadari bahwa bug masuk ke versi rilis aplikasi, memperbaikinya dan, yang paling penting, apa yang banyak orang lupa, "meyakinkan" pengguna yang menemukan bug ini.

Di sisi lain, situasinya diperumit oleh fakta bahwa integrasi dengan penyedia pembayaran selalu berinteraksi dengan kotak hitam, yang menambahkan banyak variabel ke proses pengujian.

Masalah teknis selama pengujian penagihan

Mari kita pertimbangkan mereka pada contoh integrasi Badoo dengan App Store.

Langganan di App Store milik kelas yang dikelola secara eksternal, yaitu, mereka dikelola sepenuhnya di pihak penyedia, dan sistem kami hanya dapat meminta status saat ini atau menerima pemberitahuan perubahannya.

Kami secara khusus memilih integrasi ini, karena ini adalah yang paling kompleks dan berisi semua ragam kasus yang dapat ditemukan dalam proses mengintegrasikan layanan dengan penyedia pembayaran lainnya.

Untuk mulai dengan, kami beralih ke pembelian sekali pakai.


Gambar 3. Proses melakukan pembayaran sekali pakai

Pada langkah 1, pengguna membuat permintaan untuk membeli layanan. Aplikasi memutuskan bahwa pembayaran harus dilakukan, dan pada langkah 2, kontrol ditransfer ke penyedia pembayaran (App Store). Langkah 3: pengguna diberikan formulir untuk melakukan pembayaran. Langkah 4: pengguna menyediakan data untuk pembayaran. Langkah 5: penyedia menyelesaikan transaksi dan melaporkan hasilnya ke aplikasi, mengembalikan tanda terima yang berisi informasi lengkap tentang pembelian (tanggal, layanan, status, dll.). Langkah 6: cek, ditambah dengan data pengguna, dikirim ke server untuk diproses. Server memproses data pemeriksaan dan menghasilkan pemberitahuan push untuk aplikasi pada langkah ketujuh. Pada langkah kedelapan, pemberitahuan ditampilkan kepada pengguna.

Masalahnya adalah bahwa langkah 3, 4 dan 5 dilakukan di sisi penyedia pembayaran, secara praktis tidak dikendalikan oleh kami dan dapat memiliki berbagai variasi. Dengan demikian, proses sebenarnya tidak memiliki struktur linier, seperti yang ditunjukkan pada Gambar 2, tetapi yang bercabang (lihat Gambar 4), dan masing-masing cabang harus ditangani secara berbeda oleh aplikasi.


Gambar 4. Percabangan diagram keadaan pembayaran satu kali

Membeli langganan dimulai dengan cara yang sama dengan pembayaran satu kali, tetapi kontrol lebih lanjut dari proses ini cukup sulit untuk dikendalikan.


Gambar 5. Status langganan yang dikelola secara eksternal

Biarkan saya mengingatkan Anda bahwa langganan Apple, yang kami anggap sebagai contoh, dikelola secara eksternal. Ini berarti bahwa pengguna setelah pembelian dapat mengelolanya secara tidak sinkron: tutup, ubah tanggal kedaluwarsa, minta pengembalian dana. Kita melihat ini pada langkah 9. Karena tindakan terjadi di luar sistem kami, pada gambar saya menandainya dengan garis putus-putus.

Pada langkah 10, App Store dapat mengubah status berlangganan: perpanjang, tutup, masukkan masa tenggang di jendela.

Agar kami dapat mengetahui status berlangganan, ada langkah 11, yang khusus untuk agregator seperti App Store dan Google Wallet. Pada langkah ini, sistem mengirimkan token, yang digunakan sebagai tanda terima yang diterima di awal ketika membeli langganan atau setelah pembaruan sebelumnya.

Langkah 12 adalah respons penyedia. Kami menerima cek dengan status berlangganan saat ini. Hasil dalam langkah ini tergantung pada langkah asinkron 9 dan 10.

Pada musim gugur 2018, Apple untuk semua menerapkan mekanisme notifikasi server-ke-server , yang memungkinkan Anda memberi tahu tentang perubahan yang terjadi dengan berlangganan. Tanda terima pemberitahuan tersebut ditunjukkan pada langkah 13. Untuk sebagian besar penyedia lain, mekanisme pemberitahuan server-ke-server adalah satu-satunya, sehingga dapat diperdebatkan bahwa contoh Apple mencakup seluruh variasi kasus. Dalam hal penyedia lain, langkah 13 memungkinkan Anda untuk mengecualikan langkah 11 dan 12 dari skema.

Pada langkah 14, server menghasilkan respons untuk aplikasi untuk mengubah status berlangganan.

Dengan demikian, kami mendapat grafik lengkap negara yang harus dilewati untuk memeriksa layanan berbayar.


Gambar 6. Proses lengkap mengubah status pembayaran (menggunakan contoh berlangganan yang dikelola secara eksternal)

Bagian-bagian yang tidak kita kontrol dalam sistem kita berwarna oranye, dan mereka adalah kotak hitam untuk kita.

Metode Pengujian Penagihan

Jadi, masalah teknis utama ketika menguji layanan berbayar adalah keberadaan "kotak hitam", yang hanya sedikit kita kendalikan. Ini mendefinisikan seperangkat metode yang dapat mencakup seluruh ragam kasus.

Tidak banyak metode ini, dan kami membaginya menjadi tiga kategori: pembayaran riil, kotak pasir, dan penghapusan ketergantungan eksternal dari "kotak hitam".

Pembayaran nyata

Pembayaran riil sebagai metode uji bagus karena memberikan gagasan yang jelas tentang kondisi integrasi. Kesalahan dalam melakukan pembayaran nyata adalah bukti bug tanpa syarat.

Kalau tidak, pembayaran riil buruk. Pertama, itu mahal: jelas bahwa untuk melakukan pembayaran nyata, Anda perlu menghabiskan uang nyata. Anda salah jika Anda berpikir bahwa pada akhirnya seluruh jumlah akan dikembalikan ke perusahaan: pertama, penyedia membebankan biaya untuk setiap transaksi, ukurannya, seperti yang dijelaskan di atas, tergantung pada peringkat risiko organisasi dan dapat mencapai 40% (dan bahkan lebih) ; kedua, Anda mungkin kehilangan uang saat menguji pembayaran di negara lain karena penyebaran mata uang - perbedaan antara kurs pembelian dan penjualan mata uang (Anda akan melakukan pembelian dengan kurs jual mata uang asing bank, dan pengembaliannya akan terjadi pada kurs pembelian).

Selain itu, metode ini dapat memakan waktu lama, karena Anda harus menunggu akhir periode perpanjangan berlangganan, penyelesaian masa tenggang, dan ini bisa berbulan-bulan.

Kotak pasir

Kotak pasir itu indah. Ini, pada kenyataannya, adalah fungsi yang sama yang diberikan penyedia pembayaran kepada kita dalam hal pembayaran nyata, tetapi tanpa menghabiskan uang nyata. Ini sepenuhnya didukung oleh penyedia, yang berarti integrasi dengan kotak pasir itu murah.

Masalah panjangnya pengujian dari waktu ke waktu diselesaikan, sebagai suatu peraturan, menggunakan berbagai trik. Misalnya, kotak pasir App Store menggunakan konversi kedaluwarsa berlangganan berikut.

Tabel 1. Rasio masa berlaku berlangganan asli dan berlangganan di kotak pasir Apple

Langganan kotak pasir Google Wallet terdaftar di tabel 2 dan dapat dikonfigurasi di konsol penjual.

Tabel 2. Mengatur durasi berlangganan di kotak pasir Google

Berbeda dengan kotak pasir Apple, Anda juga dapat memeriksa uji coba, masa tenggang, dll., Di kotak pasir Google, menggunakan rasio dari Tabel 3.

Tabel 3. Validitas fitur berlangganan tambahan di kotak pasir Google

Menutup langganan juga dapat diimplementasikan dengan berbagai cara: di kotak pasir App Store, penutupan dilakukan setelah pembaruan kelima, dan di Google Wallet itu dilakukan dari konsol penjual atau pada perangkat dari Play Store.

Masalah dengan kotak pasir adalah bahwa penyedia memiliki sikap yang berbeda terhadap kualitas mereka. Pengalaman kami menunjukkan bahwa dari lebih dari 70 penyedia pembayaran yang terintegrasi ke Badoo, hanya dua kotak pasir yang memiliki fungsionalitas penuh dan operasi yang stabil. Ini adalah kotak pasir Adyen dan PayPal. Penyedia lain memiliki stabil, tetapi terpotong dalam hal fungsi kotak pasir (seperti Google Wallet), atau tidak stabil dan sangat terpotong dalam fungsionalitas (seperti App Store dan Fortumo). Dan ada penyedia yang tidak memiliki dan tidak akan memiliki kotak pasir sama sekali.


Gambar 7. Klasifikasi kotak pasir berdasarkan stabilitas dan fungsionalitas

Menghapus ketergantungan eksternal

Jika kami meyakinkan Anda bahwa pengujian menggunakan pembayaran riil mahal dan tidak efisien, dan penyedia pembayaran tidak menyediakan kotak pasir dengan kualitas yang tepat, maka tetap beralih ke berbagai cara untuk menghilangkan ketergantungan eksternal. Hanya ada tiga di antaranya: moki, palsu, dan bertopik.

Moki dalam penagihan adalah pembentukan reaksi sistem Anda terhadap permintaan dengan parameter yang telah ditentukan tanpa panggilan nyata ke penyedia pembayaran (lihat Gambar 8). Misalnya, permintaan ke penyedia pembayaran SMS ke nomor + 7111-111-11-11 dicegat pada tahap pengiriman permintaan ke penyedia dan menghasilkan respons sistem dalam bentuk pembayaran yang berhasil. Permintaan ke nomor + 7111-111-11-12 juga disadap, tetapi menyebabkan reaksi terhadap kesalahan dengan kode "Tidak ada cukup uang untuk menyelesaikan transaksi."


Gambar 8. Diagram tiruan

Palsu dalam penagihan adalah palsu notifikasi (seolah-olah berasal dari penyedia nyata) (lihat Gambar 9). Integrasi dengan masing-masing penyedia menyiratkan serangkaian reaksi sistem terbatas pada serangkaian jenis pemberitahuan atau pengaturan ulang yang terbatas. ( ), .


9.

— (. . 10), .


10.

, , . (, , ) . , , , , .

. 3, 4, 5 : , . - : , — , — . « ».


11. ( App Store)

, (, ). — , . . , , , . , . , .

. , ? :

• — ?
  
• end-to-end — : - ?
  
• — : , .
  

.


4.

. . . , . : , .

. , , Apple Google, . ( ). end-to-end : . , , .

, , — . . . : .

, , .

, . .

: . , , — .

, : — , , ; — : .


12.

, , , , .

, 12, Badoo.

. . QA- . , . , - , , . , .

: .

, , — . , Apple . . , . : - .

— , . -, . -, , -, , .

— : , Apple . 1 — , .

. , . , - .

, ( ).

Kesimpulan

1. , .
   
2. ( ) . , .
   
3. « » , . - — . , : , — , — .
   
4. Ketika menggunakan palsu, mokas, dan bertopik, penting untuk diingat bahwa ini adalah model pembayaran nyata, dan, seperti model lainnya, mereka memiliki tingkat perkiraan terhadap realitas dan risiko. Risiko-risiko ini harus dinilai dan ditanggung oleh pembayaran aktual atau dengan cek tambahan.
   

Tentang bagaimana kami berhasil mencapai otomatisasi yang stabil dan murah dari pengujian layanan berbayar di aplikasi iOS, kami akan memberi tahu di artikel berikutnya .

Terima kasih atas perhatian anda! Semua keuntungan besar dan lebih sedikit bug!