Regarding the issues raised for Pull Credit Transfer

[nkosi23]

The Pull Credit Transfer Wiki Page raises the following issues:

1. flows (6) and (7) should be normalized in some ways. If not, it will be impossible for any merchant to connect to an arbitrary bank because they have no prior technical or contractual relationship.
2. Even if the merchant could wait to trigger the fund transfer, she should not wait too much. Indeed, even if there is the consent of the payer, the funds are not reserved in an escrow system. Thus, if the payer makes another payment, she might deplete the balance of the account, and the credit transfer will not be submitted.
3. It is quite impossible for the bank of the payer to authenticate the merchant.

Regarding 3., while the bank cannot authenticate the merchant, does it really need to? When a consumer pays by card or withdraws cash to give it to someone, does he expects his bank to authenticate the recipient or arbitrate the transaction? The answer is no.

With Credit Transfers, the consumer will authenticate the merchant before deciding to proceed with the credit transfer. Moreover, creating an authentication requirement at the bank level takes us a back to a situation in which 1, 2 or 3 players will be the de facto gatekeepers for online payments while W3C Payments and PSD2 both intended to and are a unique opportunity to stimulate competition and give full flexibility to online payments.

I would also note that in a world where every merchant/payee must be technologically authenticated, this technological authentication is by definition of no value to consumers. They will not feel that a merchant is safer because he is in the system since every merchant is in the system. And the same is true if banks must proceed to the authentication.

However, what I think is the most important point is that - as already mentioned - the decision to authenticate a merchant should be left to the consumer. The payer and the payee have many tools to "negotiate" authentication. In 90% of cases it will be implicit and automatic (the website initiating the payment is trusted by the consumer, business registries websites that can be used to authenticate a website etc...), in the remaining situations the payer and the payee can agree on what is necessary to build trust (scanning and sending proof of identity to each other etc...). So while this is a very difficult problem at a technological level, it is in practice most-of-the-time a non-issue and the rest of the time very easy to solve at a social level.

Regarding 2., I do not think that this is an "issue". Credit transfer systems having this behavior have long existed: checks. When a merchant accepts checks, he knows that he needs to deposit them fast enough or at a specific time agreed with his client (the traditional "please cash the check on Wednesday" written on the back of checks) and this is totally ok. There was a time when everybody was paying by check and the world was happy with it. Credit transfer will be sort of a come back to that point. But my point is that this is known territory so there is no question mark on whether or not it will work.

People will love it even more than they loved checks because the web environment is a huge improvement over the piece of paper. For example, certain merchants wanting to minimize their risk on certain transactions could even require consumers to connect a social media accounts (or innovative authentication services) to authenticate them without friction. The possibilities are many. But advanced authentication will not be used in 80% of credit transfers.

To put it differently, 2. and 3. are not technological issues and I therefore think that we should not attempt to find a technological solution to "fix" them. The first reason being that there is nothing to fix. The payer decides to trust a merchant/payee for reasons at his discretion. The merchant/payee holds a credible promise that credit will be transferred (a sort of check).

I think the only technological problem that we need to address is the first point. We do need to standardize the way requests, promises and confirmations are exchanged. But fortunately, this point is the easiest one. Since the wiki page seems to be rather dated, has any progress been done on this point? It does not seem to be addressed in the latest specification draft (October 2018).

[cyberphone]

Short return on point 3:
There are Web payment schemes which presume that merchants are authenticated like shown in:
#42 (comment)

[nkosi23]

This would only apply for Payee Initiated Credit Transfers. The implementation of such an authorization would be up to the PSD2 financial institution providing merchant services, so I would say that this is out of scope (as suggested to you in the thread you linked).

Payee Initiated Credit Transfers where the merchant's payment processor talks directly to the consumer's bank are different from Pull Credit Transfers. I expect that the former approach would only be used by sensitive businesses who must absolutely ensure that the payment promise returned by the consumer is genuine. For 95% of businesses, having a check is enough (analogy with the piece of paper).

I would prefer that this thread do not go out of topic on whether or not and when merchant authentication is required

[cyberphone]

I would prefer that this thread do not go out of topic on whether or not and when merchant authentication is required

It is possible that I'm misinterpreting this but it seems that the thing I mentioned is under consideration:
https://www.w3.org/blog/wpwg/2018/11/02/tpac-2018-recap/
For the second topic, Generic Payment Tokens, Adrian described the pitfalls of push payment flows: where the user’s bank initiates a payment (e.g., credit transfer) outside of the control of the merchant. Adrian offered an alternative flow where the party that initiates a pull payments returns a (“redeemable”) generic token through Payment Request API. The merchant can subsequently use the token to initiate the payment from the user’s bank. (I believe this is how direct debits work; please comment below if I am mistaken.) Adrian described a vision where merchants would declare through Payment Request API “I accept the generic token payload from the following networks,” and this would enable payment handlers to innovate and support different payment networks.

The scheme I'm working on has no relationship to PSD2. A PSD2 PISP is essentially a fee-based, TTP firewall between the Merchant and the User's Bank. It turns out that this functionality can be achieved using a simpler arrangement; not bringing in new TTPs to the plot.

[nkosi23]

This pattern means simpler integration for merchants (since the returned data is always the same) at the same time it opens up the payment handler landscape.

The point of this is not authorization/authentication in the sense you have in mind. It is purely about standardizing the format of requests/responses using a scalable model minimizing the integration burden of merchants while maximizing opportunities for payment handlers at the same time. But I feel it may be more appropriate to continue this discussion in the thread you linked.

However, incidentally your quote partially answers my question:

We do need to standardize the way requests, promises and confirmations are exchanged. But fortunately, this point is the easiest one. Since the wiki page seems to be rather dated, has any progress been done on this point? It does not seem to be addressed in the latest specification draft (October 2018).

I am however wondering where Adrian's efforts are documented. I like Adrian's approach because it removes for example the need for a merchant to announce its payment details to consumers. The difficulty this caused is that there was then a need to maintain some sort of exhaustive database of payment systems in order to know that when a merchant accepts payment system X, then he must provide such and such payment information to the user (for example IBAN). The redeemable token approach removes such a need, however it introduces the need to develop new payment handling technologies allowing merchants to redeem the token.

I am not really sure if this is totally a better development. Previously, no special tools where required on the side of merchants. All they needed was to have a bank account. Now they also need to have a compatible bank / payment provider. I feel the redeemable token approach would be perfect if it could be used as some sort of extra general purpose payment scheme: a very small database of the most important payment systems (such as bank accounts) and the parameters merchants must announce to accept them is built-into web browsers, while new and innovative payment schemes would use the redeemable token approach.

Thinking about it, I think that Bank Accounts may actually be the only payment method that would require explicit knowledge of its parameters from web browser. Even credit cards fit in the redeemable token approach since a payment handler is always necessary with them.

However being able to accept bank transfers without integration work and without depending on a payment handler is quite a massive and important use case. So I think maintaining explicit knowledge of a few payment schemes in browsers (SEPA, SWIFT, ACH, etc....) may very well be worth the (relatively) small amount of effort required. But I feel like we may actually already be heading in this hybrid direction, which would be awesome.

[cyberphone]

Why would you use a database of payment schemes when you have PaymentRequest? If a merchant announces its support for a SEPA Credit Transfer payment, the corresponding handler (if the user has one) should be possible to select in the PaymentRequest UI.

A question is how and when the merchant's receive account should be introduced. FWIW, in the scheme I'm working with (where the merchant indeed is authenticated), this data is included in a merchant-signed wrapper message holding the received payment token. The wrapper message is subsequently sent to the User's Bank. The result from that should be a signed "receipt", saying that the payment is in progress, making the system independent of whether the actual payment transaction is instant or not.

Using a payment token potentially also impacts tokenization. In my scheme, this part is effectively nullified:
https://cyberphone.github.io/doc/payments/payment-decentralization-scheme-1a.pdf

[nkosi23]

Why would you use a database of payment schemes when you have PaymentRequest? If a merchant announces its support for a SEPA Credit Transfer payment, the corresponding handler (if the user has one) should be possible to select in the PaymentRequest UI.

What I meant is that the browser would maintain a list of well-known payment handlers such as SEPA. This database could be as simple as a plain text data file shipping with the browser.

[cyberphone]

I must confess that I don't understand what you want to achieve. Is it about performing credit transfer in browsers? Personally I don't think this is a workable approach because SEPA SCT is a backend system. When you do a regular wire-transfer in an on-line bank the browser is only used for enabling the user to specify source and destination accounts and finally authorize the payment. No ISO 20022 is needed (at this level NB) either.

I will now step back and let the others give their view :)

Feel free sending me an e-mail if you want to discuss off-list.

[nkosi23]

According to you what is the point of W3C Payments? What will they allow merchants and users to achieve? And which innovations do they bring to the table? I think you may need to clarify this in your head, the W3C draft is however clear.

While I slightly disgressed by courtesy to accomodate your questions, I hope someone will address the gist of the thread, which is providing me the official view on my remarks on the 3 points, as well as details on Adrian's standardisation efforts mentioned above if they are available.

[cyberphone]

Dear @nkosi23 I'm also following various Open Banking API developments like: https://openid.net/wg/fapi/
In those APIs security issues have been top priority while hardly mentioned in the W3C credit transfer spec. This is my sole concern.

A payment token concept would turn the current credit transfer spec upside down. FWIW, I have begun investigating how such a scheme could hook into Open Banking APIs (entirely locally) with the goal of not having to force banks creating yet another road into the banking core.

The PaymentRequest API is quite useful but it doesn't solve the redemption part of a payment, not even for basic card payments.

[nkosi23]

The PaymentRequest API is quite useful but it doesn't solve the redemption part of a payment, not even for basic card payments.

Because it doesn't need to. This concern is out of scope, this is what you need to understand. Moreover this doesn't make the API any less secure, it will be as secure as payment handlers make it.

with the goal of not having to force banks creating yet another road into the banking core.

You make it sound like banks have been leaders in opening up their core. Quite honestly it's about time they move their a***s. The more roads to their core the better, creating a new interface for the PaymentRequest API will not be able to be avoided but it will be a net positive for everybody including banks. And it's not like they lack the financial resources to implement it...

From a different perspective, I do not think it would be appropriate to burden the volunteers-led W3C effort with out-of-scope concerns just to allow banks who are known to be very resource-limited to avoid a one-time $5M investment in tech... that most of them will not even need to make if they do a proper job at opening up their core which would incidentally allow third-parties to implement this type of interface for them and provide them off-the-shelves solutions (and these solutions could implement some of your ideas).

Once this is said, I really think you should open your own issue to discuss your concerns as having this discussion here is sort of hijacking this thread.

[cyberphone]

#74

[nkosi23]

Some additional thoughts regarding my comments on redeemable tokens.

My thinking is that the redeemable token approach requires the merchant to know how to redeem the token (namely how to interact with the API of the payment scheme). This is great as it moves the standardisation of the various payment schemes out-of-band from the PaymentHandlers specification's perspective. However I do think that some major scenarios, including the scenario of the merchant being able to accept bank payment online without software development work should be enabled by the spec.

This can be achieved by having "well-known" payment handlers as I previously suggested, as I think that trying to standardize redemption APIs across payment schemes would end up in a monstruous API.

[cyberphone]

This is great as it moves the standardisation of the various payment schemes out-of-band from the PaymentHandlers specification's perspective

Indeed, this was one of the prime motivations for adopting this flow in Saturn. Another reason is that multiple step payment like Reserve/Actual for automatic gas stations becomes very simple to support.

I think that trying to standardize redemption APIs across payment schemes would end up in a monstruous API

This what Saturn does. IMO, the API is fairly modest but has probably not been reviewed by anybody but me so it could be total crap 😎
https://cyberphone.github.io/doc/saturn/saturn-v3-presentation.pdf#page=10

This can be achieved by having "well-known" payment handlers as I previously suggested

Here I remain skeptical, awaiting a more concrete write-up.

[nkosi23]

Pull Credit Transfers also bring up the question of recurring payments. I am thinking that a minimalist standardization of redemption tokens could be introduced, the rules could be as follow:

• Payment handlers always return a redemption URL (whether the payment is instantaneous as with credit cards and certain bank transfers, or asynchronous like bitcoin)
• we could specify that sending a POST request to the redemption URL should always trigger a credit transfer for the amount authorized by the consumer
• Implementing recurring payments would then simply require sending a POST request to the redemption URL again at appropriate times
• Sending a POST request when the credit transfer was not meant to be reccuring would result in a no-op or 402
• Sending a GET request to the redemption url should always return the status of the credit transfer (whether the transfer is recurring or not)
• In the case of recurring credit transfers, if the credit transfers have been redeemed multiple times, GET requests return an array of statuses.
• then every payment handler would be free to define extra parameters to be included in the POST and GET request to accomodate their specifics

This would enable consistency and provide a single framework that even well-known payment handlers could use.

I also think that a isRecurring flag should be introduced in the Authorization request so that the underlying financial institution can configure the redemption token accordingly. I do not think that there is a need to require the periodicity of the payment to be mentioned. The way I see it, it would be enough to advise the user that they are entrusting the merchant to charge them periodically (as opposed to a one-time payment). Direct Debit mandates work that way and it is just fine.

In terms of security to avoid multiplying parameters, it should be enough to allow merchant to request three types of authorization:

• Issue a credit transfer only once using the token
• Issue credit transferts for an amount inferior or equal to a max amount for which they have requested authorization
• have the right to issue credit transfers using the token without restriction on the amount transfered

I think this should be more than enough. Merchants will be authorized by consumers based on their level of affinity wuth them (no need for technology to define this). Moreover financial institutions will always be able to innovate for example by delaying the clearance of payments having an unusual amount to give the consumer a chance to check them, these innovations would be able to happen out-of-band. But I think my proposition is more than enough even without these innovations considering how real world business is being conducted today and what consumers have proven to be comfortable with.

I therefore see the following parameters:

• isRecurring: boolean flaf
• transferAmount: the amount of the credit transfer to be done today. Will also be used as the default amount for redemption POSTs. Can also be overriden in redemption POSTs provided the amount supplied is inferior to authorizedAmount (so can only be overriden if authorizedAmount has been supplied - which indicates that it is the intent of the consumer to allow the merchant to charge him different amounts in the future)
• authorizedAmount: the max amount that can be transfered in a single transaction

If someone wants to change the default transferAmount, that person must send another payment request to the consumer (the default transferAmount cannot be changed to put it differently).

This will encourage merchants to request one payment authorization per product/subscription and will facilitate the management of these authorizations for consumers. It will be in the best interest of everyone to proceed that way. The benefits for consumers are obvious but for merchants, it will allow them to avoid losing a customer when they could just have lost a subscriber for a specific product. All of this while retaining the possibility to make adhoc payments, however it would not be in their best interest to have a single payment authorization strategy. Maintaining these separations in the mind of consumers will allow merchants to let their customers reconfigure the relationship gracefully without removing the need to break the whole relationship brutally.

[cyberphone]

There's just one snag; something along these lines would not only be a veritable "reboot" of the credit transfer work item, but also likely impact other W3C Payment activities including the recently started https://www.w3.org/securepay/charter.html

Saturn will thus probably be rather alone with the Payment Token concept which is both a blessing and a curse. The following things are currently on the "menu":

• Digital receipts
• Real time account status
• A generic invocation mechanism for the "Physical Web", tentatively based on combining NFC and BLE. The Payment Token concept is completely universal!

[nkosi23]

....would be a veritable "reboot" of the credit transfer work item

Not necessarily, this can potentially be added to the current flow without changing anything else. This mainly affects payment handlers' implementations.

[cyberphone]

To me Payment Tokens represent a quite different path with respect to:

• Request data
• Response data
• Flow
• UI considerations
• Extensibility
• Security/Privacy/Trust model

It would probably be wise calling it Payment Token and run it as a separate work item to avoid the "reboot" fuzz.

[nkosi23]

You may be right, it really depends of how they see things. This is by the way the main reason I started this thread. I am sharing these remarks so that they can comment on each item and tell us how they see things so we can have a clearer picture of where we are going and what they have in mind.

Maybe in the process they'll also see some ideas / perspectives they didn't think about and find valuable. But this is not the main goal. The main goal is to have contributors paint the official picture in light of these remarks.

[cyberphone]

@nkosi23 As you can see there is not a lot of activity in this repository and the state of the excellent PaymentToken idea is unknown @adrianhopebailie

Fortunately a variant of PaymentToken already exists and is fully documented as well.

[adrianhopebailie]

@cyberphone the PaymentToken idea was floated at the last face-to-face.

There hasn't been any momentum yet so any ideas are welcome.

[cyberphone]

@adrianhopebailie From what I can see it should be possible implementing such a thing using PaymentHandler and WebAuth "as is" as well as using PaymentRequest and a native "Wallet" application.

The problem with PaymentToken is that it has "side-effects" which could affect work items like:

• Tokenization
• Secure payments
• Open Banking (in it is intended usage)
• ISO 20022
• The current credit-transfer proposals

I would be happy to help but the above is probably a non-starter for the W3C, so I'd better continue with my own take on the matter. My talk at Trustech2018 in Cannes which covered this topic was quite appreciated so maybe there will some traction this year.

BTW, the security model for PaymentToken is really interesting!

Right now my core interest is getting the following off the ground: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-03. It may look simple but it is a real challenge!

[nkosi23]

@cyberphone You keep framing Payment Tokens as a separate and even conflicting endeavor (apparently in an effort to cast your Saturn project as a drop-in and market-ready alternative), while Payment Tokens actually nicely fit within the current Credit Transfer framework.

This is starting to become annoying as it creates noise and confusion and sorts of hijack this discussion. Can you please refrain from doing that moving forward so that this thread can be focused on building upon the current Credit Transfer framework and within the spirit and scope of W3C Payments.

[nkosi23]

@adrianhopebailie Good to hear, I will then seek to condense all these remarks into a more formal and comprehensive technical proposal (bridging gaps, naming parameters, describing behaviors more exhaustively etc...). Quite busy these days but hopefully I will post this here shortly so that it can be discussed and hopefully get the ball rolling.

[cyberphone]

@nkosi23 could you elaborate on how Payment Tokens would fit into the current Credit Transfer framework? If so, begin with the flow because parameters are not that important at this early stage. It is more on the level "Who is doing What with Whom and Why?" Given the scarcity of information it is possible that Saturn is something entirely different because it has essentially nothing in common with the W3C Credit Transfer framework.

[cyberphone]

@nkosi23 There are also very basic questions that are not answered by the Credit Transfer framework like the authentication of the Merchant. In my take on Payment Tokens, the integrity of the whole system requires that all messages are digitally signed. This is not only only for maintaining technical security, but to cope with AML (fully identified beneficiaries). A difficulty here is establishing "digital trust" in scalable way which why my scheme is based on an enhanced four corner model.

[nkosi23]

@cyberphone The flow wouldn't even change but would remain the one described in the draft spec at 90% at least. I think your real need is to understand the spec (scope etc...) because while I may include a flow diagram at some point, I will not further divert this thread by turning it into an explanation of the spec/ flow.

What's required here is a proposal in terms of normalization, as mentioned in the wiki page quoted in my first post. I've already put forward a number of building blocks but what I'll do now is fill gaps and be more comprehensive.

I think it's important to note that a good understanding of the spec is assumed in this thread, if that's not the case separate threads must be created. The culture on github is to be flexible and accomodate discussions but I think this thread has done its fair share of flexibility (at least for now). For now flebility is turning into confusion/hijacking.

When a good understanding of the spec is assumed, a flow diagram is not that essential for the discussion and task at hand in this thread. It's always useful to have one, but this is more the last thing to do than the first considering our comprehensive context.

However generally speaking everything will be put in the context of the sequencing of actions as is usual with this type of proposal.

[cyberphone]

@nkosi23 In https://w3c.github.io/payment-method-credit-transfer/#payer-initiated-0 there is no authentication of the Merchant(Payee) to the User's bank in step 2/3.

[cyberphone]

@nkosi23 In https://w3c.github.io/payment-method-credit-transfer/#payer-initiated-through-payee one might claim that step 8 represents a Payment Token redeeming. However, this is done through a TTP (and associated security and trust solutions) which is not necessarily how this was supposed to work @adrianhopebailie

[nkosi23]

I will not continue this side discussion as far as I am concerned, this is going in circle and hijacking this thread.

[cyberphone]

You raised the Merchant authentication issue. I claim that Merchants need more than a SEPA bank account in order to accept SEPA Credit Transfer payments on-line. That is, a Merchant should (in some way) be authenticated as a licensed payment partner. Who can perform this authentication? Wouldn't the Merchant's bank holding its SEPA account be a suitable entity in the https://w3c.github.io/payment-method-credit-transfer/#payer-initiated-0 scenario?

[cyberphone]

In https://w3c.github.io/payment-method-credit-transfer/#payer-initiated-0 it might even be possible performing a phishing attack where the destination account would be changed to the attacker's. @CYV

[cyberphone]

@nkosi23 A work item that aims for becoming an International Standard cannot leave out authentication of Merchants to the User's bank (unless there is a TTP in between who presumably vouches for the authenticity/legitimacy of the Merchant).

That this is "impossible" as stated in the Wiki is not based on facts. Lots of systems including Saturn already do that.
@adrianhopebailie @ianbjacobs @mattsaxon @vkuntz

I forgot to mention that authentication is equally applicable in the other direction (step 5/6) as well.