Metody służące do odświeżenia rachunków aktywną zgodą
GET /api/v2/bankaccount z parametrem RefreshActiveAccounts=true
Flaga RefreshActiveAccounts jest odpowiedzialna za synchronizację wszystkich kont użytkownika (w każdym banku) 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.
W rezultacie zwraca listę aktywnych rachunków
2. POST /api/v2/bank/{idType}/{idValue}/sync lub /api/v2/bank/{bankId}/sync
Wywołanie metody rozpoczyna synchronizację aktywnych rachunków (dla kont posiadających aktywny token) we wskazanym banku.
W rezultacie zwraca Identyfikator sesji, na podstawie którego można wywołać metodę sprawdzającą szczegóły wskazanej sesji.
GET /api/v2/bank/session/{sessionId} - szczegóły sesji plus pobrane dane
GET /api/v2/bank/session/{sessionId}/status - status sesji
GET /api/v2/bank/session/{sessionId}/stage/{stage}/status - status odpowiedniego stage w danej sesji
GET /api/v2/bank/session/{sessionId}/status/details - szczegóły sesji
Obsługa 3 scenariuszy we flow pobrania rachunku:
DEAUTHORIZED
Gdy klient wycofuję zgodę (usuwa consent, wywołuje metodę DELETE consent), w bazie dezaktywują się rachunki powiązane z daną zgodą (zmienia się flaga na isActive = 0) -> nie wyświetlamy rachunku z taką flagą
2. EXPIRED
Gdy wygaśnie dany consent, status takiej zgody jest ustawiony na Inactive, a jako powód zmiany takiego statusu - InvalidationReason = Expired (patrz przykład)
3. ERROR
Gdy wystąpi błąd przy pobieraniu rachunków lub transakcji
a) Każde konto posiada osobny syncStatus w bazie. Jeśli syncStatus = Failed, to znaczy że nie udało się pobrać szczegółów danego konta.
b) Każde konto posiada osobny status
transactionSyncStatus : (Completed – historia aktualna Failed – dla wszystkich enpointów jest błąd PartiallyFailed – dla chociażby jednego enpointu jest błąd inProgress - trwa pobieranie historii) transactionSyncDate: - data ostatniej udanej synchronizacji transakcji |
c) Jeśli wystąpi błąd podczas synchronizacji danych (czy to rachunków, czy balansów, czy transakcji) ustawiany zostaje status "syncError" (na rachunku) który posiada informacje:
"syncError": { |
Gdy rachunek przestaje przychodzić z ASPSP ustawiany jest syncStatus = Failed oraz syncError.errorType=missingAccount
d) Wartość w API „consentStatus”, „LastSessionSattus”, sekcja „LastSession” , „isActive” zostają ale zostaną oznaczone jako obsolete
ZMIANY w API (przykład)
Struktura odpowiedzi API:
"consent": { //sekcja dla pkt.2 |
Jeżeli w sesji pobierzemy rachunki, ale nie pobierzemy transakcji to ustawiamy syncStatus (na koncie) jako active -> data LastSyncDate się zmieni.
Jeżeli w sesji pobierzemy rachunki, ale będzie błąd na 1 koncie z 3 to ustawiamy status konta (syncStatus na koncie) jako failed -> data LastSyncDate się nie zmieni
Ustawienia dat podczas synchronizacji:
Pełna synchronizacja danych (>90 dni w tył) wymusza silne uwierzytelnienie użytkownika – czyli przeprowadzenie SCA. Użycie metody do synchronizacji wszystkich danych w tył (max określony w zgodzie – czyli nawet 1460 dni) wymagałby ponownego uwierzytelnienia użytkownika.
Istnieje możliwość pobrania różnego zakresu danych z użyciem 2 flag: „SyncAllData" i „daysBack", w zależności, czy istnieją już pobrane wcześniej transakcje, co dokładniej opisane jest w tabelce.
Parametr „daysBack” - Brak
SCA - authorize → uzyskujemy accessToken i pobieramy transakcje (pierwsze pobranie zakresu zgodnie z zakresem zgody czyli :
"transactionDateFrom":"2018-06-01"
"transactionDateTo":"2020-06-01"
Ostatnia pobrana transakcja ma datę 2020-05-01 + 4 dni w czasie = 2020-04-27. Następnie wywołanie będzie z pageId z datami niżej:
"transactionDateFrom":"2020-04-27"
"transactionDateTo":"2020-06-01"
po SCA pobieramy całość transakcji. Ustawiamy wpierw daty jak wskazano czyli:
“transactionDateFrom":"2018-06-01"
"transactionDateTo":"2020-06-01"
i pobieramy kolejne strony, które przekazuje nam BANK, aż do końca, nie zmieniając filtrów datowych. Czyli każde pytanie o kolejną stronę (może być ich wiele) oprócz parametru w query pageId ma parametry z datami, ale są one stałe aż do ostatniej strony i są równe tym wyliczonym do 1 strony.
Następne pobranie danych zainicjowane przez metodę np. SYNC zacznie być wykonywane z parametrami:"transactionDateFrom":"2020-04-27"
"transactionDateTo":"2020-06-01"
Parametr „daysBack” - 365 dni
Bez SCA nie mamy prawa oraz bank nie udostępnia danych >90 dni. Dlatego przy odświeżaniu w tle pobierzemy:
"transactionDateFrom":"2020-03-01"
"transactionDateTo":"2020-06-01"
Jeżeli daysback >90 to i tak pobierzemy tylko 90 dni. Przy czym te daty mają znaczenie tylko wtedy, gdy po SCA nie było pobranych danych, bo jak są to pobieramy inkrementalnie (ostatnia transakcja -4 dni).
Q & A
Co oznacza zapis “MIN (X dni, 90 dni)”? Jeżeli jest zdefiniowany parametr X dni (daysBack) to czy go używamy, a w innym przypadku (np. daysBack=brak) bierzemy wartość “90 dni”?
MIN (X dni, 90 dni) wiąże się z zastosowaniem mniejszej wartości z dwóch podanych. Czyli dla daysBack 200 weźmiemy 90, a dla daysBack 20 weźmiemy 20.
Gdzie znajdziemy rozróżnienie dla transactionDate i bookingDate (czy to dwie różne daty)?
Każdy typ transakcji ma swoje daty główne. Przyjmujemy, że o transakcje 'done' odpytujemy tylko po transactiondate, żeby nie wprowadzać zbędnego zamieszania. Różne banki dla różnych typów chcą by pytać albo o booking albo transaction, dlatego tutaj mamy dopasowane daty do typów.
Czy majac kolejne strony transakcji jest sens, aby definiować daty do ASPSP? Może to spowodować, że przy pobieraniu nastepnej strony nastąpi pominiecie elementu w kontekście dat, gdyż nie bedzie on miescił się w danych przedziałach
Nie zmieniamy zakresu dat podczas zmieniania stron. Trzymamy filtr na datach, ale jest to pierwotny, najszerszy zakres jaki chcemy otrzymać, więc nie ma możliwości pominięcia żadnego wpisu.
Czy parametr „daysBack” o wartości “Brak” - oznacza dodawanie do ostatniej daty transakcji wspomnianych 4 dni w kontekście TrasactionDateFrom?
Tak, zawsze dodajemy 4 dni przy inkrementalności.
Odświeżanie transakcji HOLD, PENDING, SCHEDULED
Transakcje typu Hold, Pending, Scheduled posiadają ustawioną w konfiguracji flagę: DeleteIfNotFetched=true. Na jej podstawie sprawdzane jest, czy po otrzymaniu całej historii od ASPSP (maksymalny zakres czasu), transakcje tego typu powinny być kasowane, jeśli po odświeżeniu się nie pojawią.