W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2018

Re: basic-card like SEPA Payment Method

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 3 May 2018 11:28:52 +0200
To: Michel Weksler <michel.weksler@airbnb.com>
Cc: Ian Jacobs <ij@w3.org>, Florian Bender <Florian.Bender@bspayone.com>, "public-payments-wg@w3.org" <public-payments-wg@w3.org>, KUNTZ Vincent <Vincent.KUNTZ@swift.com>, "Saxon, Matt" <Matt.Saxon@worldpay.com>
Message-ID: <d1f8edc1-f749-7832-5e56-5bbfad426d10@gmail.com>
On 2018-05-03 07:09, Michel Weksler wrote:
> Also, I'm curious as to the PSD2 implications here - i am not an expert on the details of the directive (and am happy to be educated about it here!), but am under the impression that it strongly mandates merchants to use a push mechanism vs. a direct debit one, and that transfer of actual bank account identification is being discouraged.

Right on.

Direct debit is cool for what it was (originally) developed for like rents, electricity bills, etc.

For e-commerce it seems like a rather odd solution since it requires that the Merchant (in some way) gets a mandate for debiting money from the customers bank account.

iDEAL-like schemes are more suited for arbitrary e-commerce but have a problem which doesn't make everybody happy: you must authenticate to the bank.

The Open Banking folks in the UK have addressed this issue in a somewhat surprising way:
https://www.linkedin.com/pulse/psd2-transforming-banks-dumb-pipes-anders-rundgren/

Anders

> 
> On Wed, May 2, 2018 at 8:58 AM Adrian Hope-Bailie <adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote:
> 
>     Hi Florian,
> 
>     It may not be obvious but the PayeeCreditResponse extends the CreditResponse, so it contains all the same fields, in addition to a token. These include the following (with SEPA definitions provided):
> 
>     selectedProcessingDate	AT-07: The Requested Execution Date of the instruction
>     payerPaymentIdentification	AT-41: The Originator’s reference of the Credit Transfer Transaction (End to End Identification in ISO20022 definition)
>     payerBankCode	AT-06: The BIC of the Originator
>     selectedNetwork	AT-40: Identification code of the Scheme
>     payerIdentificationCode	AT-10: The Originator identification code
>     payerName	AT-02: The Name of the Originator
>     buyerIdentificationCode	AT-09: The identification code of the Originator Reference Party
>     buyerName	AT-08: Name of the Originator Reference Party of the Originator Reference Party
>     statusInformation	None?
> 
> 
>     I think this covers everything you have requested.
>     Are you suggesting this is too much? (Note that only the first 4 are required, the rest are optional)
> 
>     Adrian
> 
> 
>     On 2 May 2018 at 22:07, Ian Jacobs <ij@w3.org <mailto:ij@w3.org>> wrote:
> 
>         Hi Florian,
> 
>         Thank you for reaching out. I’m pinging Vincent Kuntz and Matt Saxon in particular on this topic.
> 
>         Ian
> 
>          > On May 2, 2018, at 8:23 AM, Florian Bender <Florian.Bender@bspayone.com <mailto:Florian.Bender@bspayone.com>> wrote:
>          >
>          > Dear all,
>          >
>          > I am working at a German Payment Service Provider. We have currently implemented the basic-card method in one of our shop extensions. This has raised a lot of interest in the German market, as merchants are always looking to explore new conversion-enhancing technologies.
>          >
>          > However, with SEPA direct debit payments being very popular in Germany, most merchants are resistant to implementing any variety of the Payment Request API into their shops, as it is (for them at least) currently limited to basic card payments.
>          >
>          > After a chat with Ian I've come across several propositions for SEPA credit transfer payments, the latest (and most advanced) probably being [1]. From our perspective as a PSP, we'd suggest a simpler approach: a basic-card like implementation of the exchange of address and bank data, allowing us to initiate the SEPA debit through our established platform (and handling all compliance issues on the way). I suppose this would be somewhere along the lines of [2], however, instead of a token the IBAN, payer's name and BIC would be sent off through an encrypted connection. This is the way most merchants have already implemented it their shops today without making use of the Payment Request API.
>          >
>          > Is there currently any discussion of such a payment method that I might have missed while browsing the archives? Is there any way to contribute to the development of such a method?
>          >
>          > Thank you and all the best
>          > Florian
>          >
>          > References
>          >
>          > [1]: https://w3c.github.io/payment-method-credit-transfer/
>          >
>          > [2]: https://w3c.github.io/payment-method-credit-transfer/#payee-initiated
>          >
>          >
>          > --
>          > Florian Bender | Product Manager Integrations
>          >
>          >
>          > BS PAYONE GmbH
>          > Office Kiel
>          > Fraunhoferstraße 2-4 · 24118 Kiel · Germany
>          > Registered office: Frankfurt/Main
>          > District Court Frankfurt/Main HRB 28 985
>          > Managing Directors: Niklaus Santschi, Jan Kanieß, Dr. Götz Möller, Carl Frederic Zitscher
>          > Chairman of the supervisory board: Ottmar Bloching
>          >
>          > BS PAYONE - neu entstanden durch den Zusammenschluss der Schwestergesellschaften B+S Card Service GmbH und PAYONE GmbH – Ihr Full-Service-Zahlungsdienstleister rund um den bargeldlosen Zahlungsverkehr. Weitere Informationen zur Fusion finden Sie unter: www.bspayone.com <http://www.bspayone.com>
>          >
>          > BS PAYONE - originating from the merger of the sister companies B+S Card Service GmbH and PAYONE GmbH - your full-service payment provider for cashless payment transactions. For more information on the merger, please visit: www.bspayone.com <http://www.bspayone.com>
>          >
> 
>         --
>         Ian Jacobs <ij@w3.org <mailto:ij@w3.org>>
>         https://www.w3.org/People/Jacobs/
>         Tel: +1 718 260 9447 <tel:(718)%20260-9447>
> 
> 
> 
> 
> 
> 
> -- 
> - Michel
Received on Thursday, 3 May 2018 09:29:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 May 2018 09:29:25 UTC