This is effectively the same information as the EPC QR code scheme https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/quick-response-code-guidelines-enable-data-capture-initiation …pic.twitter.com/WbBYBOM33k
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
Every Christmas day, till you cancel it: &date=2020-12-25 &recur_frequency=year
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
This is more light-weight than the PSD2 Payment Initiation API, yet preserves the push payment setup and bank authentication
The downside for the initiator is the lack of transaction status confirmation, so that will have to be done out of band. Which is the same for the EPC QR code
No reason why the United States couldn’t do this too, as long as they introduce alias/proxy support (think Zelle): pay.federalreserve.gov/v1/ ?type=now &receiver_name=John+Smit &receiver_identifier=541-754-3010 [phone] ¤cy=USD &amount=5.00
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.
The benefit of this Payment Link scheme over the EPC QR scheme is that: (a) Both of these QR codes can be scanned with your bank app (b) Only the Link can be scanned with your default camera app (c) Only the Link can be shared in a message or typed into a browser
It’s honestly a little maddening that the @EPC_SEPA was able to release a very clean QR code scheme https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2018-05/EPC069-12%20v2.1%20Quick%20Response%20Code%20-%20Guidelines%20to%20Enable%20the%20Data%20Capture%20for%20the%20Initiation%20of%20a%20SCT.pdf … and is completely over-complicating the mobile payment scheme https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2019-06/MSG%20MSCT%20026-18v09%20MSCT%20IIGs.pdf …
The EPC even seems to want to drop their own simple QR code scheme and use the over-engineered EMVCo one… https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2019-06/EPC109-19v1.0%20White%20paper%20MCPPs_final.pdf …pic.twitter.com/cwiU30mEvW
Let’s add a second type to confirm direct debit mandates:
pay.europa.eu/v2/
?type=sdd
&receiver_name=Magazine
&receiver_identifier=NL91ABNA0417164300
¤cy=EUR
&amount=9.50
&amount_edit=false
&date=2020-05-25
&recur_frequency=week
&callback=magazine.nl
Thanks to @japborst
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
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 …
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.
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.’
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)
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
And we can even merge some variables: ¤cy=EUR &amount=9.50 is shortened as &a=EUR9.50
What else should we consider for a light-weight, permissionless payment request link scheme?
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.