Re: basic-card like SEPA Payment Method

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:

<promise>
 <promissor>
  (person's name)
 </promissor>
 <promisee>
  (person's name)
 </promissee>
 <value>
  (description of value conveyed)
 </value>
</promise>



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.


http://promiselanguage.blogspot.com/2010/03/similar-to-html-or-xml-pml-promise.html



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
>
>
> 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
>
>