RE: Refund support?

Hello All

My understanding of refund :

-      Card system already organised the refund function at the back-office using the PAN

-      For the SEPA credit transfer, this could be organised  using the IBAN of the payer. I say “organized” because the merchant is not supposed to get the IBAN of the payer but its bank knows it. So the merchant could ask its bank to send a credit transfer to the payer.

-      For the SEPAmail system, the refund is organised using the JADE application in the backoffice of the merchant using the same identifier used in the payment transaction (QXBAN)

-      For the SEPA direct debit, it is even simpler because the merchant knows the IBAN of the payer so he could sent a credit transfer

-      Other systems, I don’t know

I think that a merchant gets enough information during the payment phase to organize later a refund. However, there is still a difference between payment and refund:

-      in the payment the payer gives his consent,

-      in the refund the consent of the payer is not asked. It could be interesting to have an approval by the payer before the refund is sent to be sure that the dispute is over (for WG #10)

Regards

PS: BPCE had published all its work regarding Scai on https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI#SCAI_API


Cyril VIGNET
+33622040856
+33158400234
Cyril.vignet@bpce.fr

From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
Sent: Saturday, March 11, 2017 4:44 PM
To: Saxon, Matt; 'Adrian Hope-Bailie'; KETELS Kris; KUNTZ Vincent; Manu Sporny; VIGNET cyril
Subject: Re: Refund support?

On 2017-03-10 18:10, Saxon, Matt wrote:
Thanks Anders, understood.

However this to me does represent a change in Scheme (as it requires changes in the bank systems for the cryptography) which is specifically outside of the WG Scope, see this statement in the charter. “This Working Group will not define a new digital payment scheme.”

Cryptographic solutions are outside of the WG charter but is a part of implementations ("schemes").  How implementations will deal with security and how it affects flows we can only guess.

BPCE/Cyril have AFAIK actually defined this part as well but for unknown reasons not published it which is kind of sad since there is hardly nothing more incompatible than different security solutions.

It probably takes 3-4 years converting the draft's "method" into a usable and deployed "scheme".

Anders
In my take on the matter the draft's SCT stuff only represents a possible internal integration point, you might as well start at the transfer step directly.  The only important is that you have the right data for invoking the transfer and that you have methods for creating trust.  The "reversed" authorization method used by Saturn makes the concept adaptable to all Merchant-initiated payment scenarios and methods I know of.




I don’t see why an enhancement to the spec couldn’t add this however should banks or acquirers support the scheme you describe in future. This would be much the same as the token payment method spec has enhanced the basic-card spec.

Regards,
Matt.

From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
Sent: 10 March 2017 09:33
To: Saxon, Matt <Matt.Saxon@worldpay.com><mailto:Matt.Saxon@worldpay.com>; 'Adrian Hope-Bailie' <adrian@hopebailie.com><mailto:adrian@hopebailie.com>; KETELS Kris <Kris.KETELS@swift.com><mailto:Kris.KETELS@swift.com>; KUNTZ Vincent <Vincent.KUNTZ@swift.com><mailto:Vincent.KUNTZ@swift.com>; Manu Sporny <msporny@digitalbazaar.com><mailto:msporny@digitalbazaar.com>; VIGNET cyril <Cyril.VIGNET@bpce.fr><mailto:Cyril.VIGNET@bpce.fr>
Subject: Re: Refund support?

On 2017-03-10 10:11, Saxon, Matt wrote:

Hi Matt,
Let me elaborate a little more on this apparent disagreement.


1)      The WG feel that initiating refunds from a browser is not required, certainly not in phase 1

That is something I also agree with since refunding is a Merchant "backoffice" action.




2)      Whilst it hasn’t specifically been discussed, as far as I am aware, it IS required for payments that are initiated via WebPayments APIs for the merchant to be able to initiate a refund. That is, if the underlying scheme requires this…. Some schemes don’t support refunds, e.g. BitCoin.

OK, if the underlying payment scheme doesn't intrinsically support refunds, it won't work well in the existing card based e-commerce (or local shop) ecosystem.




As such I think it is reasonable what Anders is suggesting as this, if im not mistaken, is a method to allow such refunds to be requested in a more private manner.

Refunds require a way to send money in the opposite direction and being initiated by the Merchant.  Creating new systems that doesn't have this basic functionality is something I wouldn't bother with.  SEPA SCT is effectively a bill payment system which doesn't match cards unless you augment it in some way.  I have described one such way.

Regards,
Anders




Anders, Adrian, can you validate my thinking?

Regards,
Matt.

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
Sent: 10 March 2017 07:48
To: Anders Rundgren <anders.rundgren.net@gmail.com><mailto:anders.rundgren.net@gmail.com>; KETELS Kris <Kris.KETELS@swift.com><mailto:Kris.KETELS@swift.com>; KUNTZ Vincent <Vincent.KUNTZ@swift.com><mailto:Vincent.KUNTZ@swift.com>; Manu Sporny <msporny@digitalbazaar.com><mailto:msporny@digitalbazaar.com>; Saxon, Matt <Matt.Saxon@worldpay.com><mailto:Matt.Saxon@worldpay.com>; VIGNET cyril <Cyril.VIGNET@bpce.fr><mailto:Cyril.VIGNET@bpce.fr>
Subject: Re: Refund support?


On Fri, Mar 10, 2017 at 9:21 AM Anders Rundgren <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>> wrote:
On 2017-03-10 08:10, Adrian Hope-Bailie wrote:
> As you point out below Saturn is a new scheme so I'm not sure why it is relevant to SEPA?

This was the actual question/claim:

   "Refund support is IMO a mandatory feature for Web payments"

The WG disagrees



The Saturn system was included to show one way of dealing with refunds.

Saturn should BTW be fully compatible with SEPA SCT since Saturn is neither a "scheme" nor a "method", it is an authorization system.

Anders

>
> On Fri, Mar 10, 2017 at 6:27 AM Anders Rundgren <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>>> wrote:
>
>     http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/

>
>     Maybe it is there somehow, I'm certainly not a SEPA expert.
>
>     Refund support is IMO a mandatory feature for Web payments.
>
>
>     Although you may not be interested to know, here is how refunds are dealt with in Saturn:
>
>     The payer's account ID is always handed over to the Merchant (in the AuthorizationResponse object received from the Payer's Bank).
>
>     However, the account ID is encrypted by a public key that only the Merchant's own payment provider (Acquirer or Bank) for the actual transaction has the associated private key to.  A refund requires the Merchant signing a RefundRequest (which embeds the original AuthorizationResponse), and sending it to its payment provider (Acquirer or Bank) for fulfillment.
>
>     This scheme builds heavily on the "Authority Object" concept which is a kind of linked data system not featured in traditional payment protocols.
>
>     That is, for SEPA, ACH and similar, a refund is a "standard" transfer in the opposite direction.  For card operations, a refund is (AFAIK) a specific operation but that is nothing Saturn need to bother about.
>
>     Anders
>
> --
> Sent from a mobile device, please excuse any typos
--
Sent from a mobile device, please excuse any typos




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 www.dnb.nl<http://www.dnb.nl>. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.








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 www.dnb.nl<http://www.dnb.nl>. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.






Ce message et toutes les pièces jointes (ci-après le 'message') sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération.
BPCE décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. 

This message and any attachments (the 'message') are confidential and intended solely for the addressee(s). If you receive this message in error, please delete it and immediately notify the sender. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. « BPCE » will not be liable for the message if altered, changed or falsified.