Pembayaran online telah menjadi sesuatu yang biasa seperti wi-fi di rumah dan internet seluler berkecepatan tinggi. Dan mereka terus berkembang, semakin banyak layanan dapat dibayar dalam beberapa klik atau dari aplikasi mobile, dan di sini juga pembayaran otomatis, pengingat, kontrol biaya dan banyak lagi.
Dalam mengejar fungsionalitas, jangan lupakan pengguna, karena tugas utama kami adalah membuatnya nyaman untuk melakukan pembayaran dalam skenario apa pun. Ini berarti bahwa bentuk pembayaran harus sejelas mungkin, dan juga menawarkan opsi kepada pengguna untuk menyelesaikan masalah jika tiba-tiba muncul.
Nama saya Georgy Konnov, saya adalah Direktur Pengembangan Produk untuk E-Commerce di QIWI, dan hari ini saya akan memberi tahu Anda bagaimana kami mengembangkan formulir pembayaran yang dapat disambungkan dengan cepat oleh toko mana saja untuk menerima pembayaran.
Di bawah potongan - tentang konversi, motivasi pengguna, protokol kami, amal dan open source.
Salah satu indikator utama keberhasilan bentuk pembayaran adalah, tentu saja, konversi. Nah, serius, jika Anda membuat bentuk yang indah luar biasa menggunakan teknologi terbaru dan panduan dari perusahaan terbaik, tapi itu bodoh tidak membawa uang karena konversi rendah - itu berarti Anda membuat sampah, bukan bentuk pembayaran.
Hampir setiap orang sekarang mengatakan bahwa tingkat konversi untuk bentuk pembayaran sekitar 99 persen, atau bahkan lebih tinggi. Ini tidak benar.
Jika kami mengukur dan mengevaluasi dengan jujur motivasi orang untuk melakukan pembayaran, Anda dapat melihat bahwa itu sangat tergantung pada kategori pembayaran (jika diukur dari pembukaan formulir pembayaran hingga pembayaran dilakukan). Motivasi maksimum adalah untuk menyelesaikan proses pembayaran di mana pengguna telah melewati sejumlah prosedur kompleks - identifikasi dan sebagainya, berbagai pembayaran b2b, dan pembaruan domain yang sama, misalnya. Kemudian orang tersebut membuka formulir dengan keinginan yang jelas untuk memperbarui domain (jika tidak akan jatuh) atau melakukan pembayaran penting - dan dia akan melakukannya.
Tetapi jika ini adalah pembelian reguler, maka di sini Anda dapat dengan mudah kehilangan seperempat pelanggan dalam proses pembayaran. Di sini, konversi sudah ada di wilayah 75-85 persen.
Ada banyak alasan. Jika itu semacam pembelian spontan ("Saya lelah, saya akan membeli emas dengan cepat dan saya akan membungkuk"), maka klien mungkin tidak memiliki cukup uang. Atau di jendela terakhir dia akan melihat sekali lagi jumlah yang sudah siap untuk didebit dari akunnya, dan akan memutuskan bahwa itu tidak buruk tanpa emas. Dan akan menutup formulir tanpa menyelesaikan pembayaran.
Dan sepertinya dengan barang asli - bidang tambahan dapat terganggu di sini, seseorang akhirnya ingin membeli penyedot debu, dan formulir meminta nomor telepon, surat, dan nama panggilan kucing (kami di sini khusus tentang permintaan formulir pembayaran, bukan akun pribadi toko) yang membutuhkan serangkaian data untuk pengiriman dan pelacakan pesanan). Atau semuanya baik-baik saja dengan formulir, tetapi melihat harganya, orang tersebut memutuskan untuk memeriksa harga di Pasar yang sama lebih menguntungkan, dan meninggalkan formulir.
Namun, agak mengejutkan melihat perilaku serupa ketika membayar untuk layanan pendidikan. Tampaknya di sini tekadnya jelas lebih tinggi daripada keinginan untuk membeli sesuatu untuk diri sendiri dengan pergi ke situs web toko dari surat dengan subjek "Hanya hari ini, diskon 80% untuk semuanya *!".
* untuk hampir semuanya
** pada dua setrika itu dan membangun kembali SEArtinya, orang tersebut hanya memilih kursus yang tepat untuk spesialisasi yang diinginkan, membuka formulir pembayaran - dan masih angka konversi yang sama kecil, seperti dalam amal.
Seperti yang diukur
Sebagian besar melakukan pengukuran seperti ini.
Ada entitas seperti transaksi. Itu bisa berhasil atau tidak berhasil. Jika tiba-tiba tidak ada uang di akun klien, kesalahan ditampilkan bahwa formulir tidak dapat mempengaruhi. Yah, tidak ada uang dan tidak, jangan berikan. Atau kesalahan teknis telah terjadi. Akibatnya, ternyata dari total jumlah pembayaran dengan pendekatan ini, 98-99 dianggap berhasil.
Tetapi jika Anda mengukur dari saat formulir pembayaran dibuka sampai pembayaran berhasil, angkanya akan berbeda.
Kami mengikat seluruh cerita ini ke akun. Ada faktur, pada saat membuka formulir itu terbuka dan hidup 45 hari. Artinya, seseorang dapat kembali ke bentuk pembayaran yang sama dalam 45 hari ini dan menyelesaikannya jika, karena alasan tertentu, ia berubah pikiran lebih awal. Ini memungkinkan kami untuk melihat konversi penuh, bahkan jika orang tersebut kembali setelah beberapa hari - hanya satu akun, dan jumlah total diperoleh. Nah, seperti yang diperlihatkan oleh praktik, orang bisa kembali ke proses pembayaran.
Tentang pengingat
Pengingat adalah cerita lain sekaligus. Kami mencoba berbagai mekanik di sini. Diharapkan hal menyebalkan pergi dengan mendorong web. Misalnya, ada seseorang di situs web toko, memutar keranjang, menerima faktur dalam formulir pembayaran, yang tidak ia bayar, dan menutup jendela - dan kemudian ia menerima dorongan web "Bayar tagihan". Hal seperti itu menyebalkan. Selain itu, mendorong web tanpa konteks yang memadai sudah dianggap sebagai spam.
Nah, 10 persen pengguna akan berlangganan push semacam itu. Kemudian 10 persen akan melewati mereka. Secara umum: untuk situs rata-rata, dengan memperhitungkan lalu lintas akun, angka-angka tersebut membuat web mendorong bukan saluran pengingat yang paling berguna. Dan jika Anda juga memperhitungkan bahwa pangkalan meriam tersebut per bulan adalah busuk 15 persen ...
Tetapi apa yang berhasil dengan bang - jika seseorang pada saat pembayaran menunjukkan pembayaran sebelumnya yang terlupakan, maka ini dianggap sebagai pengingat yang berguna.
Sebagai contoh. Persetan kamu membeli mainan baru di Steam. Saya memilih, mulai memesan, saya menyadari bahwa tidak akan ada cukup uang sekarang, atau hanya memutuskan untuk menundanya nanti. Seminggu kemudian, saya pergi untuk membeli sumbu pada Ali, Anda melakukan pembayaran, dan kemudian formulir untuk Anda - "Pst, Anda ingin membeli mainan seminggu yang lalu, lihat." Dan pengguna tersebut biasanya pergi dan menyelesaikan pembayaran sebelumnya.
Dengan angka - push web membawa 3 rubel ke milis.
Pengingat serupa adalah 60 rubel.
Mekanika seperti itu berfungsi untuk penyedia yang terhubung ke Dompet. Dan ternyata situasi win-win, ketika masing-masing penyedia terhubung dapat meningkatkan konversi yang lain.
Operasi protokol
Sebelumnya, kami hanya punya protokol dompet, saya sudah menulisnya di
sini .
Hanya ada
Dompet di dalamnya . Dan tahun ini kami mengumumkan protokol baru di mana sekarang Wallet, dan akuisisi, serta perdagangan seluler, dan angsuran menurut Hati Nurani kami, akan menjadi sekumpulan metode pembayaran lainnya. Semua ini dalam satu solusi, dalam satu protokol.
Tujuan kami adalah membuat statistik transparan untuk semua orang. Oleh karena itu, kami meninggalkan akun, yang memungkinkan kami memantau konversi aktual toko setransparan mungkin, daripada teknis. Dan kami menambahkan semua mekanisme yang membantu meningkatkan pergantian. Semua turnkey.
Dari luar mungkin tampak sederhana semua ini - taruh beberapa bentuk pembayaran, dan hanya punya waktu untuk menghitung uang. Tetapi pada kenyataannya, ternyata pembeli mungkin tidak memiliki dana pada kartu. Ya itu terjadi.
Dan di sini dalam bentuk kami segera menawarkan alternatif dalam kasus seperti itu. Tidak cukup membayar? Lihat, mungkin untuk membayar dengan cepat dari ponsel kami melalui SMS. Atau, secara umum, menurut Hati Nurani, di sini. Atau yang lainnya.
Penting bahwa klien melihat dalam kasus ini tidak hanya masalah, tetapi juga pilihan untuk menyelesaikannya. Artinya, dengan tidak adanya uang, itu bukan "Tidak cukup uang" sebagai kesalahan yang hanya mengarah pada menutup jendela atau mencoba memasukkan kartu lain, tetapi segera menawarkan metode pembayaran lain tanpa menggunakan pengguna.
Pendekatan ini meningkatkan konversi akhir menjadi pembayaran yang berhasil. Karena untuk meningkatkan konversi, Anda tidak dapat fokus pada tingkat perolehan. Secara umum, setiap upaya untuk fokus pada tingkat adalah upaya untuk bersaing dengan bank hijau besar, yang memiliki biaya perolehan terendah, karena mampu.
Tetapi Anda dapat bersaing dalam konversi dalam pembayaran. Jauh lebih mudah untuk menaikkannya dengan 2-3 3-5 persen daripada mencoba menurunkan tingkat perolehan (yang sudah ada di wilayah 2).
Oleh karena itu, kami memutuskan untuk menyederhanakan bagian TI sebanyak mungkin dan menambahkan semua mekanisme yang tersedia ke checkout. Untuk mengambilnya dan dengan cepat menghubungkannya - dan semuanya bekerja untuk Anda.
Bukan web tunggal
Menurut saya, hanya yang malas tidak berbicara tentang peran ponsel dalam belanja online. Jadi saya akan mengulangi tesis terkenal dan menambahkan sedikit nomor kami.
Pada 2015, kami mendapat sekitar 10 persen panggilan dari ponsel. Dan ada aplikasi seluler keren di 3 teratas di pasar. Ada pilihan - baik melihat aplikasi web terpisah untuk seluler, atau membuat checkout adaptif sederhana. Kami memutuskan untuk tidak repot saat itu dan ketika percobaan membuat adaptasi sederhana ke ponsel. Dan selama enam bulan, angka ini telah meningkat dari 10% menjadi 30%.
Setahun yang lalu - sekitar 40 persen.
Sekarang - 51-52.
Secara umum, berbelanja dari ponsel sebenarnya adalah dofiga. Karena itu, kami membuat tata letak seluler yang sangat bagus. Kami melihat peningkatan pembayaran, memutuskan untuk melakukan beberapa studi lagi dan berbicara dengan mitra di pasar. Ternyata mereka yang beradaptasi dengan ponsel mengalami pertumbuhan penjualan. Mereka yang mencetak gol di ponsel memiliki sekitar 10% yang sama.
Di sini, omong-omong, adalah diagram yang menunjukkan distribusi penjualan tergantung pada apakah toko disesuaikan atau tidak. Ada 14 toko online besar, yang tidak akan kita panggil, tetapi hanya tahu - besar.
Siapa yang memiliki aplikasi seluler - ia sudah memiliki pembelian 1,5 kali lebih banyak. Siapa pun yang memiliki adaptasi atau aplikasi juga memiliki peningkatan penjualan, seperti halnya adaptasi yang sangat ringan.
Violet dalam diagram adalah cowok tanpa adaptif. Tetapi bahkan mereka tidak sedih seperti biru - tidak ada yang berfungsi pada ponsel ini.
Saya ingin mengatakan itu. Tidak perlu membuat aplikasi seluler kelas atas untuk mengejar lalu lintas. Bahkan aplikasi tidak meniadakan fakta bahwa adaptasi perlu dilakukan. Bahkan adaptasi halaman paling sederhana sudah akan menunjukkan hasil yang baik.
Kami mengambil langkah pertama pada tahun 2015, seperti yang saya tulis di atas. Dan sekarang kami memiliki versi baru yang cocok dengan keyboard di layar, berfungsi baik dengan Google API dan iOS dalam hal peta lengkapi-otomatis. Dan semua ini berdasarkan turn-key sehingga cepat dan nyaman. Dan sekarang kami memiliki konversi pada ponsel yang hampir sama dengan desktop. Adaptasi itu sendiri menentukan bagaimana sekarang perlu muncul di layar mana.
Dompet dan Integrasi
Dompet tidak diposisikan sebagai satu-satunya alat pembayaran. Anda tidak perlu membayar sama sekali - Anda hanya dapat mengikat kartu ke sana atau menyetujui pembayaran yang disederhanakan, dalam hal ini Wallet akan bertindak sebagai akselerator pembayaran yang sudah akrab. Jika kita melihat bahwa pengguna sangat familiar bagi kita (untuk sejumlah tanda) - kita dapat memberikan kesempatan untuk menonaktifkan 3DS, misalnya. Tentu saja, ini hanya opsi, dan jika Anda tidak ingin menonaktifkan verifikasi tambahan, maka Anda tidak perlu melakukannya.
Kami mengingat otorisasi selama enam bulan, baik dengan kata sandi dan melalui SMS. Sesi dibagi menjadi setengah token, yaitu setengah dari token bersama kami, dan setengah pada perangkat pengguna. Jika itu - dalam 1 sesi klik dapat diatur ulang.
Pembayaran ujung ke ujung bekerja di mana-mana - misalnya, bahkan dalam aplikasi ponsel AliExpress, formulir kami terbuka, di mana semuanya sudah diisi jika pembeli menggunakannya sebelumnya.
Kami memutuskan untuk mendukung kompatibilitas ke belakang, dan protokol baru yang dipompa berfungsi untuk mitra yang memperkenalkan protokol pada 2010 dan mereka yang menginstalnya hanya kemarin. Kami memiliki hampir semua ecommers aktif di basis data kami. Dan kami menyeret seluruh pangkalan ini ke alat baru.
Versi lama dipertajam di bawah terminal. Seorang pria memasukkan nomor teleponnya, faktur dikeluarkan, dan faktur ini muncul di mana-mana - di situs, di terminal, di ponsel. Penyedia yang berbeda lalu yang dalam angka yang jauh berbeda memasang masker input, yang hanya mempersulit integrasi.
Dalam versi baru dari akun yang kami simpan. Faktur dikeluarkan tanpa tanda-tanda. Penyedia memberikan nomor telepon - OK, tidak mengirim - kami bekerja tanpa itu. Perdagangan seluler memungkinkan Anda untuk menagih dan membayar segera, menggabungkan dua tindakan dalam satu permintaan. Pasangan tidak harus mempersulit hidup mereka. Jika di suatu tempat dimungkinkan untuk mengurangi jumlah permintaan, maka kami menjauh dari sisanya yang kanonik, yang menyederhanakan kehidupan pengembang selama integrasi.
Integrasi, omong-omong, juga disederhanakan secara maksimal. Protokol ini dirancang tidak hanya oleh para teknisi, tetapi juga di bawah pengawasan ketat sebuah bisnis. Dan bukan dalam hal pemantauan dan penyesuaian, tetapi dalam hal memperhitungkan di awal semua kesulitan bisnis dan menyederhanakan semua integrasi masa depan. Protokol lama memiliki 5 parameter - ID penyedia, kata sandi rahasia, ID otorisasi, mata uang, kata sandi untuk pemberitahuan.
Di baru - 2 parameter. Kunci publik untuk formulir web, yang dapat bersinar di luar, dan kunci rahasia, yang digunakan dalam API server dengan hak akses penuh, kemampuan untuk membatalkan transaksi, membuat pengembalian uang, dan banyak lagi.
Ditambah lagi, kami memungkinkan untuk mentransfer data tambahan apa pun. Sebelumnya, Anda harus mengetahui ID akun dan nomor telepon. Dan sekarang ada bidang khusus - Saya ingin penyedia memperoleh pengenal pelanggan internal - tolong. Penting untuk melemparkan nomor telepon, alamat untuk pengiriman - itu saja. Secara umum, agar tidak menulis logika Anda sendiri untuk semua ini, Anda bisa meneruskannya ke kami. Dan di semua pemberitahuan, setelah pembayaran berhasil, data tersebut akan dikembalikan.
Protokolnya modular, Anda dapat mengganti widget dan preorder, kami secara aktif mengujinya untuk amal.
Sebelumnya, semuanya dalam monolit. Di mana ada pemrosesan. Kemudian ia mulai tumbuh terlalu cepat di sisi-sisinya dengan gizmos tambahan yang berguna. Sekarang ternyata pemrosesan sebenarnya bertanggung jawab untuk melakukan transaksi. By the way, untuk kartu kami menulis yang baru - dipercepat agar tidak menyeret warisan zaman.
Kontribusi Amal
Beberapa tahun yang lalu kami duduk dan berpikir bagaimana menggabungkan pembayaran dan dukungan yayasan amal secara normal dan penuh. Pikiran pertama adalah melemparkan sedikit (dengan sendirinya, jika pengguna ingin dan kotak centang yang sesuai) langsung ke cek. Yaitu, Anda membeli satu teko untuk 5000 rubel, beri tanda centang "Saya ingin membantu" - dan sekarang Anda memiliki cek untuk 5050, misalnya, Anda membayar untuk itu. Total satu transaksi, di mana bagian dari uang itu pergi ke toko, dan sebagian - ke dana.
Gizmo tidak dapat diukur dari kata secara umum. Departemen akunting perusahaan tempat kami mentransfer melorot - di sini dalam kasus-kasus seperti itu perlu untuk membuat perjanjian rangkap tiga yang kompleks (kami, perusahaan, dana).
Dan kembali itu sulit. Anda berubah pikiran tentang teko, mengembalikannya. Dan jumlah untuk ketel dan biaya masuk dalam satu transaksi.
Jadi kami memutuskan untuk melakukan ini.
Setelah pembayaran berhasil, pengguna diundang untuk memberikan sumbangan kecil dalam 1 kali klik. Skema seperti itu berhasil, sekitar 3-5 persen siap untuk melakukannya. Di sini jumlah utamanya. Jika tidak melebihi 50 rubel, maka ini OK dan sederhana. Jika lebih, maka konteks sudah dibutuhkan ke mana uang akan pergi, dan untuk apa dana itu, dan apa yang mereka lakukan, dan seterusnya.
Orang muda dalam hal ini lebih sederhana - mereka melihat bahwa ada merek A yang mereka percayai (toko), mereka melihat merek B, dan semuanya baik-baik saja, mereka menerjemahkan. Dan orang yang lebih tua membutuhkan konteks terperinci untuk memastikan dana itu nyata, dan bahwa 50 rubel ini bukan untuk BMW baru untuk karyawan toko.
Kami mencoba menghitung jumlah sumbangan dengan berbagai cara. Misalnya, seseorang membeli sesuatu, dan setelah pembelian, 123 rubel akan tetap ada di akunnya. Dalam kasus seperti itu, kami mengusulkan untuk mengumpulkan dan mentransfer ke dana 3 rubel atau 23 rubel. Nah, buat apa besi ini sedikit di dompet elektronik, yah, kebenarannya.
Ternyata di sini kami terlalu tergerak, dan pendekatan ini tidak berhasil dengan baik. Di mana curam tepatnya jumlah tetap kecil. Biasanya sekitar 5 persen sisanya.
Pembayaran amal yang sebelumnya secara langsung diakui di situs web untuk dana Khabensky adalah sekitar 20 per bulan. Itu menjadi sekitar 30.000 - 35.000 per bulan. Kami memulainya dan berpikir bahwa akan menyenangkan untuk menunjukkan ini tidak hanya dari pembayaran dari Dompet, tetapi juga dengan kartu lain dan seterusnya.
Kami menemukan pada akhirnya bahwa orang tidak memerlukan pembayaran seperti itu dalam 1 klik, jika mereka ingin melakukan pembayaran dari kartu, mereka akan memilih metode itu sendiri. Ngomong-ngomong, mereka memotong hipotesis, hanya seminggu sebelum Mei.
Ngomong-ngomong, Anda dapat mencoba formulir pembayaran kami, dan pada saat yang sama melakukan perbuatan baik dengan mendukung salah satu dana:
- Iman - Perawatan Sistemik untuk Rumah Sakit dan Pasiennya
- Yayasan Khabensky - membantu anak-anak dengan penyakit otak parah
- {untuk semua - ke beberapa dana amal dengan porsi yang sama sekaligus
Dan pemilik situs dapat membantu dana apa pun dengan memposting widget atau tautannya sendiri:
widget.qiwi.com/vera ,
my.qiwi.com/bfkh ,
my.qiwi.com/vsem atau banyak lainnya. Tulis jika Anda mau.
Sumber terbuka
Sekarang menuju open source kami bergerak cukup aktif. Kami menerbitkan dokumentasi, contoh, SDK, dan integrasi di
https://github.com/QIWI-API/ . Membaca
dokumentasi , Anda dapat mengklik tombol "edit pada GitHub" dan membuat permintaan untuk koreksi.
Secara umum, kami mencoba menyeret semua yang tidak diproses menjadi sumber terbuka.
API GitHub QIWI dan
GitHub QIWI menjadi hidup. , , , SDK QIWI API — . GitHub.
API , , , . , QIWI BaaS, Bank as a Service. — , . .
QIWI — , . . — Apple Pay Google Pay. , , , .
CMS-, QIWI . Wordpress , — .
54 2- .
Kassa.qiwi.com — . , .
, API,
, .
, , — .
PS , :
kassa.qiwi.com/teamReact JS- Java-. JS Fullstack
15, , , . , . :)