Case produkcyjny · Volt.io

Opublikowane doświadczenie produkcyjne

Normalizacja europejskich integracji bankowych PSD2 dla platformy Account-to-Account obsługującej setki tysięcy transakcji miesięcznie.

Praca zamieniła zachowania specyficzne dla banków w spójny proces wewnętrzny bez ukrywania niepewności na granicy integracji.

~2 lata
pracy nad europejskimi integracjami bankowymi
Setki tysięcy / miesiąc
obsługiwanych miesięcznie przez platformę

01

Jeden proces płatności dla instytucji o różnej semantyce.

Każdy bank wnosił własny kontrakt, konfigurację certyfikatów, słownik błędów i interpretację statusu płatności. Ogólny adapter sukces–porażka usuwałby informacje potrzebne do bezpiecznych ponowień i wsparcia operacyjnego.

Integracje normalizowały różnice, zachowując zachowanie konkretnego banku na brzegu systemu. Mutual TLS i certyfikaty zabezpieczały komunikację platformy z instytucją.

02

Zewnętrzne API zgodne regulacyjnie, ale nie operacyjnie.

Inne statusy, błędy i reguły retry w każdym banku

Ten sam stan biznesowy mógł być przedstawiany przez banki w różny sposób. Część odpowiedzi była przejściowa, część końcowa, a inne wymagały bezpośredniego wyjaśnienia przed bezpiecznym ponowieniem.

Bezpieczeństwo i niejednoznaczność musiały być częścią projektu

  • PSD2 regulowało środowisko inicjowania płatności.
  • Mutual TLS i certyfikaty bankowe zabezpieczały komunikację platforma–bank.
  • Retry nie mogło tworzyć powtórnych prób płatności.
  • Nieznane i przejściowe statusy musiały pozostać widoczne zamiast być zgadywane.

Normalizacja kontraktu z zachowaniem dowodów specyficznych dla banku

Wspólny model upraszczał proces płatniczy, a adaptery bankowe zachowywały szczegóły potrzebne do diagnozy i decyzji, czy operację można ponowić.

Mój wkład

Integracje bankowe od analizy kontraktu do zachowania produkcyjnego.

Przez około dwa lata moja praca skupiała się niemal wyłącznie na europejskich integracjach bankowych Account-to-Account.

Projekt integracji
Tłumaczyłem kontrakty bankowe na wspólny proces płatniczy oraz projektowałem mapowanie statusów, błędów i retry.
Produkcyjne adaptery bankowe
Implementowałem integracje m.in. ze Swedbankiem, National Bank of Greece, Boursorama i CBI oraz bankami z kolejnych rynków europejskich.
Bezpieczna komunikacja z bankami
Pracowałem z Mutual TLS, certyfikatami i ograniczeniami operacyjnymi licencjonowanego środowiska PSD2.

Wolumen transakcji opisuje skalę platformy, a nie przepustowość pojedynczego adaptera. Claim bezpieczeństwa ogranicza się do Mutual TLS i certyfikatów w komunikacji platforma–bank.

Kluczowe decyzje

Semantyka błędu jako część kontraktu domenowego.

Wspólny model musiał uprościć integrację bez zacierania różnicy między stanem do ponowienia, trwałą porażką i nieznanym rezultatem.

  1. 01

    Adapter dla każdego banku

    Każdy kontrakt zewnętrzny pozostaje odizolowany, udostępniając platformie jeden spójny proces.

  2. 02

    Jawne mapowanie statusów

    Odpowiedzi banku są tłumaczone na stany wewnętrzne bez tworzenia fałszywej pewności.

  3. 03

    Bezpieczny transport na granicy

    Mutual TLS i certyfikaty są częścią cyklu życia integracji, a nie dodatkiem na końcu.

  4. 04

    Kontrolowane retry i duplikaty

    Decyzja o ponowieniu wynika ze zwróconego stanu i chroni proces przed powtórzeniem operacji.

Model dostarczania

Powtarzalna ścieżka dla instytucji, które nigdy nie są identyczne.

  1. 01

    Interpretacja kontraktu banku

    Mapowanie procesu płatności, certyfikatów, statusów, błędów i przypadków bez jednoznacznej odpowiedzi.

  2. 02

    Implementacja i normalizacja

    Budowa adaptera i tłumaczenie jego zachowania na wspólny model płatności.

  3. 03

    Wzmocnienie ścieżek błędów

    Weryfikacja retry, duplikatów i niejednoznacznych stanów przed kontrolowanym wdrożeniem produkcyjnym.

Zweryfikowany zakres produkcyjny

Wiele europejskich integracji w jednym procesie płatniczym.

~2 lata
bezpośredniej pracy nad europejskimi integracjami bankowymi
Setki tysięcy / miesiąc
w skali całej platformy Account-to-Account

Nie deklaruję poprawy konwersji, opóźnienia ani skuteczności transakcji, ponieważ nie ma zweryfikowanej bazy porównawczej.

Czego to dowodzi

Odpowiedzialność integracyjna w regulowanej domenie finansowej.

Projekt pokazuje bezpieczne integracje zewnętrzne, jawne modelowanie błędów i umiejętność zamiany wielu kontraktów instytucji w jeden operowalny proces wewnętrzny.

Twoja granica integracji

Czy zewnętrzne API ujawnia ryzyko, którego model wewnętrzny nie może ukryć?

Możemy zmapować kontrakt, semantykę błędów i zabezpieczenia operacyjne potrzebne w regulowanej integracji.

Porozmawiajmy o integracji regulowanej

Wróć do realizacji