AW: basic-card like SEPA Payment Method

Yes, that is correct. The key point is, that we as a P(I)SP acting on behalf of the payee need an IBAN to initiate the payment process.
Von: Saxon, Matt [ <>] 
Gesendet: Mittwoch, 2. Mai 2018 18:02
An: 'Adrian Hope-Bailie' <adrian@hopeba <> <>>; Ian Jacobs < <>>
Cc: Florian Bender < <>>; <>; KUNTZ Vincent < <>>
Betreff: RE: basic-card like SEPA Payment Method
I think Florian is asking for a Direct Debit flow, which is distinct from Credit Transfer, although the data elements are very similar.
Florian, can you confirm?
From: Adrian Hope-Bailie [ <>] 
Sent: 02 May 2018 16:56
To: Ian Jacobs < <>>
Cc: Florian Bender < <>>; <>; KUNTZ Vincent < <>>; Saxon, Matt < <>>
Subject: 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):
AT-07: The Requested Execution Date of the instruction
AT-41: The Originator’s reference of the Credit Transfer Transaction (End to End Identification in ISO20022 definition)
AT-06: The BIC of the Originator
AT-40: Identification code of the Scheme
AT-10: The Originator identification code
AT-02: The Name of the Originator
AT-09: The identification code of the Originator Reference Party
AT-08: Name of the Originator Reference Party of the Originator Reference Party
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)
On 2 May 2018 at 22:07, Ian Jacobs < <>> wrote:
Hi Florian,

Thank you for reaching out. I’m pinging Vincent Kuntz and Matt Saxon in particular on this topic.


> On May 2, 2018, at 8:23 AM, Florian Bender < <>> 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]: <>
> [2]: <>
> --
> Florian Bender | Product Manager Integrations
> 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: <>
> 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: <>

Ian Jacobs < <>> <>
Tel: +1 718 260 9447

This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through <>. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.

Received on Thursday, 3 May 2018 18:04:42 UTC