Pembayaran kartu
Pembayaran kartu: dari terminal ke acquirer dan kembali ke buku besar
Terminal EMV dan gateway pembayaran yang terhubung ke acquirer melalui ISO 8583 atau API, dengan berkas penyelesaian yang direkonsiliasi di ERP.
Blueprint
Gulir ke samping untuk melihat seluruh gambar.
Pembayaran kartu: diotorisasi di kasir, diselesaikan kemudian, direkonsiliasi di ERP
Terminal atau pembayaran online mengirim permintaan ke gateway pembayaran, gateway pembayaran mengirim permintaan ke acquirer, dan acquirer meneruskan ke skema kartu dan penerbit. Berkas penyelesaian tiba kemudian dan dicocokkan dengan penjualan dan biaya di ERP. Waktu tunggu habis memicu pembalikan sehingga nasabah tidak pernah ditagih dua kali.
- Alur utama
- Asinkron
- Jalur pengecualian
Alur dalam 8 langkah
Alur, langkah demi langkah
- Dari Terminal EMV atau pembayaran online ke Gateway pembayaran: Permintaan otorisasi, melalui EMV · REST/JSON (alur utama).
- Dari Gateway pembayaran ke Acquirer: Otorisasi, melalui ISO 8583 (alur utama).
- Dari Acquirer ke Skema kartu dan penerbit: Diteruskan ke penerbit, melalui ISO 8583 (alur utama).
- Dari Acquirer ke Gateway pembayaran: Disetujui atau ditolak, melalui ISO 8583 (asinkron).
- Dari Acquirer ke Lapisan integrasi: Berkas penyelesaian dan biaya, melalui SFTP (asinkron).
- Dari Lapisan integrasi ke ERP: Penjualan, biaya, dan pembayaran keluar yang telah diselesaikan, melalui REST/JSON (alur utama).
- Dari Gateway pembayaran ke Terminal EMV atau pembayaran online: Tidak ada respons pada waktunya: pembalikan otomatis, melalui ISO 8583 0400 (jalur pengecualian).
- Dari Lapisan integrasi ke Tim operasional pembayaran: Selisih rekonsiliasi atau chargeback (jalur pengecualian).
Ikhtisar
Inilah alur pembayaran kartu, dari terminal atau checkout online ke acquirer, skema kartu, dan penerbit, lalu kembali. Pelanggan menunggu jawabannya di kasir. Dana, setelah dikurangi biaya, tiba kemudian dalam berkas penyelesaian yang harus dicocokkan dengan penjualan di ERP Anda.
Rancangan acuan mengirim otorisasi melalui gateway pembayaran yang melakukan tokenisasi kartu dan meneruskan permintaan ke acquirer, melalui ISO 8583 atau API acquirer. Berkas penyelesaian dan biaya dikumpulkan oleh lapisan integrasi, dicocokkan dengan penjualan awal, dan dicatat ke ERP sebagai penjualan, biaya, dan pembayaran keluar.
Rancangan ini juga mencakup penanganan kegagalan. Permintaan yang tidak mendapat jawaban tepat waktu dibalikkan, sehingga pelanggan tidak ditagih dua kali. Penyelesaian yang tidak cocok, atau chargeback, diteruskan ke tim operasi pembayaran Anda bersama penjualan aslinya.
Cara alur bekerja
Mulai di terminal atau checkout
Terminal EMV membaca kartu chip atau kartu nirsentuh, atau checkout online mengambil data kartu melalui halaman pembayaran terkelola, lalu mengirim permintaan otorisasi ke gateway.
Otorisasi melalui gateway
Gateway menggantikan nomor kartu dengan token dan mengirim otorisasi ke acquirer, melalui ISO 8583 atau API acquirer.
Teruskan ke penerbit
Acquirer meneruskan permintaan melalui skema kartu ke penerbit, yang menyetujui atau menolaknya.
Kembalikan jawaban
Persetujuan atau penolakan kembali melalui jalur yang sama ke terminal atau checkout, dengan kode responsnya.
Terima penyelesaian
Acquirer kemudian mengirim berkas penyelesaian dan biaya, yang dikumpulkan dan divalidasi oleh lapisan integrasi.
Cocokkan dan catat
Lapisan tersebut mencocokkan transaksi terselesaikan dengan penjualan awal dan mencatat penjualan, biaya, dan pembayaran keluar ke ERP.
Saat terjadi kegagalan
Tidak ada jawaban tepat waktu
Jika gateway tidak menerima respons dalam batas waktu acquirer, gateway mengirim pembalikan, pesan ISO 8583 0400 atau padanan API-nya, sehingga pelanggan tidak pernah ditagih untuk penjualan yang tidak selesai.
Pembayaran ditolak
Kode respons sampai ke kasir atau checkout dengan pesan yang jelas. Tingkat penolakan dipantau, sehingga lonjakan yang menunjukkan gangguan teknis memicu peringatan.
Penyelesaian tidak cocok
Jumlah terselesaikan yang berbeda dari penjualan, atau penjualan tanpa penyelesaian, masuk ke daftar tinjauan untuk tim operasi pembayaran Anda, dengan kedua catatan ditampilkan berdampingan.
Pemegang kartu menyengketakan pembayaran
Laporan sengketa dari acquirer diimpor dan ditautkan ke penjualan awal dan penyelesaiannya, sehingga tim Anda dapat menanggapi dengan bukti di satu tempat.
Standar dan sistem
- Standar dan kanal perbankan
- SFTP (H2H)
- Pembayaran
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integrasi
- REST
- Webhooks
Pertanyaan dan jawaban
Apa perbedaan antara gateway dan acquirer?
Acquirer adalah bank atau lembaga berlisensi yang memproses pembayaran kartu untuk Anda dan membayarkan dananya. Gateway adalah layanan teknis di depannya yang menerima permintaan dari terminal dan checkout, melakukan tokenisasi kartu, dan meneruskannya. Sebagian penyedia menjalankan kedua peran. Rancangan ini berfungsi pada kedua model dan menjaga kedua peran tetap jelas.
Apakah rancangan ini menjauhkan data kartu dari sistem kami?
Itulah tujuan rancangan ini. Nomor kartu direkam oleh terminal bersertifikasi atau halaman pembayaran terkelola dan digantikan dengan token di gateway, sehingga POS, ERP, dan penyimpanan data Anda hanya melihat token. Hal ini mengurangi bagian lingkungan Anda yang tercakup PCI DSS. Asesor Anda yang menetapkan cakupan akhirnya.
Apakah ISO 8583 sama untuk setiap acquirer?
Tidak. ISO 8583 mendefinisikan sebuah struktur, dan setiap acquirer atau jaringan menerbitkan spesifikasi sendiri untuk bidang, tipe pesan, dan kode. Karena itu kami membangun berdasarkan spesifikasi acquirer dan menjalankan uji sertifikasinya. Gateway API di depan acquirer menyembunyikan perbedaan tersebut, yang sering kali lebih sederhana bagi peritel.
Mengapa penyelesaian tiba lebih lambat daripada penjualan?
Otorisasi hanya memesan dana. Acquirer menyelesaikan secara batch, setelah memotong biayanya dan biaya skema jika ada, lalu membayarkan sesuai jadwalnya sendiri. Karena itu rancangan ini memperlakukan otorisasi dan penyelesaian sebagai peristiwa terpisah dan mencocokkannya, sehingga tim keuangan dapat melihat apa yang terjual, apa yang sudah diselesaikan, dan apa yang masih akan diterima.
Apakah Anda mendukung EMV 3-D Secure untuk pembayaran online?
Ya. Untuk pembayaran kartu online, kami mengintegrasikan EMV 3-D Secure melalui gateway, sehingga penerbit dapat mengautentikasi pemegang kartu bila regulasi atau risiko mensyaratkannya. Kami menangani alur tantangan (challenge) dan alur tanpa hambatan (frictionless) di checkout serta menguji keduanya dengan kartu uji dari penyedia.
Dapatkah kami menggunakan lebih dari satu penyedia pembayaran?
Ya. Lapisan integrasi menyimpan satu model internal untuk sebuah pembayaran dan memetakannya ke setiap penyedia, sehingga Anda dapat meneruskan berdasarkan kanal, negara, atau jenis kartu, atau memindahkan volume antarpenyedia. Setiap penyedia tetap memerlukan integrasi dan sertifikasi sendiri, yang kami rencanakan per penyedia.
Mulai dengan percakapan, bukan kontrak.
Sampaikan apa yang perlu Anda bangun, hubungkan atau amankan. Arsitek kami membahasnya bersama Anda, lalu menyarankan titik awal.
Yang terjadi selanjutnya
Menyepakati waktu
Tim kami mengirim email kepada Anda untuk menyepakati waktu sesi.
Sesi pra-konsultasi
sesi pra-konsultasi online gratis selama 30 menit: kami membahas sasaran, sistem, dan kendala Anda.
Tinjauan kesiapan
Dalam tinjauan kesiapan gratis selama 48 jam, Arsitek Utama memeriksa proyek Anda terhadap definisi siap 6 poin dan merekomendasikan jalur yang sesuai.
Memilih jalur
Proyek yang lingkupnya sudah siap menerima proposal yang mengikat dalam 3–5 hari kerja. Proyek pada tahap konsep dimulai di Blueprint Studio. Sistem yang sedang berjalan tetapi gagal, tidak terdokumentasi, atau perlu integrasi dimulai dengan diagnostik senilai 1–2 minggu. Blueprint Studio dan diagnostik masing-masing memiliki biaya tetap yang dicantumkan dalam proposal.