Pekao Connect

Integracja z bankiem została zaprojektowana jako proces stanowy. Operator nie wysyła przelewu w ciemno i nie musi potem ręcznie zgadywać, czy bank go przyjął, odrzucił albo zaksięgował. ExKSeF zapisuje płatność, nadaje jej bezpieczny stan, przepuszcza przez strażników wysyłki, wysyła do Pekao Connect i dopiero po danych z banku zamyka rozliczenie.

Najważniejsza decyzja projektowa jest celowo konserwatywna: status z banku pain.002 może powiedzieć, że zlecenie jest zaksięgowane, ale system nie oznacza wtedy płatności jako opłaconej. Taki zapis trafia do statusu Zrealizowana w banku, a status Opłacona pojawia się dopiero po debecie z historii rachunku camt.052. Dzięki temu płatność ma datę księgowania i techniczne dane transakcji potrzebne do potwierdzeń oraz audytu.

Co obsługuje moduł

• wysyłkę płatności z kolejki bankowej przez operację DomesticTransfer,

• odpytywanie statusów zleceń przez GetPaymentStatusReport i mapowanie kodów pain.002,

• pobieranie historii rachunku camt.052 i dopasowanie debetów do płatności,

• dopasowanie wpłat do wystawionych faktur sprzedażowych,

• kolejkę ręcznego wiązania, gdy transakcja nie daje się przypisać jednoznacznie,

• pobieranie potwierdzeń PDF dopiero po przechwyceniu TxId z camt.052,

• pobieranie wyciągów MT940 i PDF używane w obszarze O->M i Export Magik,

• audyt komunikatów SOAP, błędów i przebiegów schedulerów.

Statusy w tym obszarze nie są tylko etykietami na liście. Każdy z nich określa, czy płatność może być edytowana, wycofana, wysłana, sprawdzona w banku albo domknięta przez historię rachunku.

Statusy przed wysyłką

• Robocza to szkic płatności ręcznej albo przygotowanej do zatwierdzenia. Nie trafia automatycznie do banku.

• Gotowa do eksportu oznacza klasyczną ścieżkę pliku przelewów, używaną gdy Pekao Connect nie prowadzi kolejki online.

• W kolejce do banku oznacza płatność czekającą na wysyłkę przez Pekao Connect. Ręczny eksport pliku może ją jeszcze zabrać z kolejki i przełączyć na eksportowaną.

• Wstrzymana - korekta chroni przed przepłaceniem dostawcy, gdy są nierozliczone korekty dla tego samego sprzedawcy.

Statusy po kontakcie z bankiem

• Wysłana do banku powstaje po przyjęciu zlecenia w trybie bezpośredniej realizacji.

• Oczekuje autoryzacji powstaje, gdy przelew został przekazany do banku, ale wymaga autoryzacji po stronie bankowości.

• Odrzucona przez bank jest statusem finalnym dla zlecenia odrzuconego przy wysyłce albo wykrytego później jako RJCT.

• Zrealizowana w banku oznacza, że pain.002 zwrócił zaksięgowanie, ale aplikacja nie ma jeszcze debetu z camt.052.

• Opłacona jest ustawiana dopiero po dopasowaniu debetu z historii rachunku. To jest mocny stan rozliczeniowy, bo zawiera ślad transakcji bankowej.

Takie rozdzielenie jest ważne operacyjnie. Bankowy status zlecenia odpowiada na pytanie, co bank wie o komunikacie. Historia rachunku odpowiada na pytanie, co faktycznie przeszło przez konto firmy.

Ta sama logika dopuszczenia jest używana przy wysyłce online i przy generowaniu pliku przelewów. Dzięki temu operator nie dostaje dwóch różnych odpowiedzi w zależności od kanału, którym próbuje wysłać płatność.

Co jest sprawdzane przed wysyłką

• Rachunek odbiorcy musi być poprawnym numerem NRB.

• MPP wymaga dodatniej kwoty VAT i NIP-u odbiorcy, bo tytuł przelewu jest wtedy budowany strukturalnie.

• Biała lista VAT jest sprawdzana dla faktur, not księgowych i not odsetkowych, chyba że kontrahent ma świadomie wyłączoną weryfikację.

• TransferSignature jest nadawany przed wysyłką i staje się EndToEndId, czyli kluczem idempotencji oraz późniejszego dopasowania.

Jeżeli strażnik wykryje problem, płatność nie znika i nie dostaje fałszywego statusu. Zostaje w kolejce, a opis problemu trafia do wyniku przebiegu. Jeżeli błąd dotyczy transportu albo chwilowej awarii banku, status również nie jest zmieniany, żeby kolejny cykl schedulera mógł ponowić próbę.

Joby Pekao Connect są seedowane tylko wtedy, gdy integracja jest włączona w konfiguracji. Startują jako wyłączone, więc operator świadomie decyduje, kiedy proces bankowy ma zacząć działać cyklicznie. Harmonogram i odbiorców powiadomień ustawia się w administracji.

Wysyłka płatności do banku

Pekao Connect - Wysyłka płatności do banku działa domyślnie co 5 minut po włączeniu. Czyta całą kolejkę W kolejce do banku, przeprowadza walidacje, wysyła przelewy przez DomesticTransfer i ustawia wynik: wysłane, oczekujące autoryzacji albo odrzucone. Powiadomienia e-mail lub SMS są wysyłane tylko przy problemach, czyli odrzuceniach, pominięciach lub błędach.

Statusy płatności

Pekao Connect - Statusy płatności działa domyślnie co 10 minut po włączeniu. Odpytuje pain.002 dla płatności wysłanych, oczekujących autoryzacji oraz zrealizowanych w banku bez debetu camt.052. RJCT przełącza płatność w Odrzucona przez bank. ACSC albo ACCC przełącza ją w Zrealizowana w banku, ale nie w Opłacona.

Synchronizacja transakcji

Pekao Connect - Synchronizacja transakcji działa domyślnie co 20 minut po włączeniu. Pobiera przyrostowy raport camt.052 przez GetIncrementalAccountReport z kursorem ostatniej transakcji. Debety domykają płatności wychodzące do statusu Opłacona, a kredyty rozliczają wystawione faktury sprzedażowe. Niedopasowane wpłaty mogą uruchomić powiadomienie, bo wymagają reakcji operatora.

Historia rachunku jest wspólnym źródłem prawdy dla płatności wychodzących i wpłat od klientów. Parser camt.052 dzieli transakcje na debety i kredyty, a matcher próbuje powiązać je z dokumentami na kilku poziomach pewności.

Debety płatności wychodzących

Najmocniejsze dopasowanie odbywa się po EndToEndId, czyli TransferSignature zapisanym na płatności. Gdy bank nie zwróci tego identyfikatora, system próbuje referencji bankowej, numeru dokumentu w tytule oraz jednoznacznego rachunku i kwoty. Dopiero pewne trafienie zapisuje transakcję bankową, datę księgowania i status Opłacona.

Kredyty faktur sprzedażowych

Wpłaty klientów są dopasowywane do wystawionych faktur sprzedażowych po numerze faktury, numerze proformy albo numerze KSeF. Idempotencja po referencji bankowej chroni przed podwójnym rozliczeniem tej samej wpłaty przy ponownym imporcie lub nakładających się oknach synchronizacji.

Kolejka ręczna

Transakcje, których nie da się dopasować jednoznacznie, trafiają do kolejki ręcznego wiązania tylko wtedy, gdy mają sensowny cel po stronie systemu. Filtry wykluczeń ograniczają szum, na przykład prowizje albo operacje techniczne, które nie powinny codziennie wracać do operatora.

Panel administracyjny Pekao Connect pokazuje rachunek firmy jako pole tylko do odczytu. Źródłem numeru NRB jest profil firmy, więc aplikacja nie utrzymuje drugiej, ryzykownej kopii rachunku bankowego w ustawieniach integracji.

Sekrety i tryby pracy

• hasło certyfikatu transportowego QWAC służy do mTLS,

• certyfikat autoryzacyjny PFX i hasło pojawiają się tylko w ścieżce podpisywania zleceń,

• puste pole sekretu przy zapisie zachowuje poprzednią wartość zamiast ją kasować,

• sekrety są szyfrowane mechanizmem DataProtection,

• test połączenia pobiera raport rachunku za ostatnie 7 dni i parsuje go tym samym parserem camt.052, którego używa import historii.

Adapter działa mock-first i live na tej samej ścieżce kodu. Różnice są w konfiguracji transportu, podpisie i mTLS, a nie w osobnym modelu domenowym.

Pekao Connect udostępnia także operacje pasywne. Aplikacja korzysta z nich dopiero wtedy, gdy ma dane pozwalające wysłać poprawne zapytanie, zamiast produkować błędy po stronie banku.

Potwierdzenie płatności PDF

Potwierdzenie pojedynczej płatności jest pobierane przez GetPaymentConfirmation. Bank nie szuka go po naszym EndToEndId, tylko po technicznym TxId z debetu camt.052. Dlatego przycisk pobrania ma sens dopiero po tym, gdy synchronizacja rachunku złapie faktyczną transakcję bankową i zapisze jej identyfikator.

Wyciągi MT940 i PDF

Wyciągi są pobierane jako pliki raportów. MT940 przechodzi przez sekwencję PrepareReport i GetDocument, a PDF przez GetStatement. Jeżeli bank generuje plik asynchronicznie, adapter odpytuje do gotowości i dopiero potem oddaje plik do dalszej wysyłki lub eksportu.

Pekao Connect dotyka realnych pieniędzy, więc jest spięty z rolami i audytem. Konfiguracja bankowa wymaga uprawnienia administracyjnego, wysyłka do banku, odświeżanie statusów, import historii i pobieranie potwierdzeń są osobnymi funkcjami roli. Dzięki temu użytkownik może widzieć płatności, ale nie musi mieć prawa do ich wysyłki.

Każda wymiana SOAP jest utrwalana w audycie komunikatów, razem z operacją, referencją, statusem HTTP, błędem i czasem trwania. Błędy zewnętrzne, takie jak timeout czy chwilowy problem bramki, nie są mieszane z błędami domenowymi. Scheduler może ponowić przebieg, a operator widzi, czy problem dotyczy danych płatności, konfiguracji, banku czy ręcznego dopasowania.

To pokazuje ważną cechę projektu: integracja bankowa nie jest dodatkiem do tabeli płatności, tylko pełnym procesem z walidacją, idempotencją, retry, audytem, uprawnieniami i czytelną historią dla operatora.