Seperti rasa sakit, rasa sakit, kasir sebagai layanan 2: 0

Dalam artikel sebelumnya , kami berbicara tentang bagaimana Anti-Plagiarisme memilih "awan" untuk dirinya sendiri. Dalam pembicaraan ini tentang komponen penting kehidupan perusahaan komersial - menerima uang dari pelanggan.

Untuk menerima pembayaran dari klien pribadi, kami selalu menggunakan layanan agregator. Pada awalnya, kami ingin melakukan diversifikasi antara layanan penerimaan pembayaran, kemudian muncul persyaratan untuk menerbitkan cek elektronik ... Singkatnya, ada banyak keinginan dan persyaratan hotel baik di pihak kami maupun di negara bagian. Dalam artikel ini, kami akan berbagi pengalaman dan berbicara tentang menyapu rumput tinggi yang harus kami injak dan yang berhasil kami hindari. Saya pikir pengalaman yang dijelaskan dapat bermanfaat bagi semua orang yang masih berada di awal jalur mengintegrasikan pembayaran ke dalam sistem mereka.



^{Gambar dari giphy.com}

Ada dua kasir riang di nenek ...

Klien pribadi kami memeriksa dokumen perusahaan 3 kali lebih banyak. Sejak awal bisnis kami dan sampai sekarang, kami telah dengan hati-hati menjaga kemungkinan pencarian gratis untuk pinjaman di Internet. Layanan berbayar memiliki keunggulan sebagai berikut:

• prioritas lebih tinggi saat memeriksa
• kurangnya pembatasan jumlah dokumen yang diperiksa per unit waktu;
• ketersediaan berbagai pilihan modul pencarian untuk dihubungkan.

Biaya layanan berbayar terdiri dari kontribusi kepada penyedia konten dan biaya pemeliharaan infrastruktur audit (termasuk yang gratis) untuk pelanggan pribadi.

Sekarang satu pemeriksaan pada Joint Collection (OK), yang mencakup semua modul pencarian yang mungkin, biaya 270 rubel. Cek tunggal sudah cukup untuk pengguna biasa, dan untuk pengguna biasa, pengecekan tidak terlalu mahal. Mereka yang mengecek secara besar-besaran, secara kondisional kita bagi diri kita menjadi dua kelas: jujur ​​dan tidak jujur. Jika ini adalah organisasi yang bergerak dalam pendidikan atau membutuhkan layanan pemeriksa pinjaman untuk mengontrol kualitas karya ilmiah atau tekstual lainnya, kami menawarkan untuk menjadi klien korporat kami, yang mengurangi biaya klien dalam hal satu cek. Untuk "tuner" dan penulis khusus (tebak kategori apa yang mereka miliki) jalur ke segmen korporat ditutup. Itu prinsip kami, kami tidak menyimpulkan kontrak dengan perusahaan yang diragukan, menurut pendapat kami. Kami juga mengontrol aktivitas klien kami untuk mencegah penggunaan akun perusahaan dalam tujuan "bisnis" (heuristik, pembelajaran mesin, itu saja). Dalam sejarah kami, ada beberapa pemutusan kontrak setelah kami mengetahui bahwa klien itu bukanlah klien yang ia klaim. Sayangnya, kami tidak dapat membuat perjanjian dengan setiap pengguna pribadi, oleh karena itu tawaran digunakan untuk mereka. Ini nyaman bagi pengguna pribadi, tetapi pada saat yang sama, kami tidak dapat mengontrol siapa yang menggunakan akses berbayar, karena toko tidak dapat melarang pembelian barang yang dipamerkan darinya. Biaya inspeksi massal untuk pelanggan pribadi akan meningkat terus. Karena itu, kami membuat karya tulis untuk memesan kesenangan yang mahal dan mematuhi misi kami untuk meningkatkan pendidikan di Rusia dan dunia.

Bagaimana semuanya dimulai

Layanan kami mentransfer beberapa layanan yang sebelumnya gratis untuk klien pribadi ke kategori layanan berbayar pada 4 Mei 2010. Hingga saat ini, semua fungsionalitas tersedia sepenuhnya, hanya pemeriksaan pada koleksi eksternal yang dibayar, dan kami, pada gilirannya, membayar penyedia konten itu sendiri. Kami membuat layanan berbayar pembentukan laporan lengkap. Jelas, pengguna tidak senang dan mudah menghitung pendapatan luar biasa kami.


^{Cuplikan layar pernyataan April-Mei 2010 dari forum kami.}

Sayangnya, saya masih belum memiliki real estat di Siprus, meskipun faktanya saya menulis tagihan versi pertama.

Sentuhan Robot Pertama

Untuk meluncurkan pembayaran massal, kami menggunakan solusi yang sudah terbukti - integrasi dengan Robokassa (RK). Hingga 4 Mei 2010, kami menerima pembayaran untuk ujian disertasi dan dokumen hukum. Layanan RK cocok untuk kami. Integrasi itu sesederhana sepatu bot yang dirasa, di pihak kami kami harus melakukan minimum: hanya mengarahkan ulang ke situs checkout dan petugas callback checkout tentang status pembayaran. Skenario tindakan pengguna standar adalah sebagai berikut:

1. Pengguna memilih produk di situs, klik tombol bayar.
2. Situs (dengan partisipasi layanan penagihan, tetapi ini tidak begitu penting dalam konteks saat ini) mengalihkan ke layanan Robokassa, menunjukkan pengidentifikasi toko, produk dan jumlah pembayaran.
3. Pengguna di situs membayar barang.
4. Layanan meja kas menerima uang dan memberi tahu kami tentang pembayaran melalui telepon balik (panggilan balik, dalam bahasa Rusia).
5. ... keajaiban sedang terjadi di sini ...
6. Untung !!! Uang ditransfer ke rekening perusahaan dikurangi komisi.

Semuanya sudah diatur dan bekerja selama bertahun-tahun. Dan seperti yang Anda tahu: itu berfungsi - jangan sentuh! Itu tidak bisa bertahan selamanya, saya harus mengubah sesuatu.

Y (et) a (nother)

Kita hidup dalam masa perubahan dan peluang yang bergejolak. Pada akhir Desember 2015, proses pencabutan izin dari bank sedang berjalan lancar, dan karena sistem pembayaran apa pun terkait dengan bank, kami memutuskan bahwa kami memerlukan opsi cadangan. Paket B tidak akan mengizinkan kami pada titik tertentu untuk tetap tanpa kemampuan untuk menerima pembayaran. Dari agregator pembayaran yang kurang lebih besar, pilihan jatuh pada Yandex.Kassa (Yak). Tugas dilakukan dalam waktu singkat, selama 3 hari terakhir bulan Desember, dan kami pergi berlibur dengan bagian belakang yang tertutup. Ngomong-ngomong, risiko dalam kaitannya dengan Kazakhstan tidak direalisasikan, tetapi kami mendapatkan sistem pembayaran alternatif. Jangan dibuang! Sejak itu mereka bekerja bersama. Dua angsa lucu!

Pengalaman belum diterapkan

Seperti yang sudah saya tulis, kami ingin mengembangkan Anti-Plagiarisme dan tidak terlalu terganggu oleh hal-hal sampingan. Layanan berbayar untuk klien pribadi adalah peluang untuk terus memberikan layanan gratis.
Kebetulan kami menerapkan integrasi dengan cara sesederhana mungkin yang ditawarkan oleh masing-masing agregator pembayaran. Karena itu, kami memiliki halaman pembayaran yang sangat jelas dengan dua mekanisme berbeda untuk dua meja kas yang berbeda.


Untuk Republik Kazakhstan, pilihan metode pembayaran terjadi setelah masuk ke halaman agregator, untuk UC - di halaman kami, sebelum transisi. Untuk memahami korelasi antara profil pembayaran dengan beban di bawah, biru adalah bagian dari uang yang diterima melalui Kazakhstan, dan oranye adalah jumlah cek yang dibayarkan.


Jadi, tanpa benar-benar mengkhawatirkan implementasi, kami menguji kegunaan dua opsi untuk antarmuka pembayaran. Tampaknya pengguna lebih menyukai opsi UC. Semburan di atas 50% adalah karakteristik dari awal penggunaan UC dan periode ringan ketika jumlah pembayaran lebih sedikit. Rupanya, pada saat ini, fakta bahwa RC terletak lebih tinggi dan dipilih secara default lebih terpengaruh.

Babusya Atol FF Dekhovna

Segera lakukan reservasi: kami tidak melanggar hukum fisika dan Federasi Rusia. Oleh karena itu, bersama dengan semua orang, mereka mulai mencari solusi untuk menulis cek mulai 1 Juli 2017 sesuai dengan Undang-Undang Federal No. 290 . Dicari sebelumnya, hanya selama sesi musim semi berikutnya. Segera menjadi jelas bahwa kami tidak akan memasang kasir dan merobohkan cek secara manual.
Dengan tenggat waktu yang ditentukan oleh negara, kita, seperti banyak perusahaan di negara ini, tidak memenuhi tenggat waktu. Ini terjadi karena alasan biasa karena kurangnya kantor pemesanan online sebagai layanan. Saat itu, banyak yang menawarkan berbagai pilihan lain. Misalnya, di Robokassa ada opsi dengan penjualan barang-barang mereka di toko mereka. Tampak entah bagaimana tidak terlalu. Yang terpenting, kami terkesan dengan pendekatan KaaS - checkout sebagai layanan. Salah satu yang pertama (jika bukan yang pertama) layanan seperti itu ditawarkan oleh Atol.
Terlepas dari kegembiraan itu, kami dengan cepat membuat kesepakatan, membeli dan mendaftarkan drive fiskal - flash drive khusus untuk menyimpan semua transaksi yang gagal melalui cash register.
Itu menunjukkan bahwa kedua angsa kita segera mulai mendukung integrasi dengan Babusey-Atol. Seperti yang dikatakan dalam kisah itu: kami mulai hidup, hidup, dan menjadi baik.

Transisi ke FFD 1.05

Semua orang tahu bahwa perlu memulai kehidupan baru pada 1 Januari (segera setelah Anda bangun, ya). Benar, ini jelas bukan waktu terbaik untuk pengenalan perubahan legislatif. Namun, sejak 1 Januari 2019, kita semua harus beralih ke versi baru dari format dokumen fiskal (FFD) 1.05. Perubahannya murah, tapi saya masih bergidik dari ingatan akan peristiwa pembaruan ini.

Studi masalah menunjukkan bahwa perlu menambahkan hanya dua parameter ke nilai yang ditransfer: objek perhitungan (payment_object, payment_subject) dan metode perhitungan (payment_method, payment_mode). Untuk satu-satunya produk kami, skor Anti-Plagiarisme, yang menunjukkan pasangan parameter ini tidak dikenakan biaya. Berikut adalah garis besar rencana sederhana untuk mencapai tujuan Dukungan Go to FFD v1.05:

1. Saring situs sehingga melewati beberapa konstanta baru dalam permintaan;
2. Periksa dengan agregator bahwa mereka memahami dan menerima semua ini;
3. Ubah format Atole FFD ke versi 1.05;
4. ... keajaiban sedang terjadi di sini ...
5. Untung !!!

Parameter tidak berubah dalam waktu dan tidak bergantung pada apa pun, atur sekali - dan itu saja, freebie. Jadi mereka pikir, pada kenyataannya, semuanya ternyata tidak begitu mudah sama sekali ... Apa yang salah?

1. Departemen pengembangan menyelesaikan situs Anti-Plagiarisme, kami meluncurkannya ke prod. Kami memeriksa dengan dukungan teknis dan spesialis dari kedua agregator bahwa semuanya berfungsi dan data baru dikirimkan dengan benar.
2. Dalam proses perubahan, salah satu agregator melihat informasi baru untuk dirinya sendiri: nilai bidang "situs" harus bertepatan simbolis dengan nilai yang ditentukan dalam Atola (WTF ₁ - mengapa persyaratan untuk kebetulan ini, karena ada INN dan segala macam hal lainnya?) Seperti yang ternyata kemudian, ini sangat penting.
3. Ok, mari kita berubah. Di Atola, pada satu halaman di akun Anda ada bidang dengan alamat situs web dan sedikit tentang transisi ke versi FFD 1.05. Hebat! Saya mengubah situs menjadi www.antiplagiat.ru (saya menghapus http yang berdiri di sana sebelumnya, menambahkan www) dan menaruh daw pada transisi ke versi FFD 1.05. Tiga hari kerja untuk perubahan (WTF ₂ - apakah benar seorang insinyur pergi ke sana dan mengubah firmware meja kas?)! Sekitar Nuuuuu. Sejauh ini saya akan memaparkan nilai situs yang sama pada agregator. Berubah Itu saja, kami sedang menunggu perubahan di 1.05.
4. Pagi berikutnya saya menerima informasi bahwa cek tidak dikalahkan. Atol berhasil lebih cepat dari tiga hari kerja dan mengubah versi FFD, tetapi tidak mengubah alamat situs: antiplagiat.ru (WTF ₃ - bagaimana???! Apakah Anda mengubah situs dengan tangan di suatu tempat?). Ketika mengubah alamat situs, RK sendiri dengan diam-diam menambahkan "http: //": www.antiplagiat.ru (WTF ₄ - Saya ingin cek menjadi lebih kecil dan tanpa protokol, tetapi tidak akan berhasil karena satu agregator). Yak suka dilakukan dengan baik, semuanya bekerja sebagaimana mestinya www.antiplagiat.ru . Total - cek tidak ditulis untuk agregator mana pun, karena di mana pun ada nama yang berbeda untuk situs tersebut. Tapi saya secara khusus membuatnya sama sehari sebelumnya!
5. Saya bersumpah dengan semua orang di telepon, Atol tampan, mereka punya satu biaya untuk setiap permintaan: 3 hari kerja. Saya mematikan RK, karena mereka tidak dapat mengubah situs ke yang saat ini terdaftar di Atola, karena situs tersebut harus dengan http atau https. Saya mengubah situs di UC menjadi yang sekarang di Atola (manfaatnya dengan cepat berubah di sana dan tidak ada persyaratan http). Hore, cek mulai ditulis! Atol itu ternyata dimotivasi oleh pidato saya di telepon dan dalam setengah jam mengubah situs tersebut menjadi www.antiplagiat.ru (format ini cocok dengan Republik Kazakhstan). Pada saat ini, merobohkan cek di UC berhenti bekerja, karena di sana situs lama terdaftar. Saya mengubahnya melalui akun pribadi saya, itu tidak berubah, saya sebut TP, mereka berubah. Nyalakan RK.
6. Fuh, sepertinya bekerja di mana-mana. Masih berurusan dengan cek tidak tertulis. Ada beberapa ratus di antaranya. RK - atas permintaan ponsel berjalan sendiri dengan nilai baru dari situs, mereka lulus. YAK:
   ^{Kucing karyawan kami}
   Penjelasan: kami mengirim cek ke Atoll, dia kembali kepada kami, kata mereka, ceknya salah. Kami telah menyimpan informasi ini dengan diri kami sendiri dan sekarang tidak ada yang bisa dilakukan dengan itu (WTF ₅ - masih membunuh saya, seolah-olah sistem mereka bukan milik mereka). 29 Desember - hari Sabtu yang bekerja (WTF ₆ - tetapi di sini bukan karena kebiasaan, Desember ternyata berhasil untuk rasa sakit, ingat artikel sebelumnya, aksi dengan awan terjadi secara paralel), bukan hari terbaik untuk melanjutkan. Apa yang harus dilakukan dengan cek yang tidak dicap, kami akan pikirkan pada bulan Januari.
7. Semuanya bekerja dengan baik, dengan jiwa yang tenang, kita akan merayakan Tahun Baru. 29 Desember, pada 20 jam, secara curang, tanpa menyatakan perang, UC mengubah alamat situs ke yang lain. Memeriksa melalui mereka berhenti dituliskan.

Mengapa mereka melakukannya, mereka tidak bisa menjelaskan. Mereka mengatakan sesuatu tentang surat dari Atola. Rupanya, pasangan ini ingin melakukan yang terbaik. Atol mengurus mereka yang tidak mengetahui persyaratan ini, karena alamat situs di agregator pembayaran dan meja kas tidak cocok. Hanya data, Anda tahu, sudah tua, setidaknya sejak pagi hari tanggal 29 Desember.

Pada pagi hari 10 Januari, kami memiliki banyak surat di dalam kotak dengan pesan dari UC tentang kesalahan yang membatalkan cek. Awal yang bagus untuk tahun ini! The cant mengenali dan diri mereka sendiri (!) Teruskan cek ini ke Atoll (well, mereka bisa, kapan saja mereka mau) Selain kasus ini, pengiriman UC UC tidak dapat dilakukan lebih dari sekali. Sebaliknya, mereka meyakinkan saya bahwa itu tidak mungkin! Apa yang perlu dilakukan untuk tetap menulis cek? Benar, bawa dengan tanganmu! Di Atola kita sampai ke halaman dengan selusin bidang yang perlu diisi. Dipenuhi, well, well, satu cek gagal. Pada pemeriksaan berikutnya, Anda perlu mengisi semuanya dengan cara yang sama (kecuali untuk beberapa bidang) lagi!
Kami memiliki banyak surat dengan kesalahan, kami harus membatalkan cek. Kami menulis skrip yang mengambil surat dari UC dan mengetuk cek di Atoll menggunakan mereka. Pakai mesin. Sepele, tetapi jika cek tidak dikalahkan, maka ini merupakan pelanggaran hukum. Saya harus memikirkan cara kerjanya di Athol. Mengapa UC tidak dapat melakukan pengiriman ulang cek di sisinya tidak jelas. Skrip ini ada di repositori publik kami yang baru dibuat di Github.

Yandex Kontradiksi. Dokumentasi

Ada banyak dokumentasi di UC, itu dengan gambar dan screenshot yang indah. Tampaknya, gunakan dan bersukacitalah. Mari kita lihat apa yang tertulis tentang interaksi dengan box office:


^{Tangkapan layar diambil 10/30/2019.}

Pada langkah 5, Atol terkadang melaporkan bahwa tidak semuanya sesuai dengan cek, dan di akun kami pembayaran dengan status "Diterima" muncul, tetapi tanpa cek. Ini karena cara yang disarankan untuk mengirim cek "3 hari sebelumnya" dipilih.


^{Pengaturan checkout online, opsi "Dengan bantuan kami". Tangkapan layar diambil 10/30/2019.}

Dan lagi poin ke 5, deskripsi proses yang tidak berfungsi sebagaimana dijelaskan. Menekan tombol di akun pribadi Anda tidak mengubah apa pun dalam status cek (dikonsultasikan dengan dukungan teknis, ia mengonfirmasi). Ceknya masih belum rusak. Itu bisa dihilangkan secara manual. Mungkin memilih "5 menit"? Mari kita lihat apa yang tertulis dalam bantuan di akun Anda.


^{Tangkapan layar dari akun pribadi Anda.}

Ternyata bagi kami metode "Selama 3 hari" tidak hanya direkomendasikan, itu wajib!

Kesimpulan

Atol. Tidak semuanya otomatis, banyak yang dilakukan dengan tangan. Orang bisa melihat betapa lambat tapi pasti antarmuka akun pribadi semakin kaya. Tarif standar untuk setiap perubahan adalah 3 hari kerja. Kadang-kadang mereka menawarkan untuk mengantar cek untuk kita, tetapi untuk beberapa alasan mereka tidak pernah mengantarnya. Untuk mempercepat solusi permintaan dalam menanggapi pesan tentang pembuatan tiket, Anda perlu mengirim NPWP ke organisasi (bahkan jika sudah ada di badan banding), mereka memiliki peningkatan prioritas otomatis, tampaknya dengan cara ini.

Yandex.Cash. Mereka tidak dapat mengirim ulang cek jika ada masalah di pihak Atol. Yang lain mungkin, mereka tidak, tetapi dalam kenyataannya mereka bisa, tetapi mereka mungkin tidak mau. Saya harus menulis naskah untuk mereka. Ada banyak dokumentasi, dan, mungkin, karena itu tidak konsisten.

Robokassa. Untuk beberapa alasan, mereka meningkatkan alamat web toko, sambil melakukan hal ini tanpa disadari. Sisanya adalah orang-orang yang baik.

FTS. Waktu asli untuk implementasi perubahan. Tidak dipikirkan hukum dan persyaratan. Sekarang register kas elektronik identik dengan fisik biasa. Jika dalam pembayaran offline toko dan merobohkan cek dilakukan oleh satu perangkat dan dua prosedur ini hampir seperti satu transaksi tunggal, maka di dunia online semuanya berbeda. Pembayaran diterima oleh satu layanan, tetapi cek tersebut dihapus oleh yang lain. Dengan analogi dengan register kas offline untuk merobohkan cek diberikan tidak lebih dari 5 menit. Lebih detail dapat dibaca, misalnya, di sini .

Pelajaran yang dipetik

Sepertinya hal-hal sepele, tetapi karena hal-hal sepele ini saya harus menghabiskan sekitar 60 jam di atas dan pengembangan / debugging skrip. Bahkan dua agregator pembayaran nasional besar bersama dengan penyedia besar KaaS tidak dapat membuat layanan di mana pengguna biasa akan menerima layanan, minimal memahami bidang subjek. Sangat menyedihkan bahwa dengan perubahan apa pun, bahkan sepele, Anda harus waspada dalam format dan, sebagai hasilnya, mendukung semuanya dengan kruk tulisan tangan Anda sendiri.

Ngomong-ngomong, dalam rutinitas yang biasa, kedua perusahaan memberikan dukungan teknis yang cukup tinggi dan layanan itu sendiri. Sangat mudah untuk melorot di telepon dengan teknisi selama satu jam, men-debug sesuatu atau mencari tahu penyebab kegagalan tertentu karena kesalahan sistem pembayaran. Semua baik-baik saja dengan dokumentasi, dengan keandalan. Yandex.Kassa hati-hati memperingatkan tentang semua kegagalan dalam sistem pembayaran dan pekerjaan yang dijadwalkan sendiri. Robokassa tidak terlihat dalam pengiriman seperti itu, tetapi ada lebih sedikit keluhan dari pelanggan kami tentang pembayaran bermasalah melalui itu, yang berarti bahwa tidak ada downtime yang khusus.

Apa yang harus dilakukan selanjutnya? Di cakrawala terbayang pembayaran proyek untuk mengoptimalkan pilihan agregator tergantung pada metode pembayaran yang dipilih oleh pengguna. Mungkin, dengan latar belakang ini, akan mungkin untuk terhubung ke beberapa penyedia lagi (saya berharap "OMG baru! Mengapa ini dilakukan?!" Dan alasan artikel tentang rasa sakit). Karena ketidakseimbangan yang kuat dari volume pembayaran selama satu tahun, tugas yang menarik dapat berubah untuk mengoptimalkan pengumpulan beberapa tas ransel: yang dikirim oleh pengguna untuk membayar guna meminimalkan kerugian pada komisi dan diskon untuk pembayaran bulanan. Jika seseorang memiliki pengalaman seperti itu dan apakah game ini sepadan dengan lilinnya, silakan bagikan di komentar!