Bought a present with a group? Send this link to the group chat: pay.europa.eu/v2/ ?type=sct &receiver_name=Franz+Mann &receiver_identifier=NL91ABNA0417164300 ¤cy=EUR &amount=17.50 &description=Gift+for+Susan
Every 2nd and 16th day of the month till the end of the year: &recur_frequency=month &recur_day=2,16 &recur_until=2020-12-31
-
-
Every last day of the quarter: &recur_frequency=quarter &recur_day=-1
Show this thread -
Every Christmas day, till you cancel it: &date=2020-12-25 &recur_frequency=year
Show this thread -
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
Show this thread -
This is more light-weight than the PSD2 Payment Initiation API, yet preserves the push payment setup and bank authentication
Show this thread -
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
Show this thread -
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
Show this thread -
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.
Show this thread -
-
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
Show this thread -
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 …Show this thread -
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
Show this thread -
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
@japborstShow this thread -
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
Show this thread -
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