Step 3.1 - Test flow 

Once you have finished testing in sandbox, you have the opportunity to test "hidden" in production. This way, you can experience the flow, checkout flow and etc. using the MobilePay app. These two flows can be experienced in "hidden production". We advise you to test the flow thoroughly before going from "hidden production --> Live.

Final test for Production

Once you have finished the integration in Sandbox by completing the verification, you can test the payment flow in production.   

• Purpose: To test, whether the payment flow is performing as designed from start to finish.   

• Credentials: Your log-in, client-id, client-secret is different in production.   

• Reconciliation: Test that reconciliation and streamlining of financial reporting are behaving as expected.

• MobilePay app:  You can use the MobilePay app, installed from the AppStore or Google Play Store. You can use your own MobilePay userprofile.  

• Internal Test:  Afterwards, we recommend that you do Internal Acceptance Testing. The testing is performed by members of the organization that developed the software but who are not directly involved in the project (Development or Testing). Usually, it is the members of Product Management, Sales and/or Customer Support. User Acceptance Testing is performed by the end users of the software. They can be the customers themselves or the customers’ customers. 




MobilePay app 

You can use the MobilePay app, installed from the AppStore. You can use your own MobilePay userprofile. By having the app installed, you can test the payment flow and checkout experience by yourself, prior launching it to your customers. Our checkout flow should be friction-free.

Agreement and checkout flow 

Start your ecommerce optimization efforts at the checkout flow. Relative gains here will result in very nice absolute sums.

Make sure your customers are constantly aware of the next step they are about to take. Signpost any movements to third party sites such as MobilePay carefully and clearly so they can move there with confidence.


  • Please ensure that your usage of user-redirect is well implemented at the merchant side. When the Agreement activation is completed or canceled, the user will be navigated to the link rel = user-redirect to finalize the signup. 
  • Links must contain 3 values for user redirect. Read more here
  • The user must be redirected to this address in order to prompt agreement details for confirmation in the MobilePay app. As soon as the agreement is confirmed or the signup flow cancelled, MobilePay will notify you by doing a POST request at one of the callback URLs that are provided in the "links" collection:

Link relation of the Agreement creation sequence.

 Link Customer scenarios  This will result in 



  • User swiped to accept the Agreement 

Callback to merchant system 



  • User tapped the cancel button during the signup
  • User did not do anything during the agreement timeout period
  • User canceled an Active agreement
  • Merchant canceled an Active agreement
  • System canceled an Active agreement because user was Deleted

Read more here which screens the customer sees, when/if they cancel their subscriptions agreement. 

Callback to merchant system 



  • When the agreement activation is completed or canceled, the user will be navigated to the link rel = user-redirect to finalize the sign-up. We recommend that you display the One-Off payment and Agreement result. 
  • It should be a webpage, that awaits the callbacks and then takes appropriate action, depending if the agreement was accepted or not. Based on the callback, you will redirect the user to the right place. 
  • Most merchants navigate the customer to a self-service overview, where the agreement is pending, and once you receive the callback, then you can update the status. Most merchants have a general page, that says “Thank you for your order/support”, and then it informs about the next step. It is triggered immediately after purchase, letting customers know that their order and agreement has been received and created.

The user being redirected to a page, that the merchant has defined

Please define those URL's specifically so the user experience is optimised. The callback is triggered real-time. user-redirect is a HTTP GET and callback is HTTP POST 


 Please note:  user-redirect is primarily for the visual user experiance. The merchant should be aware of the fact that the user might close the browser,  the internet might fail etc. There are cases where the user and browser interrupt the flow, and MobilePay can't control these cases. 

 MobilePay doesn't do logging on the user-redirect, since part of the data is in in the app and part of the data is in landing page, hence it would be a very complicated set up. ​ All proper data comunication and logging and monitoring should be done thorugh callbacks and GET calls.  

 Callbacks for Agreements  
New Status Condition URL Callback status Callback status_text Callback status_code
Accepted  User swiped to accept the Agreement  success-callback Active    0 
Rejected User rejected agreement in the APP  cancel-callback Rejected  Agreement rejected by user 40000 
Expired User did not do anything during the agreement timeout period.  cancel-callback Expired  Pending agreement expired 40001 
Canceled User canceled an Active agreement cancel-callback Canceled  Agreement canceled by user 40002 
Canceled Merchant canceled an Active or Pending agreement cancel-callback Canceled  Agreement canceled by merchant 40003 
Canceled System canceled an Active agreement because user was Deleted cancel-callback Canceled  Agreement canceled by system. 40004 

You do not get a callback that tells you specifically if/when the user closes the landing page with the timer.


Merchants that want to offer their customers alternative options for canceling their payment agreement can via cancel-redirect ensure that a redirect is made to the merchant's self-service website. This is an optional feature, since it should only be used if the merchant has a self-service website where the customer can cancel the agreement. To ensure the best customer experience, a clear "Unsubsribe" or "Cancel" button should be present on the merchant website.  

How is this technically implemented?

  • For new agreements, use endpoint POST /api/providers/{providerId}/agreements with cancel-redirect link. A new link allows agreement to be cancelled in merchant own environmnet. Merchant should ensure easy access to information and support.
  • For existing agreements: use endpoint PATCH /api/providers/{providerId}/agreements{agreementId}   endpoint to change agreement request parameters

Merchant implementation & Self Service Environment 

  • If cancel-redirect is used, then MobilePay redirects customer to merchant environment, and thus making cancelling functionality unavailable for the user in the MobilePay app. 
  • The cancel-redirect is not mandatory, and merchant can only use cancel-redirect if they have a self-service environment, where the customer easily can cancel the agreement. 
  • The support unit on Merchant side should be able to cancel the agreement on behalf of the customer, in case the customer cannot figure out how to use their merchant self-service website. 
 Step 4. Verify UX  

Once you have made the needed adjustments for the checkout flow, the next step is to ensure that the UX is on point. It is important that you follow our brand guidelines and Best Practice, so you limit the bounce rate.