By allowing the user to re-enter the actions they have previously taken, we are able to close the loop on the user journey for the subscription management process.

Depending on the implementation, the original entry point might not always be available. For example, if the entry point is implemented from the transaction history page, it’s recommended to only show the entry point for 30 days, which means that after the expected time has passed the entry point will no longer be available. Together with allowing the user to see what subscription related actions they’ve previously performed in a single place creates the need for the subscription history view. Additionally, by allowing the user to view all their subscription actions from a single place removes the need from scrolling through all their transactions in order to find the transaction where they initialized the action.

Communication at entry point

After an action has been successfully submitted, the entry point needs to be updated. The user has already submitted an action, so it does not make sense to keep the same content on the entry point. After the action is submitted, the user would be expecting to see updates based on their action. We recommend that the entry point is updated to provide the most urgent information to the user, namely that an action was submitted and on which date. This will continuously be updated, as the action is processed and finally completed.


Communication at entry point

Subscription changes view

The subscription changes view serves as a history of the actions the user has taken on their subscriptions. It allows the user to:
Re-visit the outcome of their previous actions
See further details of each action
Perform follow-up actions for some actions (such as Unblocking a Blocked payment)

This view can be placed wherever it makes sense with your app’s UI architecture, and serves as a fixed entry point for the user, compared to the dynamic entry points that are placed on transactions that may disappear over time.