W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2018

Re: basic-card like SEPA Payment Method

From: Andrew Bransford Brown <andrewbb@gmail.com>
Date: Thu, 19 Apr 2018 23:55:12 +0700
Message-ID: <CAPS+YF+JPpGtg+5puA66wHsLDG7vBTPZjqD5epMRV=R-Zk89Rg@mail.gmail.com>
To: Florian Bender <Florian.Bender@bspayone.com>
Cc: "public-webpayments@w3.org" <public-webpayments@w3.org>
It looks like a similar approach as Promise Language, which is designed for
any contract:

Similar to HTML or XML, PL (Promise Language) is a simple framework
describing promises that can be read by humans and processed by computers.
For example:

  (person's name)
  (person's name)
  (description of value conveyed)

A Transaction would comprise two Promises. A Transaction is marked as
completed when both Promises are delivered. Simple. Templates for forms of
Value (such as electronic gold, paper money, electronic silver, labor/time,
etc.) allow for efficient processing by banks and related financial
entities. Transaction costs go down. Reporting becomes automated,
standardized and simple. Conveying reputation to others for credit purposes
becomes easier.


On Thu, Apr 19, 2018 at 3:11 PM, 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 | Fraunhoferstr. 2-4 | 24118 Kiel
> HRB 28985 | AG Frankfurt am Main | Board of Directors: Niklaus Santschi,
> Jan Kanieß, Dr. Götz Möller, Carl Frederic Zitscher
> 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
Received on Thursday, 19 April 2018 16:55:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:49 UTC