Get code

Step 2: Get Code

You need to wait for the response by listening on the redirect_uri and get the code. MobilePay will re-direct you back to your system also using the redirect_uri. You only need to give consent once, unless you lose the code it expires, or you loose the access_token gained in the next step. The code has a lifetime of 5 minutes and can only be used once. Successive token requests with the same code will result in error.

Request an Authorization code

	Sandbox	Production
DK	https://sandprod-admin.mobilepay.dk/account/connect/authorize	https://admin.mobilepay.dk/account/connect/authorize
FI	https://sandprod-admin.mobilepay.fi/account/connect/authorize	https://admin.mobilepay.fi/account/connect/authorize

1. Redirecting the user

To request code, you must direct the user's browser to MobilePay's authorization endpoint. Once the request is made, one of the following two situations will occur:

• If the Merchant has not previously granted consent or has been manually revoked by the Merchant, the browser will be redirected to MobilePay authorization screen. When the Merchant completes the authorization process the browser is redirected to the redirect_uri provided in the redirect_uri query parameter.
• If there is a valid existing permission grant from the user, the authorization screen is by-passed and the user is immediately redirected to the URL provided in the redirect_uri query parameter.

2. Succesful authorization On a successful authorization, the Authorization Server, and the merchant has given consent, then the code will be returned to you together with the state. For security reasons, the code has a short lifespan (5 minutes) and must be used within this time. If the code expires you need to repeat all of the previous steps to request another.

https://REDIRECT_URL#code=SPlxlOBeZQQYbYS6WxSblA&state=228eaa0b1a2819a77f055171edb7d9d6&id_token=eyJhbGciOiJSUzI1NiIslm...

In the example, you can see the redirect_uri, with a code as part of the URL: https://REDIRECT_URL/callback#code=BPPLN3Z4qCTvSNOy.

note

Here you need to verify the state (compare the value in the response to the one you sent to /connect/authorize) and save the code for fetching the tokens in the next request. Since it's possible for an attacker to craft a GET request that looks similar to this, an attacker could provide your application with junk authorization codes. You need to first verify that the state parameter matches this user's session so that you can be sure you initiated the request, and are only sending an authorization code that was intended for your client. Depending on how you've stored the state parameter (in a cookie, session, or some other way), verify that it matches the state that you originally included in step 1.

3. Verifying the Authorization Code grant

After checking for all required parameters, the authorization server can continue verifying the other parts of the request. Before you accept the code you should ensure that the value returned in the state parameter matches the state value from your original authorization code request. This ensures that you are dealing with the real original user and not a malicious script that has somehow slipped into the middle of your authentication flow. The server then checks if the code is valid, and has not expired. The service must then verify that the code provided in the request was issued to the client identified. If everything checks out, the service can generate an access_token and respond'

The code is not the final token that you use to make calls to MobilePay with. It is used in the next step of the flow to exchange for an actual access_token and refresh_token. This is an important step because it provides assurance directly from MobilePay to the Merchant that permission is being granted to the correct application.