Re: Refund support?

On 2017-03-14 15:43, VIGNET cyril wrote:

Hi All,

This message was taken out of a context where I *off-list* asked some WG members
about their view on support for processes beyond direct payments like:

- Bookings (Pay another day)
- Card/Account "on file" (Amazon.com et al but also apply to electricity companies and telcos)
- Automated gas stations (Reserve Funds + Actual Payment)

The (in)famous Saturn scheme I'm plotting with addresses these scenarios by focusing
on *authorization* and leaving processes (including payments) to *subsequent* protocol
steps, [almost] completely outside of the payment app (aka Wallet) domain.

Support for refunding is a part of the "standardized" authorization process.

However, the Saturn scheme is probably not particularly interesting from a W3C
perspective since it *cannot be implemented using existing Web technologies*.
OTOH, Saturn appears to be in "good company" together with Android Pay, Apple Pay,
and their hundreds of lesser known "cousins".

The [anticipated] next project phase is getting support for security hardware since
it doesn't seem worthwhile introducing anything that already on the "drawing board"
is worse than *shipping* state-of-the-art products like Apple Pay.  This project is
fortunately "neutral" [*] and not in any way tied to Saturn.  If successful, it could
become a replacement for the currently dormant Hardware Based Security Services CG.

Anders

*] In fact, all the underpinning technologies used in Saturn were designed to be
neutral, with the aim enabling the market creating competing schemes as well.

On 2017-03-14 15:43, VIGNET cyril wrote:
> 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?
>

Received on Wednesday, 15 March 2017 09:27:04 UTC