LIP-8 Recepient VASP can't send pre approval request to a sender VASP it is not aware of

[udirom]

In the recurring payments scenario recipient VASP (some merchant acquirer) should ask sending VASP (some consumer wallet) for a FundPullPreApprovalCommand (request for consumer consent for a recurring charge by the merchant). After such a request has been submitted the recipient VASP can now use "out-of-band methods" (Some interaction with the wallet user) to approve/reject the pull pre-approval request.

According to my understanding of the process, we may encounter a problem.
Let's say a merchant consumer wants to add Libra as a payment method (i.e to his favorite transportation app who wants to charge him for every trip).

The merchant app will ask it's Libra acquirer service to generate a request for a recurring charge consent. Problem is,
at that point in time nor the merchant or the acquirer can know who is the consumer VASP and who is the specific user (subaddress?) inside the VASP to whom the pre-approval request should be sent to.

Alternative flow might be:

1. Acquirer provides a QR/link at the checkout page with the scope of the consent request (amount, currency, etc...), the acquirer VASP address, and the merchant user id.
2. consumer scans the QR / opens the link with his Libra wallet.
3. The Libra consumer wallet asks for consumer consent (approve/reject).
4. Consumer wallet opens a channel to the requesting VASP (the merchant acquirer) and creates the FundPullPreApprovalObject with the consumer desition.

Thoughts?

[kphfb]

Great question. The LIP should be updated to make it agnostic to who the creating party is (sender or receiver) and should instead allow either party to create the FundPullPreApprovalObject. I do think that there are times when both will be applicable - for example, a merchant could simply ask you to enter your bech32 address identifier and then it initiates the pull pre-approval. Or you could do one payment and then the merchant could initiate this, etc. But I agree that the LIP shouldn't be indicating that the flow is unidirectional. I'll update to change that, thanks for the input!

[dahliamalkhi]

@udirom could you please indicate in issues which LIP you are referring to?