AW: basic-card like SEPA Payment Method

I do follow the argument that a push mechanism is preferred by PSD2. However, in my opinion it is not completely ruled out. The German Federal Bank states in [1] (German only) that SEPA Direct Debit transactions are still allowed. Consumer protection is achieved by granting consumers the unconditional right to reverse any Direct Debit on their bank account within eight weeks. Additionally, P(I)SPs acting on behalf of the merchant take care of all compliance issues regarding Mandate generation and submission deadlines.
 
[1] https://www.bundesbank.de/Redaktion/DE/Dossier/Aufgaben/inhalte_der_sepa.html?notFirst=true&docId=25932 <https://www.bundesbank.de/Redaktion/DE/Dossier/Aufgaben/inhalte_der_sepa.html?notFirst=true&docId=25932>
  <>
Von: Michel Weksler [mailto:michel.weksler@airbnb.com <mailto:michel.weksler@airbnb.com>] 
Gesendet: Donnerstag, 3. Mai 2018 07:10
An: Adrian Hope-Bailie <adrian@hopebailie.com <mailto:adrian@hopebailie.com>>
Cc: Ian Jacobs <ij@w3.org <mailto:ij@w3.org>>; Florian Bender <Florian.Bender@bspayone.com <mailto:Florian.Bender@bspayone.com>>; public-payments-wg@w3.org <mailto:public-payments-wg@w3.org>; KUNTZ Vincent <Vincent.KUNTZ@swift.com <mailto:Vincent.KUNTZ@swift.com>>; Saxon, Matt <Matt.Saxon@worldpay.com <mailto:Matt.Saxon@worldpay.com>>
Betreff: Re: basic-card like SEPA Payment Method
 
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.
 
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/ <https://w3c.github.io/payment-method-credit-transfer/>
> 
> [2]: https://w3c.github.io/payment-method-credit-transfer/#payee-initiated <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/ <https://www.w3.org/People/Jacobs/>
Tel: +1 718 260 9447 <tel:(718)%20260-9447>




 
-- 
- Michel