Kurumsal Sistemler ve Entegrasyonlar
Kart ödemeleri
Kart ödemeleri: terminalden edinen bankaya ve deftere geri
ISO 8583 veya API’ler üzerinden edinen bankalara bağlanan EMV terminalleri ve ödeme geçitleri, ERP’de mutabakatı yapılan hesaplaşma dosyalarıyla birlikte.
Plan
Tüm çizimi görmek için yana kaydırın.
Kart ödemeleri: kasada yetkilendirilir, sonra hesaplaşır, ERP’de mutabakat edilir
Terminal veya ödeme sayfası ödeme geçidine sorar, geçit edinen bankaya sorar, edinen banka kart şemasına ve kartı veren kuruluşa yönlendirir. Hesaplaşma dosyaları daha sonra gelir ve ERP’de satışlar ve ücretlerle eşleştirilir. Zaman aşımı bir iptal işlemi başlatır, böylece müşteriden asla iki kez tahsilat yapılmaz.
- Birincil akış
- Asenkron
- İstisna yolu
Akış 8 adımda
Akış, adım adım
- EMV terminali veya çevrimiçi ödeme sayfası → Ödeme geçidi: Yetkilendirme talebi, EMV · REST/JSON üzerinden (birincil akış).
- Ödeme geçidi → Edinen banka: Yetkilendirme, ISO 8583 üzerinden (birincil akış).
- Edinen banka → Kart şeması ve kartı veren kuruluş: Kartı veren bankaya yönlendirildi, ISO 8583 üzerinden (birincil akış).
- Edinen banka → Ödeme geçidi: Onaylandı veya reddedildi, ISO 8583 üzerinden (asenkron).
- Edinen banka → Entegrasyon katmanı: Hesaplaşma ve ücret dosyaları, SFTP üzerinden (asenkron).
- Entegrasyon katmanı → ERP: Hesaplaşan satışlar, ücretler ve ödemeler, REST/JSON üzerinden (birincil akış).
- Ödeme geçidi → EMV terminali veya çevrimiçi ödeme sayfası: Zamanında yanıt yok: otomatik iptal, ISO 8583 0400 üzerinden (istisna yolu).
- Entegrasyon katmanı → Ödeme operasyon ekibi: Hesaplaşma uyuşmazlığı veya ters ibraz (istisna yolu).
Genel bakış
Bu, bir kart ödemesinin terminalden veya çevrimiçi ödeme sayfasından edinen bankaya, kart şemasına ve kartı veren kuruluşa ve geri dönüş yolculuğudur. Müşteri kasada yanıtı bekler. Para, ücretler düşüldükten sonra, ERP’nizdeki satışlarla eşleştirilmesi gereken bir hesaplaşma dosyası içinde daha sonra gelir.
Referans tasarım, yetkilendirmeleri kartı tokenleştiren ve isteği ISO 8583 veya edinen bankanın API’si üzerinden edinen bankaya yönlendiren bir ödeme geçidi aracılığıyla gönderir. Hesaplaşma ve ücret dosyaları entegrasyon katmanı tarafından toplanır, orijinal satışlarla eşleştirilir ve ERP’ye satış, ücret ve ödeme olarak kaydedilir.
Tasarım ayrıca ters giden durumları da kapsar. Zamanında yanıt alınamayan bir istek geri alınır, böylece müşteriden iki kez ücret alınmaz. Eşleşmeyen bir hesaplaşma veya bir ters ibraz, orijinal satış eklenmiş olarak ödeme operasyonları ekibinize gider.
Akış nasıl işler
Terminalde veya ödeme sayfasında başlayın
EMV terminali çipi veya temassız kartı okur ya da çevrimiçi ödeme sayfası kartı barındırılan bir sayfa aracılığıyla toplar ve geçide bir yetkilendirme isteği gönderir.
Ödeme geçidi üzerinden yetkilendirin
Ödeme geçidi, kart numarasını bir token ile değiştirir ve yetkilendirmeyi ISO 8583 veya edinen bankanın API’si üzerinden edinen bankaya gönderir.
Kartı veren kuruluşa yönlendirin
Edinen banka, isteği kart şeması üzerinden onaylayan veya reddeden kartı veren kuruluşa yönlendirir.
Yanıtı geri döndürün
Onay veya ret, yanıt koduyla birlikte aynı yol üzerinden terminale veya ödeme sayfasına döner.
Hesaplaşmayı alın
Edinen banka daha sonra hesaplaşma ve ücret dosyalarını gönderir; entegrasyon katmanı bunları toplar ve doğrular.
Eşleştirin ve kaydedin
Katman, hesaplaşan işlemleri orijinal satışlarla eşleştirir ve satışları, ücretleri ve ödemeleri ERP’ye kaydeder.
Bir şey başarısız olduğunda
Zamanında yanıt yok
Geçit, edinen bankanın zaman sınırı içinde yanıt alamazsa, tamamlanmayan bir satış için müşteriden asla ücret alınmaması için bir geri alma, ISO 8583 0400 mesajı veya API eşdeğerini gönderir.
Bir ödeme reddedilir
Yanıt kodu, net bir mesajla kasaya veya ödeme sayfasına ulaşır. Ret oranları izlenir, böylece teknik bir arızaya işaret eden bir sıçrama uyarı oluşturur.
Hesaplaşma eşleşmiyor
Satıştan farklı bir hesaplaşma tutarı veya hesaplaşması olmayan bir satış, her iki kayıt yan yana olacak şekilde ödeme operasyonları ekibiniz için bir inceleme listesine gider.
Kart sahibi bir ödemeye itiraz eder
Edinen bankanın itiraz raporu içe aktarılır ve orijinal satış ve hesaplaşma ile ilişkilendirilir, böylece ekibiniz kanıtlarla tek bir yerde yanıt verebilir.
Standartlar ve sistemler
- Bankacılık standartları ve kanalları
- SFTP (H2H)
- Ödemeler
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Entegrasyon
- REST
- Webhooks
Sorular ve yanıtlar
Geçit ile edinen banka arasındaki fark nedir?
Edinen banka, sizin için kart ödemelerini işleyen ve parayı ödeyen banka veya lisanslı kuruluştur. Geçit, terminal ve ödeme sayfalarından gelen istekleri kabul eden, kartları tokenleştiren ve yönlendiren önündeki teknik hizmettir. Bazı sağlayıcılar her ikisidir. Tasarım her iki durumda da çalışır ve iki rolü net tutar.
Bu, kart verilerini sistemlerimizin dışında tutar mı?
Tasarımın amacı budur. Kart numaraları sertifikalı terminal veya barındırılan bir ödeme sayfası tarafından alınır ve geçitte tokenlarla değiştirilir, böylece POS’unuz, ERP’niz ve veri depolarınız yalnızca tokenları görür. Bu, PCI DSS’in uygulandığı varlıklarınızın kısmını azaltır. Nihai kapsamı değerlendiriciniz onaylar.
ISO 8583 her edinen banka için aynı mıdır?
Hayır. ISO 8583 bir yapı tanımlar ve her edinen banka veya ağ, alanlar, mesaj türleri ve kodlar için kendi şartnamesini yayımlar. Bu nedenle edinen bankanın şartnamesinden yola çıkar ve onun sertifikasyon testlerini çalıştırırız. Edinen bankanın önündeki bir geçit API’si bu farklılıkları gizler, bu da perakendeciler için genellikle daha basittir.
Hesaplaşma neden satıştan daha sonra gelir?
Yetkilendirme yalnızca fonları rezerve eder. Edinen banka, ücretlerini ve varsa şema masraflarını düştükten sonra partiler halinde hesaplaşır ve kendi takvimine göre öder. Bu nedenle tasarım, yetkilendirme ve hesaplaşmayı ayrı olaylar olarak ele alır ve eşleştirir, böylece finans neyin satıldığını, neyin hesaplaşıldığını ve neyin hâlâ gelmesi gerektiğini görebilir.
Çevrimiçi ödemeler için EMV 3-D Secure destekliyor musunuz?
Evet. Çevrimiçi kart ödemeleri için EMV 3-D Secure’ü geçit üzerinden entegre ederiz, böylece kartı veren kuruluş, düzenleme veya risk gerektirdiğinde kart sahibini doğrulayabilir. Ödeme sayfasında challenge ve frictionless akışlarını ele alır ve her ikisini de sağlayıcının test kartlarıyla test ederiz.
Birden fazla ödeme sağlayıcısı kullanabilir miyiz?
Evet. Entegrasyon katmanı, bir ödemenin tek bir iç modelini tutar ve bunu her sağlayıcıya eşler, böylece kanal, ülke veya kart türüne göre yönlendirme yapabilir veya hacmi sağlayıcılar arasında taşıyabilirsiniz. Her sağlayıcı yine de kendi entegrasyonunu ve sertifikasyonunu gerektirir; bunu sağlayıcı sağlayıcı planlarız.
Sözleşmeyle değil, bir görüşmeyle başlayın.
Ne inşa etmeniz, neyi bağlamanız veya neyi güvence altına almanız gerektiğini bize anlatın. Bir mimar sizinle birlikte inceler ve nereden başlanacağını önerir.
Sırada ne var
Zaman belirleme
Ekibimiz oturum için bir zaman belirlemek üzere size e-posta gönderir.
Ön danışmanlık oturumu
Bir ücretsiz 30 dakikalık çevrim içi ön danışmanlık oturumu: hedeflerinizi, sistemlerinizi ve kısıtlarınızı gözden geçiririz.
Hazırlık incelemesi
Bir ücretsiz 48 saatlik hazırlık incelemesi kapsamında baş mimar, projenizi 6 maddelik Hazırlık Tanımı’na göre kontrol eder ve uygun olan yolu önerir.
Yolun seçilmesi
Kapsamı hazır projeler 3–5 iş günü içinde içinde bağlayıcı bir teklif alır. Konsept aşamasındaki projeler Blueprint Studio’da başlar. Arızalı, belgelenmemiş veya entegrasyon gerektiren canlı bir sistem, 1–2 hafta teşhisiyle başlar. Blueprint Studio ve teşhisin her biri, teklifte belirtilen sabit bir ücrete tabidir.