Obsługa 3 scenariuszy we flow pobrania rachunku - FIN-102, FIN-196, FIN-184
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ą
STATUS: Zrobione, dostarczone
EXPIRED
Gdy wygaśnie dany consent, będzie ustawiany status takiej zgody na Invalid (inactive), a jako powód zmiany takiego statusu ustawiony będzie InvalidationReason = Expired (patrz przykład)
ERROR
Gdy wystąpi błąd przy pobieraniu rachunków lub transakcji
Każde konto będzie posiadało swój osobny syncStatus w bazie, a nie jak jest obecnie to ustawione na poziomie całej sesji. Jeśli syncStatus = Failed, to znaczy że nie udało się pobrać szczegółów danego konta.
Każde konto będzie również posiadało osobny status
transactionSyncStatus : |
Jeśli wystąpi błąd podczas synchronizacji danych (czy to rachunków, czy balansów, czy transakcji) będzie ustawiany status syncError (na rachunku) który będzie posiadał informacje takie jak:
"syncError ": { |
Gdy rachunek przestaje przychodzić z ASPSP ustawiany jest syncStatus = Failed oraz syncError.errorType=missingAccount
Wartość w API „consentStatus", „LastSessionSattus", sekcja „LastSession" , „isActive" zostają ale zostaną oznaczone jako obsolete
ZMIANY w API (przykład)
"consentStatus": "invalid", //wartość obsolete pkt. 6
"consent": { //nowa sekcja dla pkt.2
"externalId": null,
"id": "844c066d-6a5f-48ce-bd4b-5fa4a8ef3e4d",
"status": "invalid",
"invalidationReason": "expired",
},
"currencyCode": "PLN",
"errorMessage": null,
"externalConsents": [
{
"consentId": "844c066d-6a5f-48ce-bd4b-5fa4a8ef3e4d",
"externalConsentId": null,
"purposes": [
"ais-polish-api-fallback"
]
}
],
"generateNotifications": false,
"hasImage": false,
"holderInfo": "GERALD KULA ul. Zaolziańska 37 93-535 Łódź Polska",
"holderType": "individual",
"iban": " PL61 0001 2345 0000 0000 0904 0575",
"id": 618,
"importDate": "2019-11-19T10:42:54.4839472",
"isActive": true, //obsolete
"isBusiness": false,
"lastSession": { //wartość obsolete pkt. 6
"consent": {
"externalId": null,
"id": "844c066d-6a5f-48ce-bd4b-5fa4a8ef3e4d",
"status": "confirmed"
},
"id": "75e1ceb6-b83e-423c-6b0a-08d76cd803a4",
"stage": "transactionDetails",
"status": "finished",
"syncDate": "2019-11-19T10:39:35.9214904"
},
"lastSessionStatus": "finished", //wartość obsolete
"lastSyncDate": "2019-11-19T10:39:35.9214904",
"lastTransactionDate": "2019-11-08T00:00:00",
"lastTransactionSyncDate": "2019-11-08T00:00:00",
"manualRelation": null,
"providerType": "api",
"relations": null,
"retrievedName": null,
"secondaryIdentifiers": [],
" syncError ": { //nowa sekcja dla pkt.4
"errorType": "missing account",
"aspspResponses":[{
"status": false,
"content": "message z ASPSPS",
"resource": "/token"
}],
"message": "Cannot deserialize ASPSP response."
},
"syncOffline": true,
"syncStatus": "active", //status synchronizacji konkretnego konta i jego salda - 3a,
"transactionSyncStatus": "active", //dodatkowy status -3b
"type": "currentAccount",
"typeName": "ROR",
"userName": "GERALD KULA ul. Zaolziańska 37 93-535 Łódź Polska"
Data dostarczenia: po sprincie 114 (termin: 19.12) (rozpoczęcie w 113)
Obsługa transakcji typu HOLD
Mechanizm
Dla banku PKO nie pobieramy szczegółów dla transakcji typu Hold
Użycie w konfiguracji flagi: DeleteIfNotFetched spowoduje, że sprawdzana będzie cała historia otrzymywana z ASPSP (maksymalny zakres czasu) i obciążenia powinny być kasowane, jeśli się nie pojawią
Odświeżenie danych (wszystkich w celu otagowania nową zgodą) – FIN-141
Mechanizm: 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.
Naszą propozycją jest dodanie 2 flag: „SyncAllData" i „daysBack". W zależności od nich (i warunku czy są transakcje czy nie) będziemy pobierać transakcje zgodnie z tabelką.
Warunki | METODY | ||||
Flaga „SyncAllData" | Parametr „daysBack" | Istnieją transakcje na koncie | /sync | /authorize | /?refreshactiveaccounts=true |
False lub brak | brak | nie | 90 dni | 1460 dni (w zależności ile pozwala bank) | 90 dni |
False lub brak | brak | tak | inkrementalnie | inkrementalnie | inkrementalnie |
False lub brak | X dni | nie | MIN (X dni, 90 dni) | MIN (X dni, 1460 dni) | NA |
False lub brak | X dni | tak | MIN( X dni, ilość dni od najnowszej transakcji,90 dni) | MIN( X dni, ilość dni od najnowszej transakcji, 1460 dni) | NA |
True | brak | NA | 90 dni | 1460 dni (w zależności ile pozwala bank) | NA |
True | X dni | NA | MIN (X dni, 90 dni) | MIN (X dni, 1460 dni) | NA |