Closed adrianhopebailie closed 8 years ago
To support enrollment in a service or a future charge, I propose that the details
object can contain "is_billing_agreement": true
key-value pair.
amount
should be the estimated periodic charge amount.amount
should be the estimated future charge.I'm not sure that is specific enough to be a payment obligation, perhaps it should be a maximum rather than an estimated?
I'm not sure we need to do anything special to support this use case, except perhaps document that authorizations are performed with an amount of "0". How capture happens (or not) is something between a merchant and their PSP. Everything else can be explained on the merchants website, as it happens today.
We might need to be careful there, there are some payment methods that don’t actually support zero amount authorizations.
On Feb 10, 2016, at 6:38 AM, Zach Koch notifications@github.com wrote:
I'm not sure we need to do anything special to support this use case, except perhaps document that authorizations are performed with an amount of "0". How capture happens (or not) is something between a merchant and their PSP. Everything else can be explained on the merchants website, as it happens today.
— Reply to this email directly or view it on GitHub https://github.com/w3c/webpayments/issues/65#issuecomment-182400693.
Regarding the payment methods that don't support zero amount authorizations: do these payment methods support periodic billing or future charge?
Yes, they can - additionally you may want to actually place a hold on the payment instrument, or verify the amount you might charge in the future is actually present right now (the same is true for periodic billing - you may not be charging the user for another 30 days, but you want to verify now they actually are likely to be able to cover the charge).
Sometimes this charge isn’t necessarily visible or clear to the user, but still happens (Uber is a good example, you aren’t charged until the ride is completed, but there is still a charge being placed for an actual amount when you call the car).
On Feb 10, 2016, at 11:47 AM, Rouslan Solomakhin notifications@github.com wrote:
Regarding the payment methods that don't support zero amount authorizations: do these payment methods support periodic billing or future charge?
— Reply to this email directly or view it on GitHub https://github.com/w3c/webpayments/issues/65#issuecomment-182547483.
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
Zach wrote:
I'm not sure we need to do anything special to support this use case, except perhaps document that authorizations are performed with an amount of "0".
I can't find my response on this subject earlier in this issue - I could have sworn I posted it.
In any case, we should >not< propagate odd semantics of zero or -1 for amount into our language. If an acquirer is looking for an amount=0 to mean something, that should be translated out of the standard message, not embedded in it.
In any case, we should >not< propagate odd semantics of zero or -1 for amount into our language. If an acquirer is looking for an amount=0 to mean something, that should be translated out of the standard message, not embedded in it.
+1
I'm a big +1 to not carrying bad design into our API due to legacy of any underlying systems. If we want to support various uses we should call them out as valid transaction types.
Payment apps and PSPs should deal with a payment request for a "reservation" or "enrollment" or "some payment type" and translate this into the appropriate set of parameters in their messages to the scheme/network.
Migrating to https://github.com/w3c/browser-payment-api/issues/52.
Migrated from https://github.com/WICG/paymentrequest/issues/43
@ianbjacobs:
@adrianba:
@mattsaxon: