Help
Troubleshooting
The /authorize URL shows a text message instead of the login form
This happens when the client_id or redirect_uri in the /authorize URL is not registered with the bank. The message will indicate which parameter needs to be corrected — for example: "mismatching redirection URI for given client". This error can occur even after a successful integration setup, e.g. if you update your redirect_uri in online banking but forget to update it in your system's configuration.
The /authorize URL redirects to your redirect_uri instead of showing the login form
This occurs when response_type, scope, or other request parameters are incorrect. The redirect_uri will include state, error, and error_description parameters. The latter two explain the cause. The specification defines these values strictly, so this error is unlikely if the integration is set up correctly.
Clicking 'Sign in' on the login form redirects to a password change page instead of your redirect_uri
This means the user's password has expired. Set a new password — it will remain valid for 365 days. You can do this in online banking.
The /token request returns HTTP 400 with error code invalid_request
Possible causes: - The Authorization Code has already been used. If you are not using a refresh_token, you need to generate a new Authorization Code for each /token request. - The code_challenge in /authorize and the code_verifier in the /token request do not match. See
"Obtaining Tokens via Code Flow"
for the correct algorithm. - The redirect_uri value is not registered with the bank, or does not match the value used in the /authorize request. - The request body is missing required parameters.
The /token request returns HTTP 401
Possible causes: - The Authorization header is malformed. It must start with Basic and contain client_id and client_secret joined by a colon and encoded with Base64URL. - The client_id or client_secret used in the Authorization header is not registered with the bank.
The accounts request returns HTTP 401
Possible causes: - The Authorization or ID-Token header is missing; - The Authorization header value does not start with Bearer; - The user has issued a new set of tokens or called /logout, which invalidates the previous token set; - The access tokens have expired.
Scheduling Automatic Statement Retrieval
Final statements for business days become available the next day after 4:00 AM Moscow time. Saturday statements may appear later.
For automatic retrieval, we recommend:
Schedule your first daily request for after 6:00 AM Moscow time, and skip Sundays. Request Saturday's statement on Monday instead.
If you need statements on Sundays, set the first request for after 2:00 PM Moscow time.