Unclear handling of non-direct payments including automatic gas stations

[cyberphone]

Non-indirect payments are payments requiring two phases, where the second phase typically do not involve user interaction. For automatic gas stations the first phase requires the customer in advance authorizing a reservation of an amount like $200, while the second phase performs the actual payment operation matching the measured volume of gas.

An example of messages used in such a scheme:
https://cyberphone.github.io/doc/saturn/hybrid-payment.html

This also has UI implications:
https://cyberphone.github.io/doc/saturn/ui-demo/personalpaymentterminal.html

[mattsaxon]

Agreed that this is a necessary requirement, though i'd expect this sort of functionality to be required for a number of the payment methods and no be unique to CreditTransfer. A related issue was raised on Payment Request, but it was felt that this sort of functionality would be for Phase 2 if i recall. It will probably need the PaymentRequest APIs to support the request and return of a status which represents Authorisation and "Hold" of funds, for a later "Execute (or Capture of funds)".

[ianbjacobs]

Since this is not a requirement for all payment methods, it seems this would be payment method specific, even if common across multiple payment methods. It seems that status information would be part of the payment method specific response data.

[adrianhopebailie]

There is a misunderstanding about the purpose of the Web Payments API here. The API is a mechanism for a payer and payee to establish a channel for payment using the browser as a mediator.

Any payment that requires a more sophisticated exchange than a simple request and response must specify a way to establish OOB communications through the initial handshake.

This applies to all payment methods.

[cyberphone]

@adrianhopebailie @ianbjacobs @CYV @mattsaxon I think you could safely close all the issues I have raised because the fundamental problem is that this draft conflates transactions and user authorizations which I consider a showstopper. Minimizing dependencies is always worth looking into. ISO 20022 does not deal with user authorizations AFAICT.

[adrianhopebailie]

draft conflates transactions and user authorizations

You'll have to explain why you think this is the case. The Web Payments APIs very explicitly avoid dealing with authentication and authorization.

[cyberphone]

This may be a terminology issue but in my opinion "checkout" is about a user authorizing a payment request. The strength of user authorizations differ between schemes, with CNP in the low region and Apple Pay in the other end of the spectrum.

Transaction request data etc: There's no standard for bringing in Merchant data into a "push" scenario. The draft assumes that this should be done in method specific ways or is betting on that the SEPA scheme is a super-set of all other methods' needs.

I have suggested reducing such dependencies in the "checkout" (aka Wallet), to almost zero and moving the (mostly unknown) method specific Merchant data to another layer in the stack which obviously requires an entirely different approach, case closed.

[adrianhopebailie]

The strength of user authorizations differ between schemes, with CNP in the low region and Apple Pay in the other end of the spectrum.

Correct

The draft assumes that this should be done in method specific ways

Correct

I have suggested reducing such dependencies in the "checkout" (aka Wallet), to almost zero and moving the (mostly unknown) method specific Merchant data to another layer in the stack which obviously requires an entirely different approach, case closed.

None of this makes sense. The method specific Merchant data is passed in the request and response as an opaque blob of data so it IS part of another logical layer.

[cyberphone]

None of this makes sense. The method specific Merchant data is passed in the request and response as an opaque blob of data so it IS part of another logical layer.

According to @ianbjacobs the decision to use WebIDL is because this data could be natively supported in browsers. That doesn't sound very opaque in my ears.

My idea was (and still is) moving this information to another protocol step which makes it easier dealing with different payment scenarios including POS payments not requiring Internet connectivity. The latter may become a no-issue in the future but it certainly isn't that today. But I leave it there.

[adrianhopebailie]

this data could be natively supported in browsers

Per the payment request API spec browsers are only required to pass this on as a data blob.

[mattsaxonwp]

@ianbjacobs

Since this is not a requirement for all payment methods, it seems this would be payment method specific, even if common across multiple payment methods. It seems that status information would be part of the payment method specific response data.

It is not for all, but it is common for many. For any push payments, it is going to be useful to understand on the return from PaymentRequest what the status is. I think an enumeration of something like "Not Started", "Funds on Hold", "Captured", "Cleared" will be needed. I just don't think we've considered this because for basic-card and tokenised-card, the status is effectively "Not Started".

This was previously discussed here and here, these threads contain a number of related issues, so the fact that they are closed does not for me suggest the debate was resolved satisfactorily.

The nub of this for me is joining up what is displayed on screen when the user hits a button to an API response that correlates such that effective user notification can occur as to what is the status of a payment. I don't believe that is resolved, but as I'm a little behind on the spec it may be so, and please correct me!

[adrianhopebailie]

@mattsaxon to do this we'd need to define some generic state flow that can be applied to all payments which I think is outside the scope of this group.

We should allow any payment method to express this information but leave it up to the methods to define the actual states.

[mattsaxonwp]

@adrianhopebailie, I think that argument was applied the previous time this was discussed, however we have seen a number of consistent themes pop up as we've considered payment apps, and we've refactored to bring them into the PaymentRequest API, this is just another example IMO.

Yes, sure the payment app can handle this, but then the browser won't be able to understand that data and so won't be able to use it to create a better user experience for ALL payments. Take for example a screen that shows a history of payments made with their status.

In terms of is this beyond the scope, from the WG charter, "Added value through machine-readable digital payment requests and payment responses.", I think the machine readability is enhanced through this factoring out. Furthermore it also read "The Working Group will standardize a set of messages", to me that includes factoring out commonalities, or at least exploring them.

[adrianhopebailie]

Do you want the browser to understand all of this? I'm already worried about how much data is being exposed to browsers.

In any event, I think the lowest common denominator we could come up with is success/fail/unknown which I'm not sure is that useful.

I'm not against someone trying to do this but I think it will be a challenge. E.g. What state is a Bitcoin transaction in when it's waiting for a 3rd block confirmation?

[cyberphone]

I have in my own take on this topic in practice converted Payment Request to become an Authorization Request which I think matches what card schemes do when you for example book an hotel room. The problem is how to display this information to a user. In card schemes you don't, it is supplied externally or is understood which makes sense since cards do not have UIs. Payment applications differ in this respect and the question is how to deal with that. I started with the gas station scenario (#42 (comment)) just to get some feeling for it because I couldn't find a single description of such things elsewhere. The browser shouldn't need to understand such data except for built-in payment apps (if there are such).

The return data to the Payee is (at least in my PoC), always based on the result of the authorization process including fund checking etc. If something goes wrong in an associated future or non real-time (e.g. SEPA) process ought to be out of scope for us like it is for card operations. The Payee must trust the Payment Processor for carrying out successfully authorized orders otherwise you get nowhere.

[adrianhopebailie]

I have in my own take on this topic in practice converted Payment Request to become an Authorization Request

That is incorrect. The Payment Request is a request to initiate a payment. It establishes a channel of communication between the payer and payee (or their agents) which may be used for any number of functions required to complete the payment.

The request contains some data that may be needed to do this (i.e. for card, nothing other than an optional list of supported networks) and the response is very method specific. For some payment methods the response may be a URL for callbacks or some other data that can be used to establish a separate out of band channel.

[cyberphone]

The Payment Request is a request to initiate a payment

Authorizing an "operation" related to the payment instrument matches the scheme used for cards. For my project universality and competitiveness are key values.

I do not have anything more to add to this topic.

[adrianhopebailie]

Authorizing an "operation" related to the payment instrument matches the scheme used for cards. For my project universality and competitiveness are key values.

I didn't understand this statement, can you elaborate?

[cyberphone]

Well, a

• Direct payment
• Booking
• Deposit
• Card on file

represent different operations which in the card world are authorized by the customer using the card. The goal has been finding a secure and universal authorization method not limited to cards for these scenarios that would not require changes at the payment network level (not inventing a new payment system).

[mattsaxonwp]

@adrianhopebailie

Do you want the browser to understand all of this? I'm already worried about how much data is being exposed to browsers.

Well all the data is exposed to the browser anyway, I'm just discussing if we should standardise it

In any event, I think the lowest common denominator we could come up with is success/fail/unknown which I'm not sure is that useful.

In PaymentRequest, when referring to the value in the complete() method, it is stated that "The user agent may use the value result to influence the user experience.". I'm wondering since we have allowed the merchant to explicitly state the result, then why a payment apps should not be able to do so too, it seems for a push payment that the Payment App is in a much better place to assert the status.

I'm not against someone trying to do this but I think it will be a challenge. E.g. What state is a Bitcoin transaction in when it's waiting for a 3rd block confirmation?

I think we should allow the Payment App to assert a status in a standard way, however the payment app can decide what those statuses are.

[cyberphone]

@adrianhopebailie @mattsaxon @CYV It seems that the latest draft (2017-03-24) featuring a "Pull-credit transfer" scheme is slowly drifting towards a (better) concept where authorizations and payments are separated. What's missing is some kind of a rationale for using the pull scheme rather than the original push scheme.

In my opinion pull is only needed/motivated for non-direct payments (which this issue was all about), but then the state diagram doesn't really apply. A gas station would open after step 6 and a booking would be fulfilled there as well.

[cyberphone]

The following picture is hopefully showing what I'm talking about:

That is, direct payments, bookings, gas stations as well as refunds can be supported by a payment system independent authorization scheme even if the underlying payment system cannot. The scheme has unfortunately not been subjected to a thorough peer review.

The "Wallet" may be replaced by a PaymentHandler without changing anything with respect to the Merchant.

[adrianhopebailie]

The goal has been finding a secure and universal authorization method not limited to cards for these scenarios that would not require changes at the payment network level (not inventing a new payment system).

All out of scope for this WG and this specification. It sounds like you should be proposing your solution as an answer to the technical requirements of PSD2

[cyberphone]

If we step back to the original issue, this specification is currently unclear on multiple points including fundamental things like how to deal with non-real-time inter-bank payment-systems like SEPA SCT in an on-line shop. However, since the WG have decided leaving such questions to the "scheme" designers, I believe we can safely close this issue for now.