How can the API support enrollment (future payment) use cases?

[adrianhopebailie]

Migrated from https://github.com/WICG/paymentrequest/issues/43

@ianbjacobs:

Here is a use case that should be supported:

• Service asks user at enrollment to register payment details for future use
• API is used to retrieve those details, but no payment should actually take place.

Some payment apps might support this (e.g., raw credit card information) while others might not
(e.g., those that return 1-time tokens).

What (if anything) does the API need to say to help readers recognize that it supports this
enrollment use case?

For example, suppose the preferred way to use the API for enrollment to specify amount=0.
The spec should say something to that effect and, for example, ensure that the definition of
amount supports that value.

Or, there might be other ways the API could support the enrollment use case. I look forward to
your thoughts.

@adrianba:

There may be many occasions where a site wants to request a payment method but not to make a charge. For example, it is common to provide a credit card number to book a car rental or to make a hotel reservation but the payment is made later, in person, and potentially with a different payment method. The merchant may charge the original payment method under some circumstances (for example no show at the hotel).

This seems very payment method specific. Perhaps we need to explore the "amount=0" use case?

@mattsaxon:

There are 2 sub uses cases to consider here;

1. An identification validation, amount=0 might be a reasonable approach here
2. A deposit/reserve, e.g. a hotel deposit, a common way of doing this to authorise an actual amount, but not make the charge unless something happens, this is known as an "authorisation" without a "capture", effectively these are two seperate transactions when can be bundled as a "sale". The flows we have documented so far don't differentiate these as the distinction occurs between the merchant and the merchant PSP, not between the shopper and the merchant. However it might be prudent to have a distinction in the target model so the user is aware what they are signing up to.

[rsolomakhin]

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.

• For periodic billing: the amount should be the estimated periodic charge amount.
• For future charge: the amount should be the estimated future charge.

[mattsaxon]

I'm not sure that is specific enough to be a payment obligation, perhaps it should be a maximum rather than an estimated?

[zkoch]

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.

[webpayments]

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 [email protected] 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 #65 (comment).

[rsolomakhin]

Regarding the payment methods that don't support zero amount authorizations: do these payment methods support periodic billing or future charge?

[webpayments]

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 [email protected] 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 #65 (comment).

[fredMeignien]

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
2. 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.
3. 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.
   "

[dezell]

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.

[dlongley]

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

[adrianhopebailie]

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.

[msporny]

Migrating to w3c/payment-request#52.