dApp - quick pay feature

[weilbith]

The dApp has a feature which allows to create links that include parameters for a full payment (token address, target address, amount and payment identifier). With the current redirect functionality, this will navigate the user automatically to a transfer after he connected to the dApp. Then he either does a direct payment or has to find a route first.

While this is working, it isn't a full mature feature. It doesn't work reliable for many cases, plus it misses some useful additions.

One missing feature is the complete communication cycle. This means that other applications can create links for a user to easily make a specific payment. But once the payment is done, the user must return manually to the origin application. Furthermore does the origin application has no clue that the payment is done.

The major issue is the unreliable user flow. The current feature only works for users which have used the dApp already and have a setup connection to the specific token network the payment targets. If these requirements are not given, the user will be dropped into an on-boarding flow or a connect token flow. The issue that in the meantime the dApp forgot that the user came originally to do this specific payment.
But also if all the previous made requirements are met, it could still fail. If the user has not already a direct channel with the payment target node, he has to find a payment route via a PFS and then do a mediated transfer. So far a normal payment flow as usual. But if the PFS can't find a route in the Raiden network, the payment flow of the user will fail. The flow basically stops. He will return to the default screen and that's it. He would now have to manually open a direct channel to the target or maybe deposit more tokens into his already open channel (for the case this is the issue to find a route). But again, the dApp fully lost the state of the original intention to do this payment and return to the other application.

Having this "pay and go" feature fully working is a key to improve the usability of Raiden/the dApp and to support new projects like the Raiden PayWall.

[weilbith]

Talel and I had an initial discussion how to tackle the implementation for this feature. In fact the old feature will remain as is, at it is basically part of the natural routing flow in the Vue application. Everything else were just tiny additions which re-used the existing structure.
We have agreed that it makes no sense to continue extending it as it will never be able to handle all of the describe issues above without completely mutating it and eventually break old features.

Rather we intend to add this as a complete new feature which 100% focuses on this very specific use case. Therefore we settled on the approach to introduce a new route which is responsible for all interactions. Thereby we have the guarantee that the original payment intention will never get lost though navigating around in the dApp. Having some "chached" knowledge would be a nightmare to manage and would never work reliably.
This means that we can re-use the old behavior where we have payment link with all necessary parameters. Then the route orchestrates the whole process for the user until he finalizes the intended payment and redirects him afterwards. So the user will never see any other route in the dApp.
Within this new route we will first check if the use is already onboarded for this token. If not we will initiate to open a direct channel to the payment target before doing a direct payment. Else we check if a direct payment is possible and do so if possible. If not the user has to query a route from a PFS (maybe automate this more than now) and then do a mediated transfer. If there is no route, the user gets asked to open a direct Channel as in the first case with a following direct payment. For the case there is a direct channel but without enough capacity, the user should be offered to deposit into the channel before doing a direct transfer.
The whole UDC management will be ignored also for new users, as this is not necessary for pure sending of tokens and it would complicate plus clutter everything.
Once the payment is done, the component is in charge to redirect the user. Therefore it will also attach the basic information of the done transaction to the query parameters. Thereby the origin application can match the user to where he came from or what his intention was.
If there is no redirect parameter given, we will navigate the use to the normal default screen of the dApp where he can also see the payment history.

For the whole flow in this single route component, we need to export everything into smaller sub-components. As basically all of the necessary partial features already exist, we must intend to re-use as many code as possible. Maybe we need to make existing components more flexible or export content of other routes to new smaller components to make them re-usable. The new route should focus 100% on managing the payment flow only without any navigation.

[weilbith]

This issue will become the tracker for the new route we will add for this.
Though it first needs #2890

[weilbith]

For the matter of documentation. Drawn by Talel and me in Mainz.

[