- ISO 8583 adalah standar pertukaran pesan real-time yang terjadi antarjaringan kartu kredit
- Standar ini mendefinisikan pesan yang terjadi saat kartu disentuhkan di perangkat point-of-sale atau saat mengklik "beli" secara online
- Pada awalnya, POS atau ATM langsung menghasilkan pesan, tetapi kini yang lebih umum adalah mengonversinya ke format tingkat tinggi seperti JSON lalu mengubahnya ke ISO 8583
- Struktur pesannya sederhana, tetapi implementasi detailnya kompleks dan cukup fleksibel untuk kompatibilitas antarnetwork
Format pesan dasar
Penanda tipe pesan (Message Type Indicator)
- Kode 4 digit yang menunjukkan jenis pesan (contoh:
0100 adalah permintaan otorisasi)
- Membantu penerima mengetahui field yang diharapkan
- Cara serialisasinya dapat berbeda menurut network (BCD, ASCII, dll.)
Bitmap
- Menunjukkan apakah suatu field ada
- Nilai 1 berarti field ada, 0 berarti field tidak ada
- Berukuran 8 byte dan dapat mewakili hingga 64 field
Elemen data (Data Elements)
- Field diserialisasi setelah bitmap
- Field panjang tetap selalu memiliki ukuran yang sama, sedangkan field panjang variabel menyertakan informasi panjang
- Metode encoding field dapat menggunakan ASCII, BCD, biner, dan sebagainya
Struktur pesan bertingkat
- Standar ISO 8583 mengizinkan network menyertakan data kustom khusus network
- Pesan bertingkat dapat diimplementasikan dalam bentuk tabel, bitmap, atau format TLV(Tag-Length-Value)
Tabel
- Semua field disertakan dengan panjang tetap
- Untuk mengurangi pemborosan ruang, subfield panjang variabel juga didukung
Pesan bitmap
- Keberadaan tiap subfield ditunjukkan dengan bitmap
- Mencegah pemborosan ruang saat field tidak ada
Pesan TLV
- Field diserialisasi sebagai tuple tag, length, value
- Dapat diperluas tanpa bergantung pada urutan
Desain parser
- Parser ISO 8583 dimulai dengan analisis bitmap dan definisi serialisasi setiap field
- Perlu mempertimbangkan penanganan pesan bertingkat dan perbedaan implementasi menurut network
- Menggunakan sistem tipe Sorbet milik Ruby untuk mendefinisikan kelas pesan yang aman
- Dapat mengatur field panjang tetap dan variabel, penanganan padding, dan lainnya
Penanganan kesalahan
- Dirancang agar parsing field berikutnya tetap bisa dilakukan saat parsing suatu field gagal
- Menangani kesalahan parsial sambil mempertahankan serialisasi pesan
- Menghentikan pemrosesan pesan saat terjadi kesalahan fatal
Kesimpulan
- Standar ISO 8583 terus berkembang sejak didefinisikan pada 1987 untuk memenuhi beragam kebutuhan network
- Increase membantu menangani pesan ISO 8583 agar pengguna bisa fokus pada pengembangan produk
- Anda dapat merujuk ke dokumentasi API atau menghubungi tim Increase
1 komentar
Komentar Hacker News
Visa dan Mastercard tidak mengimplementasikan ISO 8583 dengan cara yang benar-benar terstandarisasi. Masing-masing perusahaan menerbitkan ribuan halaman dokumentasi yang menjelaskan cara menggunakan field standar dan cara menyertakan data proprietari dalam pesan. Sebagian besar platform pengelolaan/penerbitan kartu mengabstraksikan hal ini dengan baik. Transisi ke ISO 20022 adalah perbaikan yang positif, tetapi kecil kemungkinan memenuhi kriteria ROI.
Jenis protokolnya (tipe pesan, bitmap definisi field, kumpulan nilai panjang tetap dan variabel) merupakan hal yang umum pada masa pengembangannya. Penerima harus berhati-hati untuk memvalidasi panjang field dinamis dan memastikan tidak membaca melewati akhir pesan. Namun, masalah-masalah ini kini sudah dipahami dengan baik.
Cukup membingungkan bahwa standar ISO 8583 tidak menjelaskan bagaimana field atau tipe pesan harus dikodekan. Akibatnya, penerima bisa saja menerima sekumpulan byte acak yang tidak dapat dipahaminya.
Belakangan ini ada banyak diskusi terkait pembayaran, dan patio11 memberikan konten yang sangat bagus. 25 tahun lalu belum ada situs web dengan penjelasan visual seperti ini. Seperti komentar lain yang menyebut EBCDIC, konversi antar-endian itu rumit. Pengalaman bekerja sama dengan kartu Discover pada awal 2000-an untuk menambahkan field GUID ke spesifikasi ISO8583 cukup menarik.
Sistem keuangan adalah salah satu medan tempur perubahan. Banyak orang tidak menyadari perubahan-perubahan ini. Perusahaan teknologi besar memiliki ekosistem pembayaran mereka sendiri, jadi perlu memberikan wawasan kepada mereka yang belum menyadarinya. Beberapa negara sedang mengikuti arus ini.
Charles Stross tampaknya sedikit menjadi gila karena standar ISO 8583, dan itu mungkin yang membuatnya menulis Accelerando. Kemungkinan standar ini sendiri adalah standar baru yang menggantikan protokol samar dari era 70-an.
Ini artikel yang sangat baik yang menjelaskan alasan ISO20022 akan menggantikan 8583. Terutama di wilayah yang tidak didominasi jaringan proprietari M/V. Kartu kredit dapat diimplementasikan dalam sistem pembayaran baru bersama rekening kredit yang disediakan bank. Pembayaran instan antar-rekening dan transaksi berbiaya rendah dengan harga tetap menjadi mungkin.
Menarik melihat berbagai cara untuk mengakali keterbatasan ISO 8583. Belakangan ini, banyak digunakan metode untuk meneruskan informasi tambahan di luar transaksi pembayaran melalui panggilan API sebelum/sesudah pesan ISO. Ini mempercepat time-to-market, tetapi dapat menimbulkan mode kegagalan baru.
Format ini menarik. Saat menganalisis pesan ISO-8583, terasa seperti melihat sejarah terungkap. Pesan yang saya analisis menggunakan BCD, bukan EBCDIC. Tetapi satu field berisi XML, dan di dalam XML ada JSON. Setiap kali pesan diperluas, itu mencerminkan tren pada masanya.
Berbeda dengan Visa dan Mastercard, notifikasi transaksi AMEX datang hampir seketika. Begitu kartu digesek, notifikasi langsung muncul di ponsel/jam tangan, terasa seperti sihir. Sepertinya lapisan-lapisan yang dimiliki V/MC tidak ada pada AMEX.
Saya mendapatkan banyak keberhasilan dengan iso8583 yang menggunakan library Go.
Cukup menarik meninjau logika masking untuk data kartu kredit ISO 8583 yang dikodekan dalam base64 di log sistem (atau bahkan dikodekan dalam base64 yang dikodekan lagi dengan EBCDIC).