What are redirects?

  • User-redirect: You set this redirect for each agreement you create. It can't be changed afterwards. 
  • Succes-callback: You set this redirect for each agreement you create. It can be changed afterwards. 
  • Cancel-callback: You set this redirect for each agreement you create. It can be changed afterwards. 

 

 

Agreement and checkout flow 

Please ensure that your usage of user-redirect is well implemented at the merchant side. When the Agreement activation is complete 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:

Link relation of the Agreement creation sequence.

 Link Customer scenarios  This will result in  The customer experiences

1. 

success-callback
  • User swiped to accept the Agreement 
 Callback to merchant system   

2. 

cancel-callback
  • 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

Callback to merchant system 

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

3. 

user-redirect
  • When the agreement activation is complete 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 on 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 . 

 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 tels you specifically if/when the user closes the landing page with the timer. 

 

  • payment_status_callback_url: You set this for each provider, and you can change it whenever. You can change it on the fly. 

As an integrator, you should set the "payment_status_callback_url" for each subscriptions provider, and then MobilePay uses it, when there are updates on payments. 

An example of body that you should use (just with your own values)

[

  {

    "value": "http://example.com",

    "path": "/payment_status_callback_url",

    "op": "replace",

    "from": "http://example.com"

  }

It is a PATCH method

Those do not need to be whitelisted at MobilePay.