Zgłoszenie | Opis zmiany | Wpływ na dokumentację standardową | Opis zmiany |
FIN-298 | [FOB-2705] Dodatkowy callback po pobraniu X elementów historii rachunku | Dokumentacja do sprintu dostępna na confluence | Użytkownik zgłosił potrzebę, by w ramach pobierania informacji z danego ASPSP zwracane były najmłodsze operacje, a potencjalny callback powinien powinien wykorzystywać paginacje/stronicowanie. W ramach dbania o spójność wersji 116 ustalone zostało, że procesowanie transakcji będzie odbywało się per strona, po pierwszej stronie przeprocesowanej pójdzie callback do banku ze szczegółowymi informacjami opisanymi w zgłoszeniu, szczegóły będą przeprocesowane po przeprocesowaniu wszystkich transakcji, a jako atrybut konta BUP doda liczbę transakcji przeprocesowanych na danym koncie. Analizowany był również fakt wysłania callbacka nie po pierwszej stronie, ale bardziej parametryzowanie w dwóch możliwych opcjach: wysyłanie callbacka co stronę do momentu uzyskania określonej parametryzowanym parametrem wartości (co przyczyni się do powstania kilku callbacków) lub jeden callback, po tym jak suma transakcji pobranych przekroczy jakąś ustaloną wartość. W callbacku wysyłane będzie również pole status, aby klient wiedział, z którego endpointu przychodzi ta konkretna pierwsza strona transakcji i mógł zareagować albo tylko na transakcje w statusie Done lub inne względem preferencji. Użytkownik poprosił o dodanie dodatkowych pól ("SessionExternalId", "Stage", "Status", "IsSca") w nowym callbacku. Dodatkowo dla pól "EarliestTransactionDate" i "LatestTransactionDate" następuje rozszerzenie o rozbicie na pola dotyczące księgowania i zlecania czyli LatestAccountingDate, LatestEffectiveDate, EarliestAccountingDate, EarliestEffectiveDate. Rozwiązanie zostało zawarte w paczce 116. Podobny problem omawiany był w FIN-299. |
FIN-296 | [FOB-2685] Elegenckie rozwiązanie pobieranie historii rachunków | Czeka na wycenę i realizację. | Zmiany jakie zostały zakomunikowane przez bank:
Dla klienta kluczowe jest:
Użytkownik poprosił o dodanie syncTransactionToDate celem poznania całego przedziału filtra, jaki procesuje dany batch (np. będziemy wiedzieć, że teraz leci pytanie o daty od 7 dni do 14 dni wstecz). Użytkownik poprosił również o zapewnienie, żeby był w posiadaniu informację (pewnie w liście rachunków o jak ą zapytamy po odebraniu callbacka) o tym, ile elementów operacji dla każdego z rachunków rezyduje w cache. To pozwala ocenić klientowi usług, czy już może sięgać po nie czy nie ma to sensu (bo są np. dwie). Kwestia tego, w której paczce będzie rozwiązanie dostarczone jest w tym zgłoszeniu dalej dyskutowane, a zgłoszenie znajduje się w fazie wyceny. |
FIN-295 | [FOB-2676] Zmiana w response dla metody BankAccount | Zmieniony został format odpowiedzi dla metody API: Rozszerzenie odpowiedzi dla metody BankAccount - dodanie pól
Zaktualizowany został swagger. | Użytkownik zgłosił potrzebę zmiany dla metody "BankAccount" (odpowiednik account-search na xs2a pobierającej szczegóły rachunków) w response w postaci dodania dodatkowych pól dla tej usługi odpowiadającym wartościom oryginalnym otrzymywanym z ASPSP:
Obecne przemapowanie wartości w polu "type" na słownik ("BankAccountType") pozostaje bez zmian (np."currentAccount"); Przykład zwracanych oryginalnych danych z ASPSP Alior: Przykład zwracanych oryginalnych z ASPSP Inteligo/PKO BP: Zmiana została zaimplementowana w wersji 116. |
FIN-279 | [PROD] Problem z pobieraniem transakcji na Aliorze | Brak wpływu na dokumentację. To tylko rozwiązanie tymczasowe do momentu poprawienia błędu po stronie ASPSP. Zaktualizowany został swagger. | Problem związany był z faktem braku walut wysyłanych przez Alior. BUP zaproponował workaround polegajacy na własnym mapowaniu walut na podstawie waluty konta (pole accountCurrencyCode (do obiektu Transactions)). Rozwiązanie zostało zaimplementowane w wersji 116. |
FIN-276 | [Wysoki] Rozszerzenie usługi /api/v2/bank/swiftCode/{swiftcode}/authorize o możliwość przekazania daty ważności zgody (scopeTimeLimit) | Dokumentacja do sprintu zawarta na confluence | Użytkownik zgłosił potrzebę rozszerzenia usługi /api/v2/bank/swiftCode/{swiftcode}/authorize o możliwość przekazania daty ważności zgody (scopeTimeLimit). Wedle jego uznania domyślnym zachowaniem powinno być automatyczne ustawianie ważności zgody tak jak to ma miejsce aktualnie. Rozwiązanie zaimplementowane jest w wersji 120. |
FIN-210 | Wielozgodowość / [QA] Weryfikacja liczby kont podpiętych w SCA | Dokumentacja zawiera opis zmiany, która umożliwia zwracanie listy IBAN'ów również dla kont dla których synchronizacja nie przebiegła pomyślnie Zaktualizowany został swagger. | Użytkownik zgłosił, że pojawia mu się inna liczba kont wybranych do podłączenia i faktycznie podłączonych. Problem polega na tym, że nie możemy zwracać wszystkich kont, gdyż zgodnie z założeniem zwracana jest liczba faktycznie przeprocesowanych rachunków z tabeli biznesowej (zonboardowanych w trakcie wykonywania SCA). Użytkownik chce byśmy pokazywali również konta ze statusem ERROR (czyli, gdy syncStatus będzie miał wartość failed dla określonego konta). Modyfikacja polegałaby na zwracaniu wszystkich IBANów w callbacku, w którym przekazywany jest status sesji - daje to listę przeprocesowanych IBANów, jak również zwracana jest lista wszystkich IBANów, nawet tych, dla których nasze API zwraca błąd. Rozwiązanie zostało dostarczone w paczce 115. |
FIN-200 | Informacja czy ASPSP wspiera wybór konta po stronie banku | Flaga IsAisForceAccount jest widoczna w dokumentacji swagger. | Użytkownik chce, by do kanału przekazywać informację, czy dany ASPSP wspiera wybór rachunku w trakcie SCA. Każdy bank wspiera scenariusz bez podawania rachunków w authorize (czyli wybór po stronie ASPSP), nie każdy wspiera podawanie ibanów w authorize. W ramach wersji 116 udostępniona została flaga IsAisForceAccount wraz z odpowiednimi wartościami dla banków polskich - false, w sytuacji, gdy nie można podać IBANów w authorize. |
FIN-198 | Rozszerzenie filtrowania transakcji o listę typów | W metodzie /api/v2/transaction dodano nowy filtr Status. Nowy filtr jest widoczny w dokumentacji swagger. | W ramach zgłoszenia użytkownik poprosił o możliwość wyświetlania transakcji w typie blokad oraz transakcji zaplanowanych (oprócz transakcji w statusie "Done"). Rozwiązanie zostało dostarczone w ramach paczki 113 i zostało wdrożone na obydwu środowiskach - DP i QA. |
| Wymiana z refresh-token na access-token | Mechanizm diagnozujący został opisany w dokumentacji do sprintu dostępnej na confluence | Zmiana obejmuje stworzenie mechanizmu diagnozującego podającego na wyjściu informację, czy refresh token został wymieniony na access token oraz wykonanie strzału sprawdzającego, czy udało się prawidłowo uruchomić wszystkie metody w ramach usługi AIS. W razie jakichkolwiek błędów na wyjściu podawana jest szczegółowa informacja na jakim etapie i co poszło nie tak. |
FIN-162 | TC dla unit testów | Metoda jest opisana w Swaggerze oraz pod poniższym linkiem: | Nowa metoda api/mock/session/callback, zwracająca na wyjściu to co zostało podane w BODY na wejściu. Dodane w ramach zmiany: |
FIN-159 | Nagłówek x-request-id w konektorze PKO BP powinien być wysyłany z wielkich liter | Żadne działanie nie jest wymagane, w związku z faktem anulowania zmiany | Zmiana została anulowana przez osobę zgłaszającą |
FIN-157 | [TPP] Klucz sekretny do Alior - prośba o dokonfigurowanie | Brak wpływu na dokumentację. Tylko parametryzacja ASPSP. Parametry konfigurujące ASPSP są opisane w Docker env file | Zmiana w konfiguracji w .pliku env - dodanie sekretnego klucza. |
FIN-154 | [TPP] [QA] Zmiana konfiguracji konektora PKO Inteligo | Brak wpływu na dokumentację. Tylko parametryzacja ASPSP. Parametry konfigurujące ASPSP są opisane w Docker env file | Zmiana w konfiguracji w .pliku env - dodanie parametru PkoBP_RedirectUri |
FIN-152 | Konfiguracja podpisu za pomocą usługi zewnętrznej | Konfigurowalne to jest poprzez docker compose. W wierszach: - BankConfig__PkoBP__SignatureConfig__Type= ${SignatureConfig_Type} - BankConfig__PkoBP__SignatureConfig__SigningAlgorithmConfig__ExternalConfig__HsmServiceUrl= ${ExternalSigning_HsmServiceUrl} - BankConfig__PkoBP__SignatureConfig__SigningAlgorithmConfig__ExternalConfig__HsmServiceKeyAlias= ${ExternalSigning_HsmServiceKeyAlias}
public class ExternalSigningConfig W ramach konfiguracji podajemy url i alias Konfigurowane są trzy parametry: KeyStoreType=external Jeden, który mówi, że mamy używać external usługi (HSM), a nie pliku | Zmiana związana z dodaniem obsługi HSM służącej do podpisu |
FIN-149 | Nadanie dostępu | Zmiana nie wymaga dokumentacji, gdyż jest to wewnętrzne działanie w Jira i confluence celem nadania dostępu | Konto zostało dodane z odpowiednimi uprawnieniami |
FIN-143 | [PARAMETRYZACJA] redirect URI | Brak wpływu na dokumentację. Tylko parametryzacja ASPSP. Parametry konfigurujące ASPSP są opisane w Docker env file | Zmiana redirect URI używanego dla PKO BP dla środowiska DP |
FIN-141 | wymaganie dla obsługi zgód (istotne przed wdrożeniem) | Szczegółowa dokumentacja dołączona do sprintu, dostępna na confluence | Wymaganie biznesowe omawiane na spotkaniu: "dane te muszą być pobrane z ASPS ponownie pod nowy cel przeznaczenia, czyli data pobrania danych musi być młodsza niż data wyrażenia wspomnianej wyżej zgody na przetwarzanie danych na potrzeby ofertowania" |
FIN-140 | Scope dla usługi TOKEN nie jest wymagany. Proszę zmienić na opcjonalny "scope": "ais", | Brak wpływu na dokumentację. Tylko parametryzacja ASPSP w zakresie konfiguracji zgody (purpose). | Zmiana obejmuje zdjęcie wymagalności "scope": "ais" dla usługi TOKEN, który powinien być opcjonalny. |
FIN-139 | Grupowa modyfikacja relacji do rachunku | Opisane to zostało w sekcji build 108 PSD2Hub w Planie wydań Zaktualizowany został swagger. | W ramach tego zgłoszenia pojawiła się prośba o możliwość modyfikowania w jednym komunikacie relacji klienta do wszystkich rachunków, jakie ma w danym banku - stworzony został nowy endpoint POST /api/v2/bankaccount (bez parametru accountId) - zmiana została dostarczona w wersji 108. |
FIN-138 | wymaganie opcjonalnych parametrów w odpowiedzi | Brak wpływu na dokumentację. | Zmiana obejmuje obsługę braku parametru nameAddress (pole jest obowiązkowe w PLAPI, przesyłane z pustą wartością przez PKOBP ASPSP). Zostało to dostarczone jako FIX do wersji 106. |
FIN-137 | Instalacja / Enrollment certyfikatem eIDAS | Brak wpływu na dokumentację. | Zgłoszenie zostało zamknięte bez potrzeby żadnej zmiany, a jedynie wyjaśnienie zgłaszającemu skąd powinien wziąć prawidłowy certyfikat |
FIN-134 | [TPP] [Podpis] Kod źródłowy biblioteki do podpisywania | Brak wpływu na dokumentację. | Zmiana zawiera sposób obsługi HSM po stronie BanqUP - od banku dostaliśmy pliki z biblioteki współdzielonej oraz kod źródłowy zastosowanego rozwiązania celem obsługi i konfiguracji po stronie TPP |
FIN-132 | [PODPIS] Instalacja certyfikatu TPP (testowy) w formacie x509 | Zgłoszenie zostało anulowane | Celem zgłoszenia było przetestowanie pod kątem rozbieżności względem Psd2Hub po stronie aplikacji w kwestii kodowania znaków końca linii |
FIN-131 | [FOB] [Q&A] Czas instalacji certyfiaktu testowego | Brak wpływu na dokumentację. | Zmiana polegająca na użyciu podpisu z wykorzystaniem HSMa została dostarczona |
FIN-130 | Prośba o dodanie "Other" do listy możliwych relacji klienta do rachunku | Brak wpływu na dokumentację. Zaktualizowany został swagger. | Dodane zostało słowo "Other" do listy możliwych relacji klienta do rachunku. Zmiana dostarczona została w wersji 106. |
FIN-129 | Prośba o rozszerzenie callbackow o secondary identifiers banku | Zmieniony został format odpowiedzi callback | W przypadku callbacku w kontekście tylko jednego banku, PSD2Hub zwracał identyfikator w kontekście, którego jest ten callback. Klient zażyczył sobie, by oprócz wewnętrznego identyfikatora była również kolekcja secondary identifiers, gdyż to one są informacją wartościową dla użytkowników API. Zmiana polega na dodawaniu secondaryIdentifiers dla banku oraz skasowanie niepotrzebnego, nieużywanego parametru BankId - dostarczono w wersji 108. |
FIN-128 | Endpointy które przyjmują wewnętrzny identyfikator banku a powinny SWIFTCODE | Opisane to zostało w Planie wydań, a nowe endpointy widoczne są w Swaggerze | Zmiana polega na tym, by dwie metody POST i DELETE (na endpointach: consent i bankaccount) przyjmowały swiftcode zamiast wewnętrznego identyfikatora banku - dostarczona pod koniec września 2019. |
FIN-125 | Callback data dla zlecenia synchronizacji konta | Zmieniony został format odpowiedzi callback | Użytkownik przy zlecaniu synchronizacji konta, nie może podać callback-data który byłby zwracany w callbackach. Zamiast tego dostaje identyfikator podany podczas authorize (externalSeasionID), a ten parametr po zakończeniu autoryzacji jest już dla niego bezużyteczny. Zmiana polega na daniu możliwości ustawienia właśnie tego callback-data (w postaci stringu) przy każdym zlecaniu synchronizacji konta, i która będzie mu zwracana w callbackach. |
FIN-121 | Raporty - w nawiązaniu do maila z dnia 30.07 raporty o statusie "gotowe" miały być dostępne na środowisku Finat? czy są dostępne i jeśli tak to gdzie - ścieżka dostępu? | Zmiana polegała na umieszczeniu w widokach danych, które pobierane są z bazy LDS i dostępne są poprzez SQL Mgmt Studio. Zmiana dostarczona została na wszystkie środowiska. | |
FIN-117 | [Q&A] Podłączenie drugiego konektora | Zmiana wymagałaby dodania nowego banku do konfiguracji - tak, by klient mógł wybrać który bank w danym momencie jest wołany. Dla nowego banku trzeba przygotować kopię plików konfiguracyjnych (w tym zmienić endpointy na inny sandbox). Zmiana finalnie nie została wykonana. | |
FIN-116 | Udostępnienie URL SCA na maszynie przesiadkowej | Brak wpływu na dokumentację. | W zasadzie nie chodzi tu o zmianę, a bardziej wytłumaczenie w jaki sposób przeprowadzić proces SCA z dokładnym wytłumaczeniem, jakie kroki należy podjąć i w jaki sposób można się zautentykować, by móc dokończyć testy na maszynie przesiadkowej |
FIN-114 | Callback Services Endpoints | Drobna zmiana konfiguracyjna ułatwiająca rozpoznawanie komunikatów będzie po stronie banku. Dodanie po http adresu callbacku na środowisku DP celem obserwacji, czy bank widzi dochodzące wywołania z PSD2Hub. | |
FIN-113 | Prośba o udostępnienie JIRA Service Desk: [email protected] | Zmiana nie wymaga dokumentacji, gdyż jest to wewnętrzne działanie w Jira i confluence celem nadania dostępu | Konto zostało dodane z odpowiednimi uprawnieniami do przestrzeni. |
FIN-112 | Tryby synchronizacji konta | Działanie flagi RefreshActiveAccounts zostało opisane w swaggerze w sekcji BankAccount w metodzie GET /api/v2/bankaccount | Żadna zmiana nie była konieczna, a jedynie wytłumaczenie użytkownikowi w jaki sposób zlecić synchronizację kont danego użytkownika. Padło pytanie o dwa scenariusze synchronizacji kont, czyli gdy aplikacja na początku działania zleca synchronizację wszystkich rachunków oraz gdy użytkownik w momencie gdy oczekuje na jakiś przelew zleca synchronizację tylko jednego rachunku. Flaga RefreshActiveAccounts jest odpowiedzialna za synchronizację kont i może przyjmować wartości true lub false. W przypadku wartości true asynchroniczna synchronizacja danych będzie wyzwolona w sytuacji gdy konto posiada poprawny token. |
FIN-111 | Jak zlecić synchronizację kont danego użytkownika? | Wątek zdublowany z FIN-112 | Wątek zdublowany z FIN-112 |
FIN-110 | Dostarczenie logów z sesji [96c64ff1-4faa-4a91-ab00-08d7111cb09f] | Brak wpływu na dokumentację. | Nie była wymagana żadna zmiana - był to błąd po stronie użytkownika polegający na wklejaniu zbyt wielu znaków w polu Code przy przechodzeniu SCA. |
FIN-109 | Typy transakcji (podatek, karta, walutowy, ZUS itd) | Dokumentacja zawiera informację o zwracanych typach transakcji: BankAccount-Transaction | Użytkownik chce by PSD2Hub zwracał w przypadku transakcji również ich typ. Uniwersalny słowników typów został opracowany przez bank i opiera się na zasadzie: Zwracane są dwie wartości typów transakcji: OriginalTransactionType (Pole z originalnym typem transakcji to "originalType") i TransactionType (Pole z mapowanym typem transakcji to "type") Rozwiązanie dostarczone w wydaniu 106. |
FIN-108 | Prośba o potwierdzenie zmian związanych z PURPOSE | Zgłoszenie zamknięte na prośbę osoby zgłaszającej | Zgłoszenie zamknięte na prośbę osoby zgłaszającej |
FIN-107 | Jak usunąć tylko cześć access tokenów które dostaliśmy od ASPSP? | Nowy endpoint dostępny jest w swaggerze | Użytkownik chce mieć możliwość anulowania tokenu w sytuacji, gdy np.: rozpoczyna kolejną sesję SCA na drugim kanale i pierwsze SCA ma zostać anulowane. Metoda pozwalająca na usunięcie zgody na podstawie consentId została przekazana w paczce 108. |
FIN-106 | callback o tym że pomimo SCA nie udało się uzyskać access tokenu | Dokumentacja zawarta jest na Confluence: Consent management | Użytkownik chce być informowany odpowiednim callbackiem o braku uzyskania access tokenu (na skutek np.: porzucenia SCA, błędnych danych, braku wymiany code na access token, czy odrzuconego kodu autoryzacyjnego) w sytuacji gdy klient przeszedł SCA. Rozwiązanie już istniało w momencie utworzenia zgłoszenia, więc nie było potrzeby tworzenia change. Przekazywane w callbacku wartości z ASPSP są przekształcane w wartości stage i status sesji w odpowiedniej tabeli w bazie danych. Wartość statusu failed w stage'u authentication oznacza, że autentykacja się nie powiodła. |
FIN-105 | Callback, rozpoznawanie że lista kont jest po SCA | Został poruszony wątek podobny do FIN-106. Rozwiązanie zostało dostarczone w wydaniu 106. | |
FIN-104 | Konfiguracja konektora PKO INTELIGO | Brak wpływu na dokumentację. | Nie był to change, lecz zapytanie, czy konfiguracja konektora PKO Inteligo jest poprawna. |
FIN-103 | API_CLIENT_ID | Brak wpływu na dokumentację. | W ramach zgłoszenia do zrealizowania były założenie 5 nowych api-clientId oraz weryfikacja scenariusza, kiedy użytkownik rozpoczyna autoryzację przy pomocy jednego api-clientId i przychodzi zwrotka z banku niewskazująca na to, z którego kanału autoryzacja została rozpoczęta. Weryfikacja wyszła pomyślnie, a założenie nowych api-client zostało uzupełnione zapytaniem sql. |
FIN-102 FIN- 196 FIN- 184 | Dokumentacja do stanów kont | Dokładny opis omówionych zagadnień znajduje się w poniższych linkach: | W ramach zgłoszenia użytkownikowi zostało przekazane w jaki sposób rozumieć parametry określające status konta: consentStatus (flaga informująca o (nie)aktywności zgody), syncStatus (wartość nieużywana odkąd stworzony został obiekt LastSession przekazujący informacje o ostatniej sesji), lastSession (zwracany tu jest obiekt informujący o ostatniej sesji) i isActive (wartość determinująca widoczność konta w zależności od statusu zgody) oraz statusy i stage sesji. Kompleksowe rozwiązanie ustawiające między innymi, odpowiednią właściwość flagi isActive zależnie od statusu zgody, jak również zmiana pól SyncStatus w zależności od statusu synchronizacji danych konta, czy ustawianie wartości transactionSyncStatus zostało dostarczone w ramach wydania 114. W ramach zgłoszenia uruchomiony został skrypt SQL dezaktywujący zgodę dla określonego użytkownika. |
FIN-101 | Zmiana konfiguracji DNS (edycja pliku etc/hosts) | Dokumentacja nie jest potrzebna, gdyż jest to rozwiązanie tymczasowe. | W ramach zgłoszenia użytkownik poprosił o zmianę w pliku hosts, by rozwiązać problemy z rozwiązywaniem nazw DNS w Finat. |
FIN-100 | prośba przykład wywołania nowego endpointu do zakończenia authentykacji | Na Swaggerze znajduje się opis tego endpointu | Użytkownik poprosił o przykład wywołania endpointu kończącego autentykację, przyjmującego cały URL oraz payload. W wydaniu 105 rozwiązanie zostało dostarczone. |
FIN-99 | Filtrowanie transakcji bo absolutnej wartości | W metodzie /api/v2/transaction dodano nowy filtr AmountsAbsolute. Nowy filtr jest widoczny w dokumentacji swagger. | Użytkownik poprosił o realizację zmiany umożliwiającej klientowi w ramach jednego strzału uzyskać informację o wszystkich transakcjach na kwotę nie mniejszą niż 100zl, a większą niż 50zł. Zmiana pola AmountAbsolute w filtrach została wdrożona w wersji 106. |
FIN-98 | Transaction search - not case sensitive | Brak potrzeby uzupełnienia dokumentacji, gdyż nie jest to zmiana | Użytkownik zgłosił potrzebę, aby w transaction search parametr status oraz CurrencyCode nie były case sensitive. Nie było potrzeby zmiany, gdyż słowniki, w szczególności przy przekazywaniu wartości słownikowych do filtrów nie są case sensitive. |
FIN-96 | [Q&A] Specyfikacja nagłówków HTTP - zależności konfiguracyjne Banków | Brak potrzeby uzupełnienia dokumentacji, gdyż nie jest to zmiana | Użytkownik w ramach konfiguracji API GATEWAY, prosi o przygotowanie informacji, jakie nagłówki są wymagane, opcjonalne etc. u konkretnych ASPSP. Odpowiedź udzielona została w zgłoszeniu, bez potrzeby tworzenia change. |
FIN-88 | Po której dacie jest filtracja w /api/transaction ? | W metodzie /api/v2/transaction dodano nowy filtr EffectiveDateTo/EffectiveDateFrom. Nowy filtr jest widoczny w dokumentacji swagger. | W Polish API każda transakcja ma dwie daty, a niektóre mogą mieć nawet 4. Endpoint do pobierania transakcji przyjmuje tylko "date" do filtracji, Użytkownik zadał pytanie, która z dat jest tam używana (bookingDate) i kiedy będzie możliwość filtrowania po pozostałych. BUP został poproszony o zaplanowanie rozszerzenie filtra o możliwość podania po której dacie ma być filtracja. Zmiana została dodana do wersji 108. |
FIN-86 | Flaga uznania/obciążenia | Nowe pole widoczne w swaggerze. | Użytkownik zgłosił potrzebę, by dla Get Transaction zwracać flaga uznania/obciążenia. W ramach zmiany zostaje przekazywana flaga creditOrDebit dla transakcji. Zmiana zrealizowana została w ramach wydania 105. |
FIN-85 | PsuRelations - opisanie + zwracane wartości | Dokumentacja PolishApi opisuje to zagadnienie. Opis dostępnych wartości znajduje się również w swaggerze. | Użytkownik zgłosił prośbę o opisanie (biznesowe) czym jest pole PsuRelations oraz jakie wartości będą zwracane w ramach tych pól. |
FIN-84 | [showstopper] Niepoprawny URI callback autoryzacji w środowisku testowym DP Finat | Brak wpływu na dokumentację. | Potrzebna była poprawka zmieniająca adres url wysyłany w callbacku z BanqWareowego na adres podany przez bank |
FIN-81 | BankAccountType mapping - dodanie wartości słownika PKO | Uzupełnienie mapowań dla pola Type. |
Lista zmian (CR)
Written by Maxime
Updated over 4 months ago