- ISO 8583, kredi kartı ağları arasında gerçekleşen gerçek zamanlı mesaj alışverişi standardıdır
- Bu standart, satış noktası cihazında karta dokunulduğunda veya çevrimiçi olarak "Satın al" düğmesine tıklandığında oluşan mesajları tanımlar
- Başlangıçta mesajlar doğrudan POS veya ATM tarafından üretiliyordu; bugün ise çoğunlukla önce JSON gibi daha yüksek seviyeli bir formata dönüştürülüp ardından ISO 8583'e çevrilir
- Mesaj yapısı basittir, ancak ayrıntılı uygulama karmaşıktır ve ağlar arası uyumluluk için esneklik sunar
Temel mesaj biçimi
Mesaj tipi göstergesi (Message Type Indicator)
- 4 haneli bir kodla mesaj türünü belirtir (
0100, örneğin bir yetkilendirme isteğidir)
- Alıcının hangi alanları beklemesi gerektiğini anlamasına yardımcı olur
- Serileştirme yöntemi ağa göre değişebilir (BCD, ASCII vb.)
Bitmap
- Alanın mevcut olup olmadığını gösterir
- 1, alanın mevcut olduğunu; 0 ise alanın olmadığını belirtir
- 8 bayt boyutundadır ve en fazla 64 alanı gösterebilir
Veri öğeleri (Data Elements)
- Alanlar, bitmap'ten sonra serileştirilir
- Sabit uzunluklu alanlar her zaman aynı boyuttadır, değişken uzunluklu alanlar ise uzunluk bilgisi içerir
- Alanların kodlanmasında ASCII, BCD, ikili biçim gibi yöntemler kullanılır
İç içe geçmiş mesaj yapıları
- ISO 8583 standardı, ağların ağa özgü kullanıcı tanımlı veriler içermesine izin verir
- İç içe geçmiş mesajlar tablo, bitmap ve TLV(Tag-Length-Value) biçimleriyle uygulanabilir
Tablolar
- Tüm alanlar sabit uzunlukla yer alır
- Alan israfını azaltmak için ek olarak değişken uzunluklu alt alanlar da desteklenir
Bitmap mesajları
- Her alt alanın varlığı bir bitmap ile gösterilir
- Alan olmadığında alan israfını önler
TLV mesajları
- Alanlar etiket, uzunluk ve değer üçlüsü olarak serileştirilir
- Sıraya bağlı olmadan genişletilebilir
Parser tasarımı
- ISO 8583 parser'ı, bitmap çözümlemesi ve her alanın serileştirme tanımıyla başlar
- İç içe geçmiş mesajların işlenmesi ve ağa özgü uygulama farkları dikkate alınmalıdır
- Ruby'nin Sorbet tip sistemi kullanılarak güvenli mesaj sınıfları tanımlanabilir
- Sabit uzunluklu ve değişken uzunluklu alanlar ile padding işlemleri yapılandırılabilir
Hata işleme
- Bir alan ayrıştırılamadığında sonraki alanların ayrıştırılmasına devam edilebilecek şekilde tasarlanır
- Mesaj serileştirmesi korunurken kısmi hatalar işlenir
- Kritik bir hata oluşursa mesaj işleme durdurulur
Sonuç
- ISO 8583 standardı, 1987'de tanımlanmasından bu yana sürekli gelişerek çeşitli ağ gereksinimlerini karşılamıştır
- Increase, ISO 8583 mesajlarını işleyerek kullanıcıların ürün geliştirmeye odaklanmasına yardımcı olur
- API belgelerine bakabilir veya Increase ekibiyle iletişime geçebilirsiniz
1 yorum
Hacker News yorumu
Visa ve Mastercard, ISO 8583’ü standartlaştırılmış bir şekilde uygulamıyor. Her şirket, standart alanların nasıl kullanılacağını ve mesajlara özel verilerin nasıl ekleneceğini açıklayan binlerce sayfalık doküman yayımlıyor. Kart yönetimi/ihraç platformlarının çoğu bunu iyi soyutluyor. ISO 20022’ye geçiş olumlu bir iyileştirme, ancak ROI eşiğini karşılaması pek olası değil.
Protokol türü (mesaj türü, alan tanımı bitmap’i, sabit ve değişken uzunluklu değer kümeleri) geliştirildiği dönemde yaygındı. Alıcı tarafta dinamik alan uzunluklarını doğrulamak ve mesajın sonunun ötesine okumamaya dikkat etmek gerekiyor. Ancak bu sorunlar artık iyi anlaşılmış durumda.
ISO 8583 standardının alanların ya da mesaj türlerinin nasıl kodlanacağını belirtmemesi şaşırtıcı. Bu yüzden alıcı, mesajı anlayamadan rastgele bayt kümeleri alabiliyor.
Son zamanlarda ödemelerle ilgili çok tartışma var ve patio11 harika içerikler üretiyor. 25 yıl önce böyle görsel anlatımlı web siteleri yoktu. EBCDIC’ten bahseden başka bir yorumda olduğu gibi, endian dönüşümleri karmaşık. 2000’lerin başında Discover kart ile çalışıp ISO8583 spesifikasyonuna GUID alanı ekleme deneyimi ilginçti.
Finansal sistemler, değişimin yaşandığı cephelerden biri. Birçok insan bu değişimleri fark etmiyor. Büyük teknoloji şirketleri kendi ödeme ekosistemlerine sahip ve bunun farkında olmayanlara içgörü sunmak gerekiyor. Bazı ülkeler bu eğilimi takip ediyor.
Charles Stross, ISO 8583 standardı yüzünden biraz kafayı sıyırmış olabilir ve bu da onu Accelerando’yu yazmaya itmiş olabilir. Bu standart muhtemelen 70’lerin belirsiz protokollerinin yerine gelen yeni standarttı.
ISO20022’nin neden 8583’ün yerini alması gerektiğini anlatan harika bir yazı. Özellikle M/V’ye ait özel ağların baskın olmadığı bölgelerde. Kredi kartları, yeni ödeme sistemlerinde bankaların sunduğu kredi hesaplarıyla birlikte uygulanabilir. Hesaptan hesaba anlık ödeme, düşük maliyetli sabit fiyatlı işlemler vb. mümkün olabilir.
ISO 8583’ün sınırlarını aşmak için kullanılan çeşitli yöntemleri görmek eğlenceliydi. Son dönemde, ödeme işleminin dışındaki ek bilgileri ISO mesajlarından önce/sonra yapılan API çağrılarıyla aktarma yöntemi çok kullanılıyor. Bu pazara çıkış süresini kısaltıyor ama yeni arıza modları da yaratabiliyor.
Bu format eğlenceliydi. ISO-8583 mesajlarını ayrıştırırken tarihin açıldığını görebiliyordunuz. Benim ayrıştırdığım mesajlar EBCDIC değil BCD idi. Ama bir alanın içinde XML vardı, XML’in içinde de JSON vardı. Mesaj her genişletildiğinde dönemin modasını yansıtıyordu.
Visa ve Mastercard’ın aksine, AMEX işlem bildirimleri neredeyse anında geliyor. Kartı kaydırır kaydırmaz telefonda/saatte bildirim belirmesi sihir gibi. Görünüşe göre V/MC’de olan bazı katmanlar AMEX’te yok.
Go kütüphanesi kullanan iso8583 ile çok başarılı sonuçlar aldım.
Sistem loglarında base64 ile kodlanmış (ya da EBCDIC ile kodlanmış base64 ile kodlanmış) ISO 8583 kredi kartı verileri için maskeleme mantığını incelemek eğlenceliydi.