-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LIP-8 Recepient VASP can't send pre approval request to a sender VASP it is not aware of #71
Comments
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! |
@udirom could you please indicate in issues which LIP you are referring to? |
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:
Thoughts?
The text was updated successfully, but these errors were encountered: