Re: SEPA Credit Transfer + W3C PaymentRequest

It might be interesting to know that by separating the authorization system from the payment system and by authenticating Merchants, the scheme permits using SEPA Credit Transfer in scenarios it was not designed for like Gas station payments, Bookings and Deposits.

That is, emulating features the card schemes already have built in.  All non-direct transaction requests build on counter-signing the original (by the bank) granted request which reduces database state holding to a minimum:
https://github.com/cyberphone/saturn/blob/master/resources/account.db/payer-bank.sql

Anders

On 2019-08-17 16:36, Anders Rundgren wrote:
> Hi Payment Aficionados,
> 
> F.Y.I. I'm putting the finishing touches on a Payment Authorization solution for account-2-account based transactions like SEPA Credit Transfer.  It builds on a native Android application invoked by Google's Android implementation of W3C's PaymentRequest. Aided by excellent help from Rouslan it wasn't too difficult to get PaymentRequest going.
> 
> This implementation uses massive amounts of cryptography to enable an end-2-end secured and scalable trust model which I believe is new for the banking industry:
> https://cyberphone.github.io/doc/saturn/enhanced-four-corner-model.pdf
> Yes, authenticating Merchants is (in this scenario NB) a prerequisite.  AML considerations also speak for this.
> 
> The client also needed some pretty advanced security features to cope with the rather demanding push payment model:
> https://cyberphone.github.io/doc/saturn/saturn-payment-credentials.pdf
> 
> Signed and encrypted JSON data is based on
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06
> which I hope to get published as an "Informational" RFC.
> 
> It was a pleasure replacing the awkward (and security broken) URL handler scheme with PaymentRequest!  Suddenly the App became an integral part of the browser experience.
> 
> If anybody wonder where ISO 20022 is in this scheme the answer is simple: ISO 20022 was designed for the "backend" while this system targets the "frontend".  Of course the information need to perform the backend operations must be available, but that is not the same thing as running the entire system on ISO 20022.  The security constructs as well as the message in step #4 has no counterpart in any backend protocol.
> 
> Thanx,
> Anders Rundgren
>

Received on Sunday, 18 August 2019 05:55:12 UTC