Płatności kartą
Płatności kartą: od terminala do agenta rozliczeniowego i z powrotem do księgi
Terminale EMV i bramki płatności połączone z agentami rozliczeniowymi przez ISO 8583 lub interfejsy API, z plikami rozliczeniowymi uzgadnianymi w ERP.
Blueprint
Prosimy przewinąć w bok, aby zobaczyć cały rysunek.
Płatności kartą: autoryzacja przy kasie, rozliczenie później, uzgadnianie w ERP
Terminal lub kasa pyta bramkę, bramka pyta agenta rozliczeniowego, a agent kieruje transakcję do systemu kartowego i banku wydawcy. Pliki rozliczeniowe przychodzą później i są dopasowywane do sprzedaży i opłat w ERP. Przekroczenie czasu wywołuje odwrócenie transakcji, aby klient nigdy nie został obciążony dwa razy.
- Ścieżka główna
- Asynchroniczny
- Ścieżka wyjątku
Przepływ w 8 krokach
Przepływ krok po kroku
- Od Terminal EMV lub kasa internetowa do Bramka płatności: Żądanie autoryzacji przez EMV · REST/JSON (ścieżka główna).
- Od Bramka płatności do Agent rozliczeniowy: Autoryzacja przez ISO 8583 (ścieżka główna).
- Od Agent rozliczeniowy do System kartowy i bank wydawca: Przekierowane do banku wydawcy przez ISO 8583 (ścieżka główna).
- Od Agent rozliczeniowy do Bramka płatności: Zatwierdzone lub odrzucone przez ISO 8583 (asynchroniczny).
- Od Agent rozliczeniowy do Warstwa integracji: Pliki rozliczeniowe i opłat przez SFTP (asynchroniczny).
- Od Warstwa integracji do ERP: Rozliczona sprzedaż, opłaty i wypłaty przez REST/JSON (ścieżka główna).
- Od Bramka płatności do Terminal EMV lub kasa internetowa: Brak odpowiedzi na czas: automatyczne odwrócenie przez ISO 8583 0400 (ścieżka wyjątku).
- Od Warstwa integracji do Zespół operacji płatniczych: Niezgodność rozliczenia lub chargeback (ścieżka wyjątku).
Przegląd
To droga płatności kartą, od terminala lub kasy online do agenta rozliczeniowego, systemu kartowego i wydawcy, i z powrotem. Klient czeka na odpowiedź przy kasie. Pieniądze, pomniejszone o opłaty, przychodzą później w pliku rozliczeniowym, który trzeba dopasować do sprzedaży w Państwa ERP.
Wzorzec referencyjny prowadzi autoryzacje przez bramkę płatności, która tokenizuje kartę i kieruje żądanie do agenta rozliczeniowego przez ISO 8583 lub jego API. Pliki rozliczeń i opłat zbiera warstwa integracji, dopasowuje do pierwotnej sprzedaży i księguje w ERP jako sprzedaż, opłaty i wypłaty.
Projekt obejmuje też to, co się psuje. Żądanie bez odpowiedzi na czas jest odwracane, aby klient nie został obciążony dwa razy. Rozliczenie, które nie pasuje, lub chargeback trafia do Państwa zespołu operacji płatności z załączoną pierwotną sprzedażą.
Jak działa przepływ
Zacząć na terminalu lub w kasie
Terminal EMV czyta kartę chipową lub zbliżeniową albo kasa online pobiera kartę przez hostowaną stronę i wysyła żądanie autoryzacji do bramki.
Autoryzować przez bramkę
Bramka zastępuje numer karty tokenem i wysyła autoryzację do agenta rozliczeniowego przez ISO 8583 lub jego API.
Skierować do wydawcy
Agent rozliczeniowy kieruje żądanie przez system kartowy do wydawcy, który je zatwierdza lub odrzuca.
Zwrócić odpowiedź
Zatwierdzenie lub odmowa wracają tą samą drogą do terminala lub kasy wraz z kodem odpowiedzi.
Odebrać rozliczenie
Agent rozliczeniowy wysyła później pliki rozliczeń i opłat, które warstwa integracji zbiera i waliduje.
Dopasować i zaksięgować
Warstwa dopasowuje rozliczone transakcje do pierwotnej sprzedaży i księguje sprzedaż, opłaty i wypłaty w ERP.
Gdy coś zawodzi
Brak odpowiedzi na czas
Jeśli bramka nie dostanie odpowiedzi w limicie czasu agenta rozliczeniowego, wysyła odwrócenie, komunikat ISO 8583 0400 lub jego odpowiednik API, aby klient nigdy nie został obciążony za niedokończoną sprzedaż.
Płatność odrzucona
Kod odpowiedzi dociera do kasy lub kasy online z jasnym komunikatem. Wskaźniki odmów są monitorowane, więc skok wskazujący na usterkę techniczną wywołuje alert.
Rozliczenie nie pasuje
Rozliczona kwota inna niż sprzedaż albo sprzedaż bez rozliczenia trafia na listę przeglądu dla Państwa zespołu operacji płatności, z oboma zapisami obok siebie.
Posiadacz karty kwestionuje płatność
Raport sporów agenta rozliczeniowego jest importowany i łączony z pierwotną sprzedażą i rozliczeniem, aby Państwa zespół mógł odpowiedzieć dowodami w jednym miejscu.
Standardy i systemy
- Standardy i kanały bankowe
- SFTP (H2H)
- Płatności
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integracja
- REST
- Webhooks
Pytania i odpowiedzi
Czym różni się bramka od agenta rozliczeniowego?
Agent rozliczeniowy to bank lub licencjonowana instytucja, która przetwarza dla Państwa płatności kartą i wypłaca pieniądze. Bramka to usługa techniczna przed nim, przyjmująca żądania z terminali i kas, tokenizująca karty i kierująca je dalej. Niektórzy dostawcy są jednym i drugim. Projekt działa w obu przypadkach i utrzymuje role rozdzielone.
Czy to trzyma dane kart poza naszymi systemami?
Taki jest cel projektu. Numery kart są pobierane przez certyfikowany terminal lub hostowaną stronę płatności i zastępowane tokenami w bramce, więc POS, ERP i magazyny danych widzą wyłącznie tokeny. Zmniejsza to część Państwa środowiska objętą PCI DSS. Ostateczny zakres potwierdza Państwa audytor.
Czy ISO 8583 jest takie samo u każdego agenta rozliczeniowego?
Nie. ISO 8583 definiuje strukturę, a każdy agent rozliczeniowy lub sieć publikuje własną specyfikację pól, typów komunikatów i kodów. Dlatego budujemy na podstawie specyfikacji agenta rozliczeniowego i uruchamiamy jego testy certyfikacyjne. API bramki przed agentem rozliczeniowym ukrywa te różnice, co dla detalistów jest często prostsze.
Dlaczego rozliczenie przychodzi później niż sprzedaż?
Autoryzacja tylko rezerwuje środki. Agent rozliczeniowy rozlicza w partiach, po odjęciu swoich opłat i ewentualnych opłat organizacji, i wypłaca według własnego harmonogramu. Dlatego projekt traktuje autoryzację i rozliczenie jako osobne zdarzenia i dopasowuje je, aby finanse widziały, co sprzedano, co rozliczono i co jeszcze ma przyjść.
Czy obsługują Państwo EMV 3-D Secure dla płatności online?
Tak. Dla płatności kartą online integrujemy EMV 3-D Secure przez bramkę, aby wydawca mógł uwierzytelnić posiadacza karty tam, gdzie wymaga tego regulacja lub ryzyko. Obsługujemy przepływy z wyzwaniem i bez, w kasie, i testujemy oba na kartach testowych dostawcy.
Czy można używać więcej niż jednego dostawcy płatności?
Tak. Warstwa integracji utrzymuje jeden wewnętrzny model płatności i mapuje go na każdego dostawcę, więc można kierować według kanału, kraju lub typu karty albo przenosić wolumen między dostawcami. Każdy dostawca nadal potrzebuje własnej integracji i certyfikacji, które planujemy dostawca po dostawcy.
Najpierw rozmowa, nie umowa.
Prosimy opowiedzieć, co trzeba zbudować, połączyć lub zabezpieczyć. Architekt przechodzi przez to z Państwem, a następnie rekomenduje, od czego zacząć.
Co dalej
Ustalenie terminu
Nasz zespół pisze do Państwa, aby ustalić termin sesji.
Sesja przeddoradcza
To bezpłatna 30-minutowa konsultacja wstępna online: omawiamy Państwa cele, systemy i ograniczenia.
Ocena gotowości
To bezpłatna 48-godzinna ocena gotowości: główny architekt sprawdza projekt pod kątem 6-punktowej definicji gotowości i rekomenduje dopasowaną ścieżkę.
Wybór ścieżki
Projekty gotowe zakresowo otrzymują wiążącą ofertę w ciągu 3–5 dni roboczych. Projekty na etapie koncepcji zaczynają się w Blueprint Studio. Działający system, który zawodzi, nie ma dokumentacji lub wymaga integracji, zaczyna się od diagnostyki: 1–2 tygodnie. Blueprint Studio i diagnostyka mają stałą opłatę podaną w ofercie.