As an aside: I wonder if more people would understand “repeat” instead of “recur” recur_frequency → repeat_frequency recur_day → repeat_day recur_interval → repeat_interval recur_count → repeat_count recur_until → repeat_until
In this case, it’s a request to get permission for a weekly magazine subscription charge. This SEPA Direct Debit (SDD) would redirect to your bank, where you confirm the mandate. It would return a sender_name, sender_identifier (IBAN), and mandate_identifier to the callback url
-
-
This is also where we run into some naming problems. The person paying is confirming, but no longer actively sending the money. To indicate who sends and who receives money, the payment world likes to use: payer/payee payer/beneficiary debtor/creditor
Show this thread -
However, those are difficult words. payer/payee only differ one letter, making mistakes easy. beneficiary scores 36/100 on the Flesch–Kincaid test. creditor scores just 23/100 https://www.webfx.com/tools/read-able/check.php …
Show this thread -
In my opinion, comprehension outweighs precision for light-weight protocols used by a broad public. Especially because the people who need the exact definition will be capable enough to read the specification.
Show this thread -
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.
Show this thread -
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