Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65)

In the existing "regulations", the authorisation with amount=0 belongs to the list of recurring confusing questions. There are a lot of misinterpretations around it by the various providers.
Most of the time it is used to get non payment information from an issuer: for instance, just an authentication, or an account balance. But the problem gets tougher when this is done inside a payment process. For instance, many e-commerce sites request an authentication of the consumer with amount 0 at the initial step of check-out... and sometimes with 3DS. This avoids to do later on (in the rest of the process) a 3DS transaction for every good that the consumer buys on their site. This is clearly a way to circumvene the authentication and consent procedures.

In these cases, amount 0 is an inheritage of the clumsy protocols where one cannot send a request for anything else then for authorizing a payment...and the message thus imposes an amount, the tricky way to use it being to set it to 0.
This shows that there is a (huge) need for adapted API and transactions dedicated to information, credentials, and authentication retrieval, for today's methods are often based upon workarounds.

When it comes to payment, if an amount = 0 is in the check-out, it implies that there is no consumer consent.
To get the consent, amount must be provided, and accepted by the customer; and the amount must take part in the authorisation mechanism to proof the consent: 
Cf. PSD2: "Member States shall ensure that, for electronic remote payment transactions, payment service providers apply strong customer authentication that includes elements which dynamically link the transaction to a specific amount and a specific payee". (3DS style).

In the beginning of the payment process (I reserve my hotel room), the amount may be "estimated", this condition has to be clear for payee and payer.
At this stage, when the authorisation is granted by the consumer's issuer, the corresponding funds are "reserved". They can only be actually debited from his account when the exact amount is "known". If the payment operation is cancelled, or estimated amount modified, funds reservation must be changed accordingly and as soon as possible.
To do again the connection with the PSD2 discussion thread, the related regulations are provided by article 75 and 76 which give a simple and clear "state of the art"
"
Article 76
Refunds for payment transactions initiated by or through a payee
1. Member States shall ensure that a payer is entitled to a refund from the payment service provider of an authorised payment transaction which was initiated by or through a payee and which has already been executed, if both of the following conditions are met:
(a) the authorisation did not specify the exact amount of the payment transaction when the authorisation was made;
(b) the amount of the payment transaction exceeded the amount the payer could reasonably have expected taking into account the previous spending pattern, the conditions in the framework contract and relevant circumstances of the case.
Article 75
Payment transactions where the transaction amount is not known in advance
1. Where a payment transaction is initiated by or through the payee in the context of a card-based payment transaction and the exact amount is not known at the moment when the payer gives consent to execute the payment transaction, the payer’s payment service provider may block funds on the payer’s payment account only if the payer has given consent to the exact amount of the funds to be blocked.
2. The payer’s payment service provider shall release the funds blocked on the payer’s payment account under paragraph 1 without undue delay after receipt of the information about the exact amount of the payment transaction and at the latest immediately after receipt of the payment order.
"

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/65#issuecomment-183277042