Re: basic-card like SEPA Payment Method

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> 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>
> 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
> >
> > 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
> >
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>
>