Frequently asked questions

Here are the Login API Frequently Asked Questions (FAQ). See the Login API for all the technical details.

For general information and questions, please check in the Knowledge base.

Why does Login fail for my sales unit?

Make sure that your test sales unit is set up for using login. See How to set up login on your sales unit.

Where do I find the client_id and client_secret?

See: Knowledge base: API Keys.

How can I activate and set up Login?

You can activate Login on portal.vippsmobilepay.com. See How to set up login on your sales unit.

Can I initiate payments using a Login sales unit?

If you ordered a sales unit specifically for Login, you won't be able to complete payments with this. It's also not possible to add a payment solution to this sales unit later on. However, you can set up Login for all ecom sales units in order to handle both Login and payments from the same sales unit. So if your intention is to do so, please order an ecom sales unit and activate Login afterwards on portal.vippsmobilepay.com. See How to set up login on your sales unit.

What are the requirements for redirect URIs?

We validate redirect URIs used against a whitelist of pre-approved URIs. The URIs must be registered by the merchant on portal.vippsmobilepay.com as described in How to set up login on your sales unit.

You can register as many URIs as you want. Specify the URI that will be used with the query parameter, redirect_uri, on the initial request to the authentication endpoint.

For app URIs, we recommend using universal links (Apple)/asset links (Android) instead of custom URL schemes for better security.

Please note:

• The redirect URI cannot contain #.
• You can use localhost as part of the redirect URI.
• We recommend using universal links (Apple)/asset links (Android) instead of custom URL schemes for better security (example: "https://example.com/app/callback").

What are the requirements for app callback URIs?

The app_callback_uri should be a URI that makes the device switch back to the merchant's app again after the Vipps/MobilePay app portion of the flow is done (example: "https://example.com/app/callback").

For app URIs, we recommend using universal links (Apple)/asset links (Android) instead of custom URL schemes for better security.

How can I use client_secret_post for authentication?

It is possible to change the token endpoint authentication method on portal.vippsmobilepay.com. This setting will then apply to all login transactions on this sales unit.

Under the Developer section you will find the Setup Login option for your sales units.

Here you have the option to change the token endpoint authentication method, and see which method is currently active:

Why do I get invalid_client?

This means that the specified client_id and client_secret are not valid for Login.

Please check:

• Have you activated Login and set up a redirect URI? See: How to set up login on your sales unit?.
• Have you double-checked that the redirect_uri used in the API call is exactly the same as the one specified on portal.vippsmobilepay.com?
• Pay extra attention to whether the URI used in the API request has a trailing / or URL-encoded entities (like %20), and whether the URI added on portal.vippsmobilepay.com is an exact match.
• Are you using the client_id and client_secret for the correct environment? There are separate API keys for test and production. See: Knowledge base: API Keys.

Why do I get invalid_grant?

The most common reason is that the authorization code has expired. The code is short-lived, so it will only be valid for a couple of minutes.

From RFC 6749:

The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.

If you first make one request, and then repeat the same request, you will get this error.

Why do I get invalid_request?

The most common reason is that the redirect_uri sent in the API request is not identical to one of the URIs registered by the merchant on portal.vippsmobilepay.com.

The redirect_uri must be an exact match, meaning capitalization, query string, etc. It must be 100 % identical.

Please check that you are including the necessary required parameters in the API request.

Which scopes can I use? Why do I get invalid_scope?

If you get Invalid_scope this means that you have included one or more scopes that you do not have access to or that is not supported. See: Scopes.

All merchants have access to these scopes:

• openid
• address
• birthdate
• email
• name
• phoneNumber

Important: You should never ask for more scopes than you need for your application. The user will need to consent to sharing the information with you so adding more scopes increases the chance that they will decline.

The scope openid is required and does not require user consent. It provides the claim sub which is a unique ID for the end user at that particular merchant.

Please note: Different sales units will get different subs for the same end user.

Some merchants can get access to National Identity Number (NIN) with the nin scope. Merchants need to request this separately. See Who can get access to NIN and how?.

You can find the list of scopes that your individual sales units have access to in portal.vippsmobilepay.com under the Developer section and the Set-up Login panel.

Why do I get Error: Could not get Login token” in Vipps?

You can get this error if you have both our test app and production app on the same phone.

What is the sub?

See: Userinfo API FAQ: What is the sub for this and more information about the sub.

How can I get updated information, like addresses, for a user?

When the user consents to sharing information with the merchant, the merchant has ~10 minutes to retrieve the information. The information can be retrieved every time the user logs in. The merchant must save this information and handle everything according to GDPR.

Why can I get userinfo after the user has revoked consent?

During a login or a payment session, the user consents to share information if requested by the merchant. The user's information is then available for the merchant from the userinfo endpoint. For login sessions, user information is available for the ongoing login session.

To better support merchants that do not handle online fetching and processing of the user info as part of a payment session, we keep this information accessible for the merchant for the next 168 hours, even though the user revokes the consent in this period. Revoking consents will immediately affect future login and payment sessions.

See: Userinfo API.

Can a user less than 15 years old use Login?

No, Login requires a full Vipps or MobilePay profile. Users below the age of 15 can not use Login.

Who can get access to NIN and how?

info

Access to the nin scope and the National Identity Number (NIN) is a paid service.

Only merchants with legal requirements or other objective needs for using the NIN to achieve the required user identification can get access to NIN. We comply with local applicable laws as well as guidance from the Norwegian Data Protection Authority, Datatilsynet, and other relevant local authorities.

As an independent controller, the merchant shall assess whether they are entitled to receive NIN. It must be noted that the legal liability regarding receiving and processing NIN solely resides with the Merchant. However, it's within Vipps MobilePay's own discretion to decide if merchant's requests meet the criteria stated above.

Keeping a unique and consistent identifier for the user over time is not a sufficient requirement. For this purpose, we offer a unique merchant specific user identifier that is delivered as part of the registration/login. This is the claim sub that is delivered based on the openid scope. This unique identifier will allow you to keep a consistent user profile even if the user changes contact information.

Be aware that Login is not an electronic ID. Thus, the NIN can only be used to simplify the customer processes by removing manual input or to look up the customer in your own or external registers. This can be done as part of the process to become a customer or to link login with Vipps MobilePay to an existing user. If you need to store the NIN for new users, we recommend that you use an electronic ID.

Merchants need to apply for access to NIN by sending an email to accessuserinfo@vippsmobilepay.com. In the email you must share:

• Organization number
• Merchant name
• Name and number of the sales unit from portal.vippsmobilepay.com
• Detailed information on how you plan to use the NIN
• If the request is based on the objective need; explanation of why the purpose can be only achieved with NIN
• Any supportive documents such as user terms, process flows etc.
• If the request is based on the legal requirement, direct reference to the legal text and guidelines, if any.

Who can get access to Login from phone number and how?

Login from phone number is available for all Login enabled clients.

Login from phone number is a paid service.

Remember that Login from phone number has been developed to support use cases where authentication/registration does not start in a browser or an app. This means that it is the merchant that triggers the authentication/registration (either manually or automatically) and thus the log-in cannot be done in the user’s browser.

Login from phone number is reserved for such special cases. If a merchant uses this incorrectly on webpages or in apps used by end users (on their own device), access to the feature can be withdrawn.

Merchants need to apply for access to Login from phone number by sending an email to accessuserinfo@vippsmobilepay.com. In the email you must specify:

• Recipient name
• Recipient email
• Invoicing address

How can I get started with marketing consents?

See Marketing consents.

What's the purpose of the state parameter?

The state parameter is an opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter should be used for preventing cross-site request forgery. It must be at least 8 characters long to ensure sufficient entropy. A GUID is a good choice for a state parameter value.

Can I use partner keys for Login?

Yes, partner keys can be used for both Login in Browser and Login from Phone number. Be aware that the partner key integration differs slightly from a regular merchant integration.

Login supports some scenarios where a merchant can be used for registration and log in to other sites/merchants. Specific terms and conditions related to UX/branding, consent, terms, and privacy statement apply to such scenarios.

Can I control if a user is remembered in the browser (set up as 2FA)?

No. Login does not support merchants specifying that the user needs to use the app to authenticate (two-factor authentication - 2FA). The end user chooses whether or not to be remembered in browser. This is seen as a key feature of the service.

How is GDPR handled with Login?

With regard to the processing of personal data and GDPR, the following applies to Login:

1. Login gives a merchant the opportunity to ask a Vipps or MobilePay end user to share a selection of data from their profile in Vipps. This can include name, phone number, email, addresses, and date of birth. The merchant controls which of this data is requested. The user must consent to the sharing of data. The consent is the legal basis for the Vipps MobilePay AS (hereafter called Vipps MobilePay) transfer of this information to the merchant.
2. We are responsible for our processing of information related to our end users and the personal information generated using the Vipps MobilePay services. For the Login service, the merchant will be responsible for the processing of the profile information received, starting when the merchant receives the profile information from Vipps or MobilePay end user. The merchant will thus be an independent data controller for this data, and there is no need for a data processing agreement between Vipps MobilePay and the merchant.
3. The merchant must therefore obtain a valid basis for further processing of the personal data (e.g., agreement, terms or consent), to e.g. register the information in its customer register and start customer processing from there.
4. When such sharing from Vipps MobilePay to the merchant has been made, the end user can later use our services to log in to the merchant, and the merchant will then have access to updated information on the data elements that the company has requested. A Vipps MobilePay end user can go into the Vipps or MobilePay app and see which companies they have shared data with, which data has been shared, and they can withdraw their consent to share. This means that new consent must be obtained before we can share data again with the merchant.
5. When an end user uses Login at a merchant, we store, as part of our service to the end user and with Vipps MobilePay as data processor, information about (a) what information a user has agreed to share with a merchant and (b) when a user has used Vipps MobilePay log in to the relevant merchant.
6. Vipps MobilePay does not receive any information from the merchant about a Vipps MobilePay end user.

See more information in our privacy policy and terms and conditions.

Can we control the language displayed to the user?

No. The language is controlled by the browser settings.

Specifically, language is controlled by window.navigator.language; however, it gets more complicated since there are fallbacks. Refer to the documentation for your browsers.

Which configuration should I have when integrating using Azure B2C?

Azure B2C overrides the redirect_uri parameter to redirect to Azure B2C first, then to your redirect URI. You will need to look at your call to https://apitest.vipps.no/access-management-1.0/access/oauth2/auth and find the redirect_uri query parameter. This will need to be whitelisted in portal.vippsmobilepay.com.

See What are the requirements for Redirect URIs?

Azure B2C uses client_secret_post as token_endpoint_auth_method and the default value is client_secret_basic, so you'll need to change this in the portal.vippsmobilepay.com.

See How can I use client_secret_post for authentication?

Login does not return user information in the id_token, but there is a userinfo endpoint for this use case. See the Login API userinfo endpoint documentation. Azure B2C's User Flows does not use the userinfo endpoint, and you will therefore need to use a Custom policy.

How can we detect users' consent removal?

Or: How can our system dynamically "know/find out" if the user has revoked the consent for us to have access to his/her personal data in our system?

Your system can dynamically detect when a user's consent has been revoked by using consent webhooks. This is a system for notifying merchants when an end user revokes their consent. See the Consent webhooks section for more information.

Can we have multiple URIs as landing pages?

Yes. You can register as many callback URLs as you want; and then you specify which one you use in the request to GET:/access-management-1.0/access/oauth2/auth.

Can I use a custom URL scheme for the redirect_url?

Yes. If the redirect_url is using a custom URL scheme, such as myapp://, a path is required: myapp://path-to-something.

Can we change the name that appears in customer's app under Login and Access?

The name which is displayed in the customer's Vipps or MobilePay app is the name of the sales unit. You can change it yourself on portal.vippsmobilepay.com. See How can I change my name and logo?

Can we change the text that is displayed in the app during merchant initiated logins?

Yes, we have texts for different scenarios like "Join customer club" or "Share information". You can change it yourself on portal.vippsmobilepay.com.

How can I log a user out?

Login does not support merchant-initiated log-out in the browser, as this would effectively log the user out of Vipps MobilePay (meaning that the user will no longer be remembered in the browser across sites that use Login). You are of course free to log the user out of your service (by disabling your own session).

If a user wants to log out of a specific browser remembered in Login, they need to do this in the Vipps or MobilePay app by navigating to: Profile > Personal Information > Browsers that remember you, select a browser, and press the logout button.

Common errors

See FAQ: Common errors for more questions.

Why do I get The client or its related sales unit or merchant does not exist or is not active?

This means that the API credentials are for a Merchant Serial Number (MSN) that does not exist, or is not active. This can happen if the organization number has been deactivated. For Norwegian business, this happens at the Business registry.

Why do I get a CORS error?

We do not currently support any flows that requires requests being made from browsers.

See: Common problems: Why do I get a CORS error?.

Why do I get No CSRF value available in the session cookie?

Certain versions of Chrome give the error No+CSRF+value+available+in+the+session+cookie. Upgrading to the latest version of Chrome should solve this.

Why do I get HTTP 502 Bad Gateway?

Some merchants have experienced a 502 Bad gateway response from api.vipps.no. This typically occurs in situations in which the state or nonce parameter is 1000+ characters. We've seen this issue when any of the requests in the redirect sequence are too long (i.e.,2000+ characters). Therefore, try to keep these parameters at sane lengths. If there is a need to encode some payload in the state (i.e a JWT), it would be a better option to cache this at the client server and use the key as state.