Halo, Habr! Saya terus mempublikasikan siklus tentang bagian dalam platform pembayaran RBK.money, yang dimulai pada posting ini. Hari ini kita akan berbicara tentang skema pemrosesan logis, layanan mikro spesifik dan hubungannya satu sama lain, bagaimana layanan yang memproses setiap bagian dari logika bisnis dipisahkan secara logis, mengapa inti pemrosesan tidak tahu apa-apa tentang jumlah kartu pembayaran Anda dan bagaimana pembayaran berjalan di dalam platform. Juga, sedikit lebih detail saya akan mengungkapkan topik tentang bagaimana kami menyediakan ketersediaan tinggi dan penskalaan untuk menangani beban tinggi.
Tinjauan umum logika dan pendekatan umum
Secara umum, skema elemen dasar dari bagian pemrosesan yang bertanggung jawab untuk pembayaran terlihat seperti ini.
Secara logis di dalam diri kita, kita membagi area tanggung jawab menjadi 3 domain:
- zona eksternal, entitas yang ada di Internet, seperti aplikasi JS dari formulir pembayaran kami (Anda memasukkan detail kartu Anda di sana), backend dari klien merchant kami, serta memproses gateway bank mitra kami dan penyedia metode pembayaran lainnya;
- zona internal yang sangat mudah diakses, layanan microser tinggal di sana, yang menyediakan pekerjaan gateway pembayaran secara langsung dan mengelola pendebetan uang, memperhitungkannya dalam sistem kami dan layanan online lainnya, yang dicirikan oleh persyaratan "harus selalu tersedia, meskipun ada kegagalan di DC kami";
- ada area layanan terpisah yang bekerja secara langsung dengan data lengkap pemegang kartu, layanan ini memiliki persyaratan terpisah yang diajukan oleh Kementerian Kereta Api dan tunduk pada sertifikasi wajib di bawah standar PCI-DSS. Kami akan menjelaskan secara lebih rinci mengapa pemisahan seperti di bawah ini;
- zona dalam, di mana ada persyaratan yang lebih rendah untuk ketersediaan layanan yang diberikan atau waktu tanggapan mereka, dalam pengertian klasik - ini adalah kantor pusat. Meskipun, tentu saja, di sini kami juga mencoba untuk memastikan prinsip "selalu tersedia", kami hanya menghabiskan sedikit upaya untuk ini;
Di dalam setiap zona ada layanan-layanan microser yang melakukan bagian-bagian mereka dari pemrosesan logika bisnis. Mereka menerima panggilan RPC pada input, dan pada output, mereka menghasilkan data yang diproses menggunakan algoritma tertanam, yang juga dieksekusi sebagai panggilan layanan microser lainnya di sepanjang rantai.
Untuk memastikan skalabilitas, kami mencoba menyimpan status di tempat sesedikit mungkin. Layanan stateless dalam diagram tidak memiliki koneksi dengan toko persisten, masing-masing stateful, terhubung ke mereka. Secara umum, kami menggunakan beberapa layanan terbatas untuk penyimpanan keadaan persisten - untuk bagian utama pemrosesan, ini adalah cluster KV Riak, untuk layanan terkait - PostgreSQL, untuk pemrosesan antrian asinkron, kami menggunakan Kafka.
Untuk memastikan ketersediaan tinggi, kami menyebarkan layanan dalam beberapa kasus, biasanya dari 3 hingga 5.
Sangat mudah untuk skala layanan Stateless, kami hanya meningkatkan jumlah instance yang kami butuhkan pada mesin virtual yang berbeda, mereka terdaftar di Konsul, mereka tersedia untuk diselesaikan melalui DNS konsol dan mulai menerima panggilan dari layanan lain, memproses data yang diterima dan mengirimkannya lebih lanjut.
Layanan stateful, atau lebih tepatnya itu layanan utama kami dan ditampilkan dalam diagram sebagai Machinegun, mengimplementasikan antarmuka yang sangat mudah diakses (arsitektur terdistribusi didasarkan pada Distribusi Erlang), dan sinkronisasi melalui Konsul KV digunakan untuk memastikan antrian dan penguncian terdistribusi. Ini adalah deskripsi singkat dan terperinci yang akan berada di pos terpisah.
Di luar kotak, Riak menyediakan penyimpanan masterless persisten yang sangat mudah diakses, kami tidak mempersiapkannya dengan cara apa pun, konfigurasi hampir default. Dengan profil memuat saat ini, kami memiliki 5 node di cluster yang digunakan pada host yang terpisah. Catatan penting - kami praktis tidak menggunakan indeks dan sampel data besar, kami bekerja dengan kunci tertentu.
Di mana terlalu mahal untuk mengimplementasikan skema KV, kami menggunakan database PostgeSQL dengan replikasi, atau bahkan solusi single-mode, karena kami selalu dapat mengunggah peristiwa yang diperlukan jika terjadi kegagalan dari bagian online melalui Machinegun.
Pemisahan warna microservices dalam diagram menunjukkan bahasa tempat mereka ditulis - hijau muda - ini adalah aplikasi Java, biru muda - Erlang.
Semua layanan bekerja dalam wadah Docker, yang merupakan artefak buatan CI dan terletak di Docker Registry setempat. Menyebarkan layanan pada produksi SaltStack, konfigurasi yang ada di dalam repositori Github pribadi.
Para pengembang secara mandiri membuat permintaan untuk perubahan pada repositori ini, di mana mereka menggambarkan persyaratan untuk layanan - menunjukkan versi dan parameter yang diinginkan, seperti ukuran memori yang dialokasikan untuk wadah, ditransfer ke variabel lingkungan dan hal-hal lain. Selanjutnya, setelah konfirmasi manual tentang permintaan perubahan oleh karyawan yang berwenang (kami memilikinya DevOps, dukungan dan keamanan informasi), CD secara otomatis meluncurkan mesin kontainer dengan versi baru ke host di lingkungan produk.
Juga, setiap layanan menulis log dalam format yang dapat dimengerti oleh Elasticsearch. File log diambil oleh Filebeat, yang menulisnya ke cluster Elasticsearch. Jadi, terlepas dari kenyataan bahwa pengembang tidak memiliki akses ke lingkungan produk, mereka selalu memiliki kesempatan untuk melakukan debug dan melihat apa yang terjadi pada layanan mereka.
Interaksi dengan dunia luar
Setiap perubahan dalam kondisi platform bersama kami terjadi secara eksklusif melalui panggilan ke metode terkait API publik. Kami tidak menggunakan aplikasi web klasik dan pembuatan konten sisi-server, pada kenyataannya, semua yang Anda lihat sebagai UI adalah tampilan JS atas API publik kami. Pada prinsipnya, setiap tindakan dalam platform dapat dilakukan dengan rantai panggilan curl dari konsol, yang kami gunakan. Secara khusus, untuk menulis tes integrasi (kami telah menulisnya di JS sebagai perpustakaan), yang dalam CI, selama setiap pertemuan, periksa semua metode publik.
Juga, pendekatan seperti itu menyelesaikan semua masalah integrasi eksternal dengan platform kami, memungkinkan Anda untuk mendapatkan protokol tunggal untuk pengguna akhir dalam bentuk bentuk yang indah untuk memasukkan data pembayaran, dan host-ke-host untuk integrasi langsung dengan pemrosesan pihak ketiga menggunakan interaksi interserver secara eksklusif.
Selain cakupan penuh tes integrasi, kami menggunakan pendekatan pementasan pembaruan, dalam arsitektur terdistribusi, cukup mudah untuk melakukan ini, misalnya, meluncurkan hanya satu layanan dari setiap grup dalam satu pass, diikuti dengan jeda dan analisis log dan grafik.
Hal ini memungkinkan kami untuk mengerahkan hampir sepanjang waktu, termasuk malam Jumat, meluncurkan sesuatu yang tidak beroperasi tanpa rasa takut, atau dengan cepat mundur, membuat komitmen pengembalian sederhana dengan perubahan, sampai tidak ada yang memperhatikan.
Sebelum ada panggilan ke metode publik, kami perlu mengesahkan dan mengautentikasi klien. Agar klien muncul di platform, Anda memerlukan layanan yang akan menangani semua interaksi dengan pengguna akhir, menyediakan antarmuka untuk mendaftar, memasukkan dan mengatur ulang kata sandi, kontrol keamanan, dan binding lainnya.
Di sini, kami tidak menciptakan sepeda, tetapi hanya mengintegrasikan solusi open-source dari Redhat - Keycloak . Sebelum memulai interaksi dengan kami, Anda harus mendaftar di platform, yang, pada kenyataannya, terjadi melalui Keycloak.
Setelah otentikasi berhasil dalam layanan, klien menerima JWT. Kami akan menggunakannya nanti untuk otorisasi - di sisi Keycloak, Anda dapat menentukan bidang yang berubah-ubah yang menggambarkan peran yang akan disematkan sebagai struktur json sederhana di JWT dan ditandatangani dengan kunci pribadi layanan.
Salah satu fitur JWT adalah bahwa struktur ini ditandatangani oleh kunci pribadi server, sehingga, untuk mengesahkan daftar peran dan objek lainnya, kita tidak perlu mengakses layanan otorisasi, prosesnya sepenuhnya dipisahkan. Layanan CAPI saat startup membaca kunci publik Keycloak dan menggunakannya untuk mengesahkan panggilan ke metode API publik.
Ketika kami menemukan skema pencabutan kunci, cerita itu terpisah dan layak untuk posnya sendiri.
Jadi, kami telah menerima JWT, kami dapat menggunakannya untuk otentikasi. Di sini kelompok microservices Common API berperan, pada diagram yang ditunjukkan sebagai CAPI dan CAPI-DSS, yang menerapkan fungsi-fungsi berikut:
- otorisasi pesan yang diterima. Setiap panggilan API publik didahului oleh header HTTP Authorisasi: Bearer {JWT}. Layanan dari grup API Umum menggunakannya untuk memverifikasi data yang ditandatangani dengan kunci publik yang ada dari layanan otorisasi;
- validasi data yang diterima. Karena skema dijelaskan sebagai spesifikasi OpenAPI, juga dikenal sebagai Swagger, validasi data bisa sangat mudah dan dengan sedikit kemungkinan menerima perintah kontrol dalam aliran data. Ini memiliki efek positif pada keamanan layanan secara keseluruhan;
- terjemahan format data dari REST JSON publik ke internal binary Thrift;
- membingkai pengikatan transportasi dengan data seperti trace_id unik dan meneruskan peristiwa lebih jauh di dalam platform ke layanan yang mengelola logika bisnis dan tahu apa, misalnya, pembayaran.
Kami memiliki banyak layanan seperti itu, mereka cukup sederhana dan ek, tidak menyimpan status apa pun, jadi untuk penskalaan kinerja linier, kami cukup menerapkannya pada kapasitas bebas dalam jumlah yang kami butuhkan.
PCI-DSS dan data kartu terbuka
Seperti yang dapat Anda lihat dalam diagram, kami memiliki dua grup layanan tersebut - yang utama, Common API, bertanggung jawab untuk memproses semua aliran data yang tidak memiliki data pemegang kartu terbuka, dan yang kedua, PCI-DSS Common API, yang bekerja langsung dengan kartu-kartu ini. Di dalam, mereka persis sama, tetapi kami secara fisik memisahkan mereka dan mengaturnya pada potongan besi yang berbeda.
Hal ini dilakukan untuk meminimalkan jumlah lokasi untuk menyimpan dan memproses data kartu, untuk mengurangi risiko kebocoran data ini dan area sertifikasi PCI-DSS. Dan ini, percayalah, adalah proses yang agak memakan waktu dan mahal - sebagai perusahaan pembayaran, kita harus menjalani sertifikasi berbayar untuk kepatuhan dengan standar MPS setiap tahun, dan semakin sedikit server dan layanan yang terlibat di dalamnya, semakin cepat dan mudah untuk menyelesaikan proses ini. Nah, pada keamanan ini tercermin dalam cara yang paling positif.
Penagihan dan Tokenisasi
Jadi, kami ingin memulai pembayaran dan menghapus uang dari kartu pembayar.
Bayangkan bahwa permintaan untuk ini datang dalam bentuk rangkaian panggilan ke metode API publik kami, yang dimulai oleh Anda sebagai pembayar setelah Anda pergi ke toko online, mengumpulkan sekeranjang barang, mengklik "Beli", memasukkan detail kartu Anda ke pembayaran kami formulir dan mengklik tombol "Bayar".
Kami menyediakan berbagai proses bisnis untuk menghapus uang, tetapi yang paling menarik adalah proses menggunakan hutang dagang. Di platform kami, Anda dapat membuat faktur pembayaran, atau faktur yang akan menjadi wadah pembayaran.
Dalam satu faktur, Anda dapat melakukan pembayaran satu per satu, yaitu melakukan pembayaran hingga pembayaran berikutnya berhasil. Misalnya, Anda dapat mencoba membayar faktur dari berbagai kartu, dompet, dan metode pembayaran lainnya. Jika tidak ada uang di salah satu kartu, Anda dapat mencoba yang lain dan seterusnya.
Ini memiliki efek positif pada konversi dan pengalaman pengguna.
Mesin Faktur
Di dalam platform, rantai ini berubah menjadi interaksi di sepanjang rute berikut:
- Sebelum mengirimkan konten ke browser Anda, merchant-klien kami terintegrasi dengan platform kami, terdaftar pada kami dan menerima JWT untuk otorisasi;
- dari backendnya , pedagang memanggil metode createInvoice () , yaitu, ia membuat faktur untuk pembayaran di platform kami. Bahkan, pedagang backend mengirim permintaan HTTP POST dari konten berikut ke titik akhir kami:
curl -X POST \ https://api.rbk.money/v2/processing/invoices \ -H 'Authorization: Bearer {JWT}' \ -H 'Content-Type: application/json; charset=utf-8' \ -H 'X-Request-ID: 1554417367' \ -H 'cache-control: no-cache' \ -d '{ "shopID": "TEST", "dueDate": "2019-03-28T17:41:32.569Z", "amount": 6000, "currency": "RUB", "product": "Order num 12345", "description": "Delicious meals", "cart": [ { "price": 5000, "product": "Sandwich", "quantity": 1, "taxMode": { "rate": "10%", "type": "InvoiceLineTaxVAT" } }, { "price": 1000, "product": "Cola", "quantity": 1, "taxMode": { "rate": "18%", "type": "InvoiceLineTaxVAT" } } ], "metadata": { "order_id": "Internal order num 13123298761" } }'
Permintaan itu seimbang pada salah satu aplikasi erlang dari grup Common API, yang memeriksa validitasnya, pergi ke layanan Bender, di mana ia menerima kunci idempotensi, mentransfernya ke tift dan mengirim permintaan ke grup layanan Hellgate. Contoh Hellgate melakukan pemeriksaan bisnis, misalnya, memastikan bahwa pemilik JWT ini tidak diblokir pada prinsipnya, dapat membuat faktur dan umumnya berinteraksi dengan platform dan mulai membuat faktur.
Kita dapat mengatakan bahwa Hellgate adalah inti dari pemrosesan kami, karena beroperasi dengan entitas bisnis, tahu cara meluncurkan pembayaran, siapa yang perlu ditendang sehingga pembayaran ini berubah menjadi biaya uang nyata, cara menghitung rute pembayaran ini, siapa yang harus disuruh menghapusnya tercermin dalam neraca, menghitung komisi dan ikatan lainnya.
Biasanya, ini juga tidak menyimpan status apa pun dan juga mudah diskalakan. Tetapi kami tidak ingin kehilangan faktur, atau mendapatkan tagihan ganda uang dari kartu jika terjadi perpecahan jaringan atau kegagalan Hellgate dengan alasan apa pun. Penting untuk terus menyimpan data ini.
Di sinilah microservice ketiga, yaitu Machinegun. Hellgate mengirimkan Machinegun panggilan untuk "membuat automaton" dengan payload dalam bentuk parameter kueri. Machinegun mengatur permintaan bersamaan dan, menggunakan Hellgate, membuat acara pertama dari parameter - InvoiceCreated. Yang kemudian dengan sendirinya dan menulis dalam Riak dan antrian. Setelah itu, respons yang berhasil dikembalikan dalam urutan terbalik ke permintaan awal dalam rantai.
Singkatnya, Machinegun adalah DBMS dengan timer atas DBMS lainnya, dalam versi platform saat ini - lebih dari Riak. Ini menyediakan antarmuka yang memungkinkan Anda untuk mengontrol mesin independen, dan memberikan jaminan idempotensi dan urutan rekaman. Ini adalah MG yang tidak akan mengizinkan acara untuk ditulis keluar dari antrian secara otomatis jika beberapa HG tiba-tiba datang kepadanya dengan permintaan seperti itu.
Otomat adalah entitas unik dalam platform, yang terdiri dari pengidentifikasi, kumpulan data dalam bentuk daftar acara, dan timer. Keadaan akhir otomat dihitung dari pemrosesan semua peristiwa yang memulai transisi ke keadaan yang sesuai. Kami menggunakan pendekatan ini untuk bekerja dengan entitas bisnis, menggambarkannya sebagai mesin negara yang terbatas. Bahkan, semua faktur yang dibuat oleh pedagang kami, serta pembayaran di dalamnya, adalah mesin negara yang terbatas dengan logika transisi mereka sendiri antar negara.
Antarmuka untuk bekerja dengan penghitung waktu di Machinegun memungkinkan Anda menerima permintaan formulir "Saya ingin melanjutkan memproses mesin ini dalam 15 tahun" dari layanan lain bersama dengan acara untuk merekam. Tugas yang tertunda tersebut diimplementasikan pada timer yang terpasang di dalam. Dalam praktiknya, mereka digunakan sangat sering - panggilan berkala ke bank, tindakan otomatis dengan pembayaran karena tidak aktif lama, dll.
Ngomong-ngomong, kode sumber Machinegun terbuka di bawah lisensi Apache 2.0 di repositori publik kami. Kami berharap layanan ini dapat bermanfaat bagi masyarakat.
Penjelasan terperinci tentang pekerjaan Machinegun dan, secara umum, bagaimana kami menyiapkan sistem distribusi, ditarik ke pos besar yang terpisah, jadi saya tidak akan berhenti di sini lebih terinci.
Nuansa otorisasi klien eksternal
Setelah berhasil menyimpan, Hellgate mengembalikan data ke CAPI, itu mengubah struktur trift biner menjadi JSON yang dirancang dengan indah, siap dikirim ke backend pedagang:
{ "invoice": { "amount": 6000, "cart": [ { "cost": 5000, "price": 5000, "product": "Sandwich", "quantity": 1, "taxMode": { "rate": "10%", "type": "InvoiceLineTaxVAT" } }, { "cost": 1000, "price": 1000, "product": "Cola", "quantity": 1, "taxMode": { "rate": "18%", "type": "InvoiceLineTaxVAT" } } ], "createdAt": "2019-04-04T23:00:31.565518Z", "currency": "RUB", "description": "Delicious meals", "dueDate": "2019-04-05T00:00:30.889000Z", "id": "18xtygvzFaa", "metadata": { "order_id": "Internal order num 13123298761" }, "product": "Order num 12345", "shopID": "TEST", "status": "unpaid" }, "invoiceAccessToken": { "payload": "{JWT}" } }
Tampaknya Anda dapat mengirim konten ke pembayar di browser dan memulai proses pembayaran, tetapi di sini kami berpikir bahwa tidak semua pedagang siap untuk secara mandiri menerapkan otorisasi di sisi klien, jadi kami menerapkannya sendiri. Pendekatannya adalah bahwa CAPI menghasilkan JWT lain yang memungkinkan Anda untuk memulai proses tokenisasi kartu dan mengelola faktur tertentu dan menambahkannya ke struktur faktur yang dikembalikan.
Contoh peran yang dijelaskan di dalam JWT yang serupa:
"resource_access": { "common-api": { "roles": [ "invoices.18xtygvzFaa.payments:read", "invoices.18xtygvzFaa.payments:write", "invoices.18xtygvzFaa:read", "payment_resources:write" ] } }
JWT ini memiliki sejumlah upaya untuk digunakan dan masa pakai yang kami konfigurasi, yang memungkinkan Anda untuk mempublikasikannya di peramban pembayar. Bahkan jika itu dicegat, maksimum yang bisa dilakukan penyerang adalah membayar tagihan orang lain atau membaca datanya. Selain itu, karena mesin pembayaran tidak beroperasi dengan data kartu terbuka, maksimum yang dapat dilihat penyerang adalah nomor kartu bertopeng dari tipe 4242 42** **** 4242 , jumlah pembayaran dan, opsional, sekeranjang barang.
Faktur dan kunci akses yang dibuat untuk memungkinkan Anda memulai proses bisnis pembayaran. Kami memberikan ID faktur dan JWT-nya ke browser pembayar dan mentransfer kontrol ke aplikasi JS kami.
Aplikasi JS Checkout kami mengimplementasikan antarmuka untuk berinteraksi dengan Anda sebagai pembayar - menggambar formulir entri data pembayaran, memulai pembayaran, menerima status akhir, menunjukkan Titik lucu atau sedih.
Tokenisasi dan data kartu
Tetapi Checkout tidak berfungsi dengan data kartu. Seperti yang disebutkan di atas, kami ingin menyimpan data sensitif dalam bentuk data pemegang kartu di tempat sesedikit mungkin. Untuk melakukan ini, kami menerapkan tokenization.
Di sinilah perpustakaan Tokenizer JS berperan. Ketika Anda memasukkan kartu Anda di bidang input dan klik "Bayar", kartu itu memotong data ini dan mengirimkannya secara asinkron kepada kami untuk diproses dengan memanggil metode createPaymentResource () .
Permintaan ini seimbang untuk aplikasi CAPI-DSS individual, yang juga mengesahkan permintaan, hanya dengan memeriksa faktur JWT, memvalidasi data dan mengirimkannya dengan tront ke layanan penyimpanan data kartu. Dalam diagram, ini ditunjukkan sebagai CDS - Card Data Storage.
Tujuan utama dari layanan ini:
- menerima data sensitif pada input, dalam kasus kami - data kartu Anda;
- mengenkripsi data ini dengan kunci enkripsi data;
- menghasilkan beberapa nilai acak yang digunakan sebagai kunci;
- menyimpan data terenkripsi pada kunci ini di cluster Riak Anda;
- kembalikan kunci dalam bentuk token data pembayaran ke layanan CAPI-DSS.
Sepanjang jalan, layanan memecahkan banyak tugas penting, seperti menghasilkan kunci untuk mengenkripsi kunci, memasukkan kunci ini dengan aman, mengenkripsi ulang data, mengendalikan penghapusan CVV setelah pembayaran, dan sebagainya, tetapi ini berada di luar cakupan posting ini.
Itu bukan tanpa perlindungan dari kemungkinan menembak diri sendiri di kaki. Ada kemungkinan non-nol bahwa JWT pribadi, yang dirancang untuk mengesahkan permintaan dari backend, akan dipublikasikan di web ke browser klien. Untuk mencegah hal ini terjadi, kami membuat perlindungan - Anda dapat memanggil metode createPaymentResource () hanya dengan kunci otorisasi faktur. Ketika mencoba menggunakan platform JWT pribadi akan mengembalikan kesalahan HTTP / 401.
Setelah menyelesaikan permintaan tokenization, Tokenizer mengembalikan token yang diterima ke Checkout dan menyelesaikan pekerjaannya.
Proses bisnis mesin pembayaran
Checkout memulai proses pembayaran, yaitu, ia memanggil metode createPayment () , meneruskan token kartu yang diterima sebelumnya sebagai argumen dan memulai proses peristiwa polling, bahkan, memanggil metode API getInvoiceEvents () satu detik.
Permintaan ini melalui CAPI masuk ke Hellgate, yang mulai menerapkan proses bisnis pembayaran, tanpa menggunakan data kartu:
- pertama-tama, Hellgate pergi ke layanan manajemen konfigurasi - Dominan dan menerima revisi terbaru dari konfigurasi domain. Ini berisi semua aturan yang dengannya pembayaran ini akan dilakukan, bank mana yang akan dituju untuk otorisasi, berapa biaya transaksi yang akan dicatat, dll.
- dari layanan manajemen anggota, sekarang ini merupakan bagian dari HG, mempelajari data tentang nomor internal dari akun pedagang yang mendukung pembayaran dilakukan, menerapkan jumlah biaya, menyiapkan rencana pengiriman dan memasukkannya ke dalam layanan Shumway. Layanan ini bertanggung jawab untuk mengelola informasi tentang pergerakan uang pada akun peserta dalam suatu transaksi saat melakukan pembayaran. Paket posting berisi instruksi "untuk membekukan kemungkinan pergerakan dana pada akun peserta dalam transaksi yang ditentukan dalam paket";
- memperkaya data pembayaran dengan merujuk ke layanan tambahan, misalnya, di Binbase untuk mengetahui negara bank penerbit yang mengeluarkan kartu dan jenisnya, misalnya, "emas, kredit";
- panggilan layanan inspektur, sebagai suatu peraturan, ini adalah Antifraud untuk menerima penilaian pembayaran dan memutuskan pilihan terminal yang mencakup tingkat risiko yang dikeluarkan oleh penilaian. Sebagai contoh, terminal tanpa 3D-Secure dapat digunakan untuk pembayaran berisiko rendah, dan pembayaran yang telah menerima tingkat risiko fatal akan mengakhiri masa pakainya;
- memanggil layanan pendeteksian kesalahan, Faultdetector, dan berdasarkan data yang diterima darinya memilih rute pembayaran - adaptor protokol bank, yang saat ini memiliki kesalahan paling sedikit dan probabilitas tertinggi dari pembayaran yang berhasil;
- mengirimkan permintaan ke adaptor protokol bank yang dipilih, biarkan itu menjadi YellowBank Adapter, "otorisasi jumlah yang ditentukan dari token ini" dalam kasus ini.
Adaptor protokol untuk token yang diterima pergi ke CDS, menerima data kartu yang didekripsi, mentransfernya ke protokol khusus bank, dan secara umum, menerima otorisasi - konfirmasi dari bank yang mengakuisisi bahwa jumlah yang ditunjukkan telah dibekukan di rekening pembayar.
Pada saat inilah Anda menerima SMS dengan pesan tentang pendebitan dana dari kartu Anda dari bank Anda, meskipun sebenarnya dana itu sebenarnya hanya dibekukan di akun Anda.
Adaptor memberitahukan HG dari otorisasi yang berhasil, kode CVV Anda dihapus dari layanan CDS, dan ini adalah akhir dari tahap interaksi. Manajemen kembali ke HG.
Bergantung pada proses pembayaran yang ditentukan oleh panggilan createPayment () oleh pedagang dari proses bisnis pembayaran, HG mengharapkan panggilan dari API eksternal ke metode pengambilan otorisasi, yaitu, konfirmasi penarikan uang dari kartu Anda, atau langsung melakukannya sendiri, jika pedagang telah memilih skema pembayaran satu tahap.
Sebagai aturan, sebagian besar pedagang menggunakan pembayaran satu tahap, namun ada kategori bisnis yang, pada saat otorisasi, belum tahu jumlah total yang didebit. Ini sering terjadi di industri pariwisata ketika Anda memesan tur untuk satu jumlah, dan setelah mengonfirmasi pemesanan, jumlah tersebut ditentukan dan mungkin berbeda dari yang disetujui di awal.
Terlepas dari kenyataan bahwa jumlah konfirmasi dapat secara eksklusif sama atau kurang dari jumlah otorisasi, ada jebakan di sini. Bayangkan bahwa Anda membayar produk atau layanan dari kartu dalam mata uang yang berbeda dari mata uang rekening bank Anda di mana kartu itu ditautkan.
Pada saat otorisasi, jumlah diblokir pada akun Anda berdasarkan nilai tukar pada hari otorisasi. Karena pembayaran mungkin dalam status "resmi" (terlepas dari kenyataan bahwa Kementerian Perkeretaapian memiliki rekomendasi untuk jangka waktu maksimum 3 hari) beberapa hari, penangkapan otorisasi akan dilakukan pada tingkat hari di mana ia dibuat.
Dengan demikian, Anda menanggung risiko mata uang, yang dapat menguntungkan Anda dan melawan Anda, terutama dalam situasi volatilitas tinggi di pasar mata uang.
Untuk mendapatkan otorisasi, proses komunikasi yang sama dengan adaptor protokol terjadi seperti untuk menerimanya, dan jika berhasil, HG menerapkan rencana pengiriman akun di dalam Shumway, dan mentransfer pembayaran ke status "Dibayar". Pada saat inilah kami, sebagai sistem pembayaran, memiliki kewajiban finansial kepada para peserta dalam transaksi.
Perlu juga dicatat bahwa setiap perubahan dalam kondisi mesin faktur, yang meliputi proses pembayaran, dicatat oleh Hellgate di Machinegun, memastikan persistensi data dan memperkaya faktur dengan peristiwa baru.
Sebutkan sinkronisasi mesin pembayaran dan UI
Sementara proses latar belakang pembayaran berlangsung di dalam platform, Checkout menuangkan pemrosesan dengan meminta acara. Setelah menerima peristiwa tertentu, ia menggambarkan kondisi pembayaran saat ini dalam bentuk yang dapat dimengerti oleh seseorang - menggambar preloader, menampilkan layar "Pembayaran Anda berhasil diproses" atau "Pembayaran tidak dapat diselesaikan" atau mengalihkan browser ke halaman bank penerbit Anda untuk memasukkan kata sandi 3D-Secure;
Jika gagal, Checkout akan menawarkan Anda untuk memilih metode pembayaran lain atau coba lagi, sehingga memulai pembayaran baru sebagai bagian dari faktur.
Skema semacam itu dengan polling peristiwa memungkinkan untuk memulihkan keadaan bahkan setelah menutup tab browser - dalam kasus peluncuran berulang, Checkout akan menerima daftar peristiwa terkini dan menggambar skenario interaksi pengguna saat ini, misalnya, akan menawarkan untuk memasukkan kode 3D-Secure atau menunjukkan bahwa pembayaran telah berhasil diselesaikan.
Replikasi acara di Zona Offline
Bersamaan dengan antarmuka kontrol alat berat, Machinegun mengimplementasikan layanan yang bertanggung jawab untuk meluap-luap aliran acara ke layanan yang bertanggung jawab untuk tugas platform lain yang kurang online.
Sebagai broker antrian di final, kami memutuskan pada Kafka, meskipun kami sebelumnya menerapkan fungsi ini menggunakan Machinegun itu sendiri. Dalam kasus umum, layanan ini adalah pelestarian aliran acara yang dijamin, atau penerbitan daftar acara tertentu berdasarkan permintaan kepada konsumen lain.
Kami juga awalnya menerapkan skema deduplikasi acara, memberikan jaminan bahwa acara yang sama tidak akan direplikasi dua kali, namun, beban pada Riak, yang dihasilkan oleh yang serupa, memaksa kami untuk mengabaikannya - lagipula, pencarian indeks bukanlah yang terbaik Penyimpanan KV mampu. Sekarang, setiap konsumen layanan bertanggung jawab atas deduplikasi acara secara independen.
Secara umum, replikasi acara oleh Machinegun berakhir dengan konfirmasi penyimpanan data di Kafka, dan konsumen sudah terhubung ke topik Kafka dan mengunduh daftar acara yang menarik bagi mereka.
Templat Aplikasi Zona Offline Khas
Misalnya, layanan Dudoser bertanggung jawab untuk mengirimi Anda pemberitahuan email tentang pembayaran yang berhasil. Saat startup, ia memompa daftar peristiwa pembayaran yang berhasil, mengambil informasi tentang alamat dan jumlah dari sana, menyimpannya ke instance PostgreSQL lokal dan menggunakannya untuk pemrosesan logika bisnis lebih lanjut.
Semua layanan serupa lainnya beroperasi sesuai dengan logika yang sama, misalnya, layanan Magista, yang bertanggung jawab untuk menemukan faktur dan pembayaran di akun pribadi pedagang atau layanan Hooker, yang mengirimkan panggilan balik tidak sinkron ke backend ke pedagang yang karena satu atau lain alasan tidak dapat mengatur acara pemungutan suara dengan menghubungi langsung ke API pemrosesan.
Pendekatan ini memungkinkan kami melepaskan beban pada pemrosesan, mengalokasikan sumber daya maksimum dan menyediakan kecepatan tinggi dan ketersediaan pemrosesan pembayaran, memberikan konversi tinggi. Pertanyaan berat seperti "pelanggan bisnis ingin melihat statistik pembayaran selama setahun terakhir" diproses oleh layanan yang tidak memengaruhi beban saat ini dari bagian pemrosesan online, dan karenanya tidak memengaruhi Anda, sebagai pembayar dan pedagang, sebagai pelanggan kami.
Mungkin kita akan berhenti di sini agar tidak mengubah posting menjadi terlalu panjang. Dalam artikel mendatang saya pasti akan memberi tahu Anda tentang nuansa memastikan keaslian perubahan, jaminan dan ketertiban dalam sistem terdistribusi yang dimuat menggunakan Machinegun, Bender, CAPI, dan Hellgate sebagai contoh.
Nah, tentang Salt Stack waktu berikutnya ¯\_(ツ)_/¯