A risk is that people might just click on a random link, get redirected to their bank, and don’t realize they are asked to transfer money. Though request services like Venmo, PayPal, and Tikkie seem to show this is manageable.
Another thing to add is an idempotency key to prevent the same transaction from being completed twice. Given the decentralized nature of this scheme and the fact that the key does not need to be exposed to the user, I suggest an RFC 4122 UUID.
-
-
You would add: &unique_key=[uuid] And it gets passed on to the bank, which stores it for a minimum of 30 days. They also return it to the callback url. Again, ‘unique’ should be easier to understand to the general public than ‘idempotent.’
Show this thread -
The callback needs to be verified though, which we can do through a combination of: (a) The unique key (which transaction) (b) HTTP Signatures (correct server) (c) Bank account number to domain name mapping maintained by the central directory (server is a bank)
Show this thread -
URL maximum is 2048 characters, but they are preferably shorter than that to generate easy to scan QR codes. Every parameter has a preferred long-form and optional short-form: type = t receiver_name = rn receiver_identifier = ri sender_identifier = si recur_frequency = rf
Show this thread -
And we can even merge some variables: ¤cy=EUR &amount=9.50 is shortened as &a=EUR9.50
Show this thread -
What else should we consider for a light-weight, permissionless payment request link scheme?
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
at
retweets