Kody odpowiedzi emitenta i przetwarzanie

1) Dlaczego zrozumieć kody odpowiedzi

Kod odpowiedzi emitenta określa następujące działanie: powtarzać, powtarzać z SCA/3DS, trasować inaczej, nie powtarzać lub escalować do użytkownika. Poprawna klasyfikacja kodu zwiększa wskaźnik zatwierdzenia (AR), zmniejsza koszty i zmniejsza udział spornych transakcji.

2) Taksonomia kodu (przegląd)

• Sukces

„00” - zatwierdzone (lub „85” w oddzielnych implementacjach).

Miękkie spadki

„51” - Niewystarczające fundusze.
„91” - Emitent lub przełącznik niepracujący.
„96” - Nieprawidłowe działanie systemu (błąd ogólny).
„62/65” - ograniczenia/przekroczenia częstotliwości.
"Potrzebne required/3DS kody programu R1/R3 lub miękkiego spadku według SCA.

Twarde spadki

„05” - Nie szanować (często rzeczywiście twarde, jeśli nie oznaczone SCA-miękkie).
'14' - Nieprawidłowy numer karty.
„54” - Karta wygasła.
„57” - Transakcja niedozwolona dla posiadacza karty.
'59' - Podejrzenie oszustwa.
„43/41” - Skradziona/Zagubiona karta.
„03/04/13” - Nieprawidłowy handlowiec/w/w (błąd parametru).

3) Macierz decyzji (zasady przetwarzania)

Poniżej znajduje się praktyczny kod → macierz działania dla handlu elektronicznego (MCC 7995), gdzie 3DS2/SCA i COF/MIT są krytyczne.

4) Odtwarzacze retray i backoff

Idempotencja: Każda próba musi mieć klucz idempotencji i naprawić maszynę stanu prób.

4. 1 Ogólny szablon backoff (miękki)

pierwsza awaria → powtórzyć w 10-15 min

2 → w ciągu 1-2 godzin

3rd → po 24h, a następnie zatrzymać

Jeśli miękki spadek = SCA wymagane → natychmiast 3DS2 bez oczekiwania.

4. 2 Powtórzenia dotyczące subskrypcji (MIT/COF)

Oddzielna kolejka ponownych prób MIT (nie zakłócaj CIT).
Wykładnicze backoff + jitter (losowe rozłożenie), aby uniknąć „burzy” o 00:00.
Przechowywać wiązanie z początkowym CIT (odpowiedzialność/PSD2).

5) Smart-routing kodem/BIN/PSP

Jeżeli „91/96” dotyczy określonych klastrów BIN, przejdź do PSP-B, który ma wyższy wskaźnik AR dla tych emitentów.
Dla '05' po 3DS - spróbuj token sieciowy + inny PSP (czasami wrażliwość emitenta na nadużycia finansowe pomaga).
Utrzymuj tabelę stabilności: emitent × tryb PSP × 3DS → AR/opóźnienie.

IF code in {91,96} AND bin_country == "X" THEN route = PSP_B
ELSE IF code == SCA_REQUIRED THEN enforce_3DS = true
ELSE IF code == 05 AND was_3DS == false THEN retry_with_3DS
ELSE IF code in HARD THEN stop_and_prompt_alternative

6) Związek z 3DS/SCA

Miękki spadek ze względu na SCA, rozpoznać jednoznacznie i nie marnować prób na „ślepych” retras.
W CIT, uruchom EMV 3DS 2. x; kolejne MIT - brak SCA z poprawnymi odniesieniami.
Prześlij maksymalny kontekst (urządzenie, wiek konta, prędkość) - zwiększa szansę na bezstratność.

7) Wzory UX, aby zwiększyć konwersję

Jasne statusy: „Niewystarczające środki”, „Bank czasowo niedostępny”, „Wymagane potwierdzenie banku”.
Przycisk Redo z timerem (dla '91/96').
Alternatywna oferta: portfele A2A/local, częściowa kwota, inne PSP.
W subskrypcjach - powiadomienia miękkie z „uaktualnij formę płatności” (link do aktualizacji karty).

8) Spory i obciążenia zwrotne: co ma znaczenie według kodu

Sukces 3DS (EIK/CAVV) zmniejsza ryzyko oszustwa/obciążenia zwrotnego i przenosi odpowiedzialność.
Kody „59/41/43” są wysokim ryzykiem: przygotowanie dowodów i dzienników zwalczania nadużyć finansowych.
„05” - without 3DS często wpisuje się w „brak zezwolenia posiadacza”; powtarzanie z 3DS zmniejsza ryzyko sporu.
Przechowywać artefakty: dsTransID/ECI/CAVV, logi SCA, dowód usługi.

9) Elementy przetwarzania architektonicznego

Orkiestrator płatności: zasady, idempotency, state machine, smart-routing, reinitisation 3DS.
Usługa BIN: country/scheme/card type → routing and limits policy.
Serwer 3DS: wersje 2. 1/2. 2/2. 3, web/mobile SDK, oddzielone od produkcji.
Tokenizzate: żetony sieciowe (VTS/MDES/ма. п.) + skarbiec-fallback.
Aktualizacja karty: Aktualizacje VAU/ABU/acquiring.
Obserwability: AR/Reasons loss metrics, alerts on '05/91/96' bursts in BIN/issuers section.

10) Mierniki i wpisy

• AR według kodu i grupy (miękki/twardy).
• Miękki spadek → udany retray% (często z 3DS).
• Udostępnianie '05' po 3DS (nienormalnie wysokie → spojrzeć na routing/przeciwdziałanie oszustwom).
• "91/96 wg BIN/kraju (SLO według dostępności emitenta/PSP).
• Czas na udane powtórzenie (p50/p95).
• Koszt za zatwierdzoną txn (biorąc pod uwagę ponowne próby).

• Spike '91/96'> X% w 15 min w klastrze BIN.
• '05 ° rowth> Y% po udanym 3DS.
• Sukces retray

11) Częste błędy

Brak rozróżnienia SCA-soft vs generic '05'.
Wiele powtórzeń bez idempotencji → duplikaty w księdze.
Ignorowanie limitów geograficznych i limitów emitenta („62/65”).
Rejestrowanie PAN/CVV zamiast żetonów (naruszenie PCI).
„Jeden PSP dla wszystkich przypadków” bez routingu emitenta.

12) Lista kontrolna wdrażania

• Słownik mapowania kodów (ISO/schemas/PSP) → pojedyncza taksonomia (soft/hard/SCA).
• Państwowa maszyna i idempotencja do prób (klucze, TTL).
• Zasady backoff i limity ponownej próby (oddzielne dla CIT/MIT).
• Auto- 3DS2 z SCA-soft; zachowanie artefaktów.
• Inteligentne trasy według BIN/country/emitenta i zdrowia PSP.
• Deski rozdzielcze AR/spadki i wpisy za pomocą przyczepności kodu.
• Szablony UX ze względu na odmowę i sugestie alternatywne.
• Integracja z aktualizatorem kart i żetonami sieciowymi.
• Spór playbooks według grupy przyczyny.
• Polityka PWZ: PAN-safe, maskowanie, logowanie bez danych wrażliwych.

13) Podsumowanie

Kody odpowiedzi to język emitenta. "Przełożyć to na zrozumiałe działania: gdzie powtarzać, gdzie iść do 3DS od razu, gdzie zmienić PSP, a gdzie zatrzymać i zaoferować alternatywę. Silny orkiestrator z właściwą klasyfikacją miękką/twardą, regułami backoff, inteligentnym routingiem i obserwowalnością konsekwentnie zwiększa konwersję i zmniejsza koszty transakcji przetwarzanych w iGaming.