Pre Authorization

[chadcampbell]

Hello,

I reviewed the Payment Request API. In my personal opinion, the PaymentRequest object needs an additional function. The purpose of the function would be to pre-authorize a payment for a specific amount. In the real-world, this situation happens at gas stations. For example, you have to swipe your credit card before you pump your gas. The gas station will pre-authorize that you can make a $100 purchase for example. In the digital world, I have the opinion that this preauthorization story is relevant when you take into consideration smart contracts.

I personally think this API would return a promise and would look something like this:

let paymentRequest = new PaymentRequest(...);
paymentRequest.authorize()
  .then(function(res) {
     // Now call the show function
  })
  .catch(function(ex1) {
    // The amount could not be preauthorized.
  })
;

[ianbjacobs]

Hi @chadcampbell,

Thank you for submitting this use case. We are starting to look more closely at automotive use cases [1], including pay at the pump [2].

I'm marking this as postponed for version 1 but look forward to returning to this use case soon!

Ian

[1] https://cdn.rawgit.com/w3c/automotive-pay/gh-pages/charter.html [2] https://www.w3.org/WebCommerce/IG/wiki/Automotive/UseCase_PayAtPump

[marcoscaceres]

I’m confused as to how this is any different to just calling show()? The display item would just be “€100 pre-authorize gas”? Then responses.complete(“fail”) if the amount can’t be pre-authorized. What am I missing? Is it just that you want the “Pay” button to say a different thing in the sheet (i.e., pre-authorize)?

[rsolomakhin]

I'm in the same boat as @marcoscaceres in that I believe the current API can accommodate the use case. I would recommend to use of payment handler API, if we decide to go with the CanMakePayment event firing design. Your PaymentRequest code would look like this:

let paymentRequest = new PaymentRequest(
    [{supportedMethods: 'https://chadcampbell.com/preauth'}], ...);
// Send `CanMakePayment` event to the payment handler.
paymentRequest.canMakePayment()
    .then(function(res) {
      if (res) {
       // The payment handler has pre-authorized a transaction
       // with some static amount, e.g., USD $1.00.
      } else {
        // Pre-authorization failed or payment handler not installed.
      }
    })
    .catch(function(ex1) {
      // Unexpected error occurred.
    })
;

In your payment handler, you would write the following:

self.addEventListener('canmakepayment', function(evt) {
  // Pre-authorize here.
  let preAuthSuccess = ...;
  evt.respondWith(preAuthSuccess);
});

This payment handler would need to live in a service worker at https://chadcampbell.com/preauth scope.

[chadcampbell]

I see now. I misunderstood the purpose of canMakePayment. Thank you for clarifying.

[ianbjacobs]

Thanks @rsolomakhin, and for adding that code to our code samples: https://github.com/w3c/payment-request-info/wiki/CodeExamples#pre-authorize-transaction

Ian

[cyberphone]

An existing solution here provided for "inspiration": https://cyberphone.github.io/doc/saturn/saturn-v3-presentation.pdf#page=13

[adrianhopebailie]

@rsolomakhin actually, while I agree with your point in general, I don't completely agree with your solution 😄

Most importantly, pre-auth is a feature of specific payment methods (just like recurring payments and other features we have explored). Some payment methods will support this concept, some won't.

If we "add support" for these features it will likely be in the Basic Card payment method spec (not payment request) where we will add some additional payment method data that allows the merchant to specify that they are requesting a pre-auth not a payment.

There will likely be value in defining some standard ways to express this so it can be consistent across other payment methods, or making it a property of the PaymentRequest but I expect that would be an evolution of the former happening first.

My understanding of the purpose of CanMakePayment is not to verify funds but check if the user has payment instruments available that "can make the payment". Have I got that wrong?

I'd be nervous about CanMakePayment having side-effects like actually checking a user's available balance (both from a privacy and usability perspective).

@chadcampbell I've kept this open and marked it as Postponed so we can keep it under consideration as we plan our work for the next version of this API.

[rsolomakhin]

check if the user has payment instruments available that "can make the payment".

Different types of payment methods will have different implementations for what this means. Some examples are:

• Does the user have at least 1 dollar in their account?
• Does the user have a card on file in their account?
• Does the user have an account?
• Can the user sign up for an account, even if they don't have one?