Pembayaran kad
Pembayaran kad: daripada terminal ke pemeroleh dan kembali ke lejar
Terminal EMV dan get laluan pembayaran disambungkan kepada pemeroleh melalui ISO 8583 atau API, dengan fail penyelesaian diselaraskan dalam ERP.
Pelan terperinci
Tatal ke sisi untuk melihat keseluruhan lukisan.
Pembayaran kad: dibenarkan di kaunter, diselesaikan kemudian, diselaraskan dalam ERP
Terminal atau kaunter pembayaran bertanya kepada get laluan, get laluan bertanya kepada pemeroleh, dan pemeroleh menghalakan kepada skema kad dan pengeluar. Fail penyelesaian tiba kemudian dan dipadankan dengan jualan serta fi dalam ERP. Tamat masa mencetuskan pembalikan supaya pelanggan tidak dicaj dua kali.
- Aliran utama
- Tak segerak
- Laluan pengecualian
Aliran dalam 8 langkah
Aliran, langkah demi langkah
- Dari Terminal EMV atau kaunter pembayaran dalam talian ke Get laluan pembayaran: Permintaan kebenaran, melalui EMV · REST/JSON (aliran utama).
- Dari Get laluan pembayaran ke Pemeroleh: Kebenaran, melalui ISO 8583 (aliran utama).
- Dari Pemeroleh ke Skema kad dan pengeluar: Dihalakan kepada pengeluar, melalui ISO 8583 (aliran utama).
- Dari Pemeroleh ke Get laluan pembayaran: Diluluskan atau ditolak, melalui ISO 8583 (tak segerak).
- Dari Pemeroleh ke Lapisan integrasi: Fail penyelesaian dan fi, melalui SFTP (tak segerak).
- Dari Lapisan integrasi ke ERP: Jualan, fi dan bayaran keluar diselesaikan, melalui REST/JSON (aliran utama).
- Dari Get laluan pembayaran ke Terminal EMV atau kaunter pembayaran dalam talian: Tiada respons dalam masa: pembalikan automatik, melalui ISO 8583 0400 (laluan pengecualian).
- Dari Lapisan integrasi ke Pasukan operasi pembayaran: Ketidaksepadanan penyelesaian atau caj balik (laluan pengecualian).
Gambaran keseluruhan
Ini ialah laluan sesuatu pembayaran kad, daripada terminal atau kaunter bayaran dalam talian ke pemeroleh, skim kad dan pengeluar kad, lalu kembali. Pelanggan menunggu jawapannya di kaunter. Wang, selepas ditolak fi, tiba kemudian dalam fail penyelesaian yang perlu dipadankan dengan jualan dalam ERP anda.
Reka bentuk rujukan menghantar kebenaran melalui get laluan pembayaran yang menokenkan kad dan mengarahkan permintaan kepada pemeroleh, melalui ISO 8583 atau API pemeroleh. Fail penyelesaian dan fi dikumpulkan oleh lapisan integrasi, dipadankan dengan jualan asal dan diposkan ke ERP sebagai jualan, fi dan pembayaran keluar.
Reka bentuk itu juga meliputi apa yang tidak kena. Permintaan yang tidak menerima jawapan tepat pada masanya dibalikkan, supaya pelanggan tidak dicaj dua kali. Penyelesaian yang tidak sepadan, atau caj balik, dihantar kepada pasukan operasi pembayaran anda bersama jualan asal dilampirkan.
Cara aliran berfungsi
Bermula di terminal atau kaunter bayaran
Terminal EMV membaca kad cip atau tanpa sentuh, atau kaunter bayaran dalam talian mengumpul kad melalui halaman pembayaran dihoskan, lalu menghantar permintaan kebenaran kepada get laluan.
Mendapatkan kebenaran melalui get laluan
Gerbang menggantikan nombor kad dengan token dan menghantar kebenaran kepada pemeroleh, melalui ISO 8583 atau API pemeroleh.
Mengarahkan kepada pengeluar kad
Pemeroleh mengarahkan permintaan melalui skim kad kepada pengeluar kad, yang meluluskan atau menolaknya.
Mengembalikan jawapan
Kelulusan atau penolakan kembali melalui laluan yang sama ke terminal atau kaunter bayaran, bersama kod responsnya.
Menerima penyelesaian
Pemeroleh kemudian menghantar fail penyelesaian dan fi, yang dikumpul dan disahkan oleh lapisan integrasi.
Memadankan dan memposkan
Lapisan itu memadankan transaksi yang diselesaikan dengan jualan asal dan memposkan jualan, fi dan pembayaran keluar ke ERP.
Apabila sesuatu gagal
Tiada jawapan tepat pada masanya
Jika get laluan tidak menerima respons dalam had masa pemeroleh, ia menghantar pembalikan, mesej ISO 8583 0400 atau yang setara dalam API pemeroleh, supaya pelanggan tidak pernah dicaj bagi jualan yang tidak selesai.
Pembayaran ditolak
Kod respons sampai ke kaunter atau pembayaran dalam talian bersama mesej yang jelas. Kadar penolakan dipantau, supaya lonjakan yang menunjukkan kerosakan teknikal membangkitkan amaran.
Penyelesaian tidak sepadan
Jumlah yang diselesaikan berbeza daripada jualan, atau jualan tanpa penyelesaian, masuk ke senarai semakan bagi pasukan operasi pembayaran anda, dengan kedua-dua rekod dipaparkan sebelah menyebelah.
Pemegang kad mempertikaikan pembayaran
Laporan pertikaian pemeroleh diimport dan dikaitkan dengan jualan dan penyelesaian asal, supaya pasukan anda dapat menjawab dengan bukti di satu tempat.
Piawaian dan sistem
- Piawaian dan saluran perbankan
- SFTP (H2H)
- Pembayaran
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integrasi
- REST
- Webhooks
Soalan dan jawapan
Apakah perbezaan antara get laluan dan pemeroleh?
Pemeroleh ialah bank atau institusi berlesen yang memproses pembayaran kad untuk anda dan membayar keluar wangnya. Gerbang ialah perkhidmatan teknikal di hadapannya yang menerima permintaan daripada terminal dan kaunter bayaran, menokenkan kad dan mengarahkannya. Sesetengah penyedia merupakan kedua-duanya. Reka bentuk ini berfungsi dalam kedua-dua keadaan dan mengekalkan kedua-dua peranan dengan jelas.
Adakah ini menjauhkan data kad daripada sistem kami?
Itulah tujuan reka bentuk ini. Nombor kad ditangkap oleh terminal bersijil atau halaman pembayaran dihoskan dan digantikan dengan token di get laluan, jadi POS, ERP dan stor data anda hanya pernah melihat token. Ini mengurangkan bahagian persekitaran anda yang tertakluk kepada PCI DSS. Penilai anda mengesahkan skop akhir.
Adakah ISO 8583 sama bagi setiap pemeroleh?
Tidak. ISO 8583 menetapkan struktur, dan setiap pemeroleh atau rangkaian menerbitkan spesifikasi medan, jenis mesej dan kodnya sendiri. Itulah sebabnya kami membina daripada spesifikasi pemeroleh dan menjalankan ujian pensijilannya. API get laluan di hadapan pemeroleh menyembunyikan perbezaan ini, yang selalunya lebih mudah bagi peruncit.
Mengapa penyelesaian tiba lebih lambat daripada jualan?
Kebenaran hanya menempah dana. Pemeroleh menyelesaikan secara kelompok, selepas menolak finya dan apa-apa caj skim, dan membayar keluar mengikut jadualnya sendiri. Itulah sebabnya reka bentuk ini menganggap kebenaran dan penyelesaian sebagai peristiwa berasingan dan memadankannya, supaya kewangan dapat melihat apa yang dijual, apa yang diselesaikan dan apa yang masih akan tiba.
Adakah anda menyokong EMV 3-D Secure bagi pembayaran dalam talian?
Ya. Bagi pembayaran kad dalam talian, kami menyepadukan EMV 3-D Secure melalui get laluan, supaya pengeluar kad dapat mengesahkan pemegang kad di tempat peraturan atau risiko memerlukannya. Kami mengendalikan aliran cabaran dan tanpa geseran dalam kaunter bayaran serta menguji kedua-duanya dengan kad ujian penyedia.
Bolehkah kami menggunakan lebih daripada satu penyedia pembayaran?
Boleh. Lapisan integrasi mengekalkan satu model dalaman bagi sesuatu pembayaran dan memetakannya kepada setiap penyedia, jadi anda boleh mengarahkan mengikut saluran, negara atau jenis kad, atau memindahkan jumlah antara penyedia. Setiap penyedia masih memerlukan integrasi dan pensijilannya sendiri, yang kami rancang penyedia demi penyedia.
Mulakan dengan perbualan, bukan kontrak.
Beritahu kami apa yang perlu anda bina, sambungkan atau lindungi. Seorang arkitek akan membincangkannya bersama anda, kemudian mengesyorkan dari mana hendak bermula.
Apa yang berlaku seterusnya
Mempersetujui masa
Pasukan kami menghantar e-mel kepada anda untuk mempersetujui masa sesi.
Sesi praperundingan
Satu sesi praperundingan dalam talian percuma selama 30 minit: kami meneliti matlamat, sistem dan kekangan anda.
Semakan kesediaan
Dalam satu semakan kesediaan percuma selama 48 jam, seorang Arkitek Utama menyemak projek anda menurut Takrif Kesediaan 6 perkara dan mengesyorkan landasan yang sesuai.
Memilih landasan
Projek yang bersedia dari segi skop menerima cadangan mengikat dalam 3 hingga 5 hari perniagaan. Projek pada peringkat konsep bermula di Blueprint Studio. Sistem yang sedang berjalan tetapi gagal, tidak didokumenkan atau memerlukan integrasi bermula dengan diagnostik selama 1 hingga 2 minggu. Blueprint Studio dan diagnostik masing-masing mempunyai fi tetap, disebut dalam cadangan.