search

w3c / webpayments

The document repo for the Web Payments Working Group
https://github.com/w3c/webpayments/wiki
Other
257 stars 63 forks source link

[Architecture] Payment App is a term used in EMV to describe the applet stored in SC #31

Closed adrianhopebailie closed 8 years ago

adrianhopebailie commented 8 years ago

Migrated from a thread on the Web Payments IG mailing list: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Dec/0039.html

There is not a 1:1 relationship between a payment app and a payment instrument. I will update the documentation because this is misleading.

A payment app is more akin to a wallet but by using this terminology we do away with the fact that the wallet metaphor has not worked in our context.

For example, a user may register a payment app from their bank and this may support payments using all of the payment instruments they have from that bank.

While I recognise the closeness in terminology to EMV apps on a chip but I think the term app is most appropriate for what the component does and is sufficiently generic (and EMV sufficiently specialised a field) that this is not a problem.

halindrome commented 8 years ago

The point I was trying to make in that thread (thanks for moving it here!) is that we should clarify what we are DEFINING so that we can get the right term for it. I propose that we are defining is "One or more pieces of software that act as a conduit between the payer and their various funding sources, enabling the payer to make payments from one or more of those funding sources."

@adrianhopebailie since you wrote the original, is that correct?

dlongley commented 8 years ago

Sounds like a "Payment Agent". I realize we had this terminology before.

You give your Payment Agent your Payment Instrument and they make the payment happen for you.

dlongley commented 8 years ago

Alternatively, you could give your Payment Credential to your Payment App and it executes the payment.

webpayments commented 8 years ago

I note that we are talking about this wiki page [1]. That page talks about 3 different components. The component in question here is the first one, right? Which I don't think is a Payment Agent...

[1] https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web

On Tue, Dec 8, 2015 at 12:15 PM, Dave Longley notifications@github.com wrote:

Alternatively, you could give your Payment Credential to your Payment App and it executes the payment.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webpayments/issues/31#issuecomment-162966739.

-Shane

dlongley commented 8 years ago

"One or more pieces of software that act as a conduit between the payer and their various funding sources, enabling the payer to make payments from one or more of those funding sources."

I don't know if this is a thing that sits between the payer and their funding sources. That sounds like it's just a piece of software that helps you select which funding source to use. That sounds like the Payment Mediator's job.

Instead, this thing sounds like it's a piece of software that uses a funding source (somehow) to initiate a payment. This also better matches the wiki page description here of a Payment App:

"The Payment App facilitates a payment on behalf of the payer using one or more payment methods..."

As an analogy, one simplistic definition of a User Agent could be: "A piece of software that acts as a conduit between the user and a website, enabling the user to view web pages."

It seems like a "Payment Agent" would be a piece of software that enables a payer to make payments using their payment instrument of choice.

dlongley commented 8 years ago

I see payment instrument/funding sources as unique and specific to particular users. Ideally, these would be purely declarative in nature. But, in order to use them, you need this "thing" we're trying to name. In order to understand what this thing is, here's my view of how the relevant parts of the payment process could happen. I refer to this "thing" as a "Payment Agent":

Step 1: Payment Mediator presents payment instruments/funding sources to user.

Step 2: User selects a payment instrument/funding source. It will be tied to one or more Payment Agents. If there is more than one Payment Agent for the selection, the Payment Mediator can let the user pick one or make some kind of smart decision for them.

Step 3: Payment Mediator invokes the Payment Agent passing it the selected payment instrument/funding source and payment request. (Note there may be an installation step if the Payment Agent is not yet installed in the user's browser).

Step 4: The Payment Agent helps the user make their payment using their selected payment instrument/funding source.

webpayments commented 8 years ago

Okay - that seems reasonable. If that is the process, then in some flows isn't the payment mediator also passing the offer / payee information to the Payment Agent so that, for example, a push payment can be initiated?

On Tue, Dec 8, 2015 at 12:44 PM, Dave Longley notifications@github.com wrote:

I see payment instrument/funding sources as unique and specific to particular users. Ideally, these would be purely declarative in nature. But, in order to use them, you need this "thing" we're trying to name. In order to understand what this thing is, here's my view of how the relevant parts of the payment process could happen. I refer to this "thing" as a "Payment Agent":

Step 1: Payment Mediator presents payment instruments/funding sources to user.

Step 2: User selects a payment instrument/funding source. It will be tied to one or more Payment Agents. If there is more than one Payment Agent for the selection, the Payment Mediator can let the user pick one.

Step 3: Payment Mediator invokes the Payment Agent passing it the selected payment instrument/funding source. (Note there may be an installation step if the Payment Agent is not yet installed in the user's browser).

Step 4: The Payment Agent helps the user make their payment using their selected payment instrument/funding source.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webpayments/issues/31#issuecomment-162976490.

-Shane

dlongley commented 8 years ago

Yes, I should have been explicit with that. I modified Step 3 to include passing the payment request itself as well:

"Step 3: Payment Mediator invokes the Payment Agent passing it the selected payment instrument/funding source and payment request. (Note there may be an installation step if the Payment Agent is not yet installed in the user's browser)."

adrianhopebailie commented 8 years ago

I think there is a misunderstanding about my intentions for the relationship between a payment method, payment app and payment instrument.

User's don't care about payment methods and it's arguable whether they care about payment instruments. The purpose of the payment app is to abstract these away. Users who want control over specifically which instrument they use will use apps that give them that choice.

Similarly the payee (merchant and/or their PSP) isn't too concerned about which app the user selects to make the payment, they care what payment methods it supports because they need to support one of these.

sidenote: One exception would be the merchant that has their own app and would like users to use this because they have proprietary data exchanges as part of the payment method that allows them to do things like process loyalty transactions etc. This is effectively a closed loop system where the merchant's app defines it's own payment method which is preferred over generic methods if available. "Available" in this context means the user is using the merchant's app to pay on the merchant's site.

To re-state @dlongley 's steps for clarity:

Pre-steps: The user installs a payment app. On a mobile device this may be through the mobile platform's app store on a desktop it may be through a browser API call initiated when they visited the website of the app publisher. Let's assume the app publisher is the user's bank.

The user has multiple "funding sources"/"payment instruments" through this bank; a VISA debit card, a MasterCard credit card, direct debits from their bank account and the bank's proprietary loyalty points system (let's call it BankBucks).

The payment app (through the registration process) supplies the payment mediator with a manifest that provides, at a minimum, the publisher's origin and the supported payment methods:

In this case the Legacy MasterCard payment method is a very simple protocol where the payment app simply returns the clear PAN, expiry and CVV2 to the merchant however the EMV Tokenised Visa Debit payment method has defined a mechanism whereby the app returns an EMVCo tokenisation scheme compliant token. The bank could have supported a "Legacy Visa Debit" payment method for the Visa Debit card too but chose not to because they feel enough merchants support the tokenised payment method and they don't want to take on the risk of sending the debit card numbers in the clear.

Step 1: The user visits a website, adds some items to a shopping cart and wishes to checkout. The merchant site calls the payment API passing a payment request object that lists the payment methods they support.

This merchant is a rewards/loyalty partner of the user's bank so the supported methods are:

The merchant doesn't support the "Legacy MasterCard" payment method because they have chosen to not put their website in scope for PCI DSS. If they make a call to the payment API and there are no payment method matches then they simply direct the user to a payment page hosted by their PSP where the user is able to make payments using legacy payment methods or even directly through a traditional payments page.

sidenote: We probably need to discuss a way in which the merchant can specify a weighted preference for the supported payment method.

Based on the payment methods supported by the merchant and the payment methods supported by the installed payment apps on the users device, the payment mediator prompts the user to select a payment app to use for the payment (N.B. the user chooses between payment apps not payment instruments, funding sources or payment methods).

Let's assume our user has a variety of apps installed but selects the bank app we described in the pre-steps.

Step 2: @dlongley 's step 2 is not required anymore as the user has already selected their payment app

Step 3: Payment Mediator invokes the Payment App passing it the payment request (trimmed down so that only the data relevant for the payment methods supported by that app are present).

To further illustrate this through examples; on a mobile device the payment mediator will be the mobile OS and the selection of a payment app will be the familiar app selection pattern, on a desktop the browser will likely be the mediator and will prompt the user to select a payment app.

Step 4: The payment app helps the user make their payment using their selected payment instrument/funding source.

The user is now interacting with UI provided by the payment app. In this case it is their bank's app that they selected and the app has prompted the user to login (perhaps through a fingerprint scan on their mobile or an OTP).

The bank's app fetches the latest balance for all of the user's funding sources. The user doesn't have enough BankBucks points for this purchase but is given the option to split the payment and use their points for a portion and pay the balance using an ACH direct debit/their VISA card.

The user decides to use their VISA Debit card to make the balance of the payment and the app makes a call to the bank's tokenisation service for an EMVCo compliant token for that card.

The app returns a response to the website with the details of the payment, a portion paid via BankBucks points and the remainder via the EMV Tokenised Visa Debit payment method.

The merchant takes the response and passes it to their PSP who processes the two payments.

webpayments commented 8 years ago

@Adrian

I just don’t agree that users don’t care about the payment method. They really do care, for reasons of points or loyalty or cashflow or other good reasons.

And I think merchants will care which app gets invoked if the app itself is a strong determiner of which payment method is used (so for example if an app from a specific bank prioritises a particular method from its portfolio), because the cost of those payment methods might well be quite varied.

Nick Telford-Reed e: nick.telford-reed@worldpay.commailto:nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069

From: Adrian Hope-Bailie [mailto:notifications@github.com] Sent: 09 December 2015 05:33 To: w3c/webpayments Cc: webpayments Subject: Re: [webpayments] [Architecture] Payment App is a term used in EMV to describe the applet stored in SC (#31)

I think there is a misunderstanding about my intentions for the relationship between a payment method, payment app and payment instrument.

User's don't care about payment methods and it's arguable whether they care about payment instruments. The purpose of the payment app is to abstract these away. Users who want control over specifically which instrument they use will use apps that give them that choice.

Similarly the payee (merchant and/or their PSP) isn't too concerned about which app the user selects to make the payment, they care what payment methods it supports because they need to support one of these.

sidenote: One exception would be the merchant that has their own app and would like users to use this because they have proprietary data exchanges as part of the payment method that allows them to do things like process loyalty transactions etc. This is effectively a closed loop system where the merchant's app defines it's own payment method which is preferred over generic methods if available. "Available" in this context means the user is using the merchant's app to pay on the merchant's site.

To re-state @dlongleyhttps://github.com/dlongley 's steps for clarity:

Pre-steps: The user installs a payment app. On a mobile device this may be through the mobile platform's app store on a desktop it may be through a browser API call initiated when they visited the website of the app publisher. Let's assume the app publisher is the user's bank.

The user has multiple "funding sources"/"payment instruments" through this bank; a VISA debit card, a MasterCard credit card, direct debits from their bank account and the bank's proprietary loyalty points system (let's call it BankBucks).

The payment app (through the registration process) supplies the payment mediator with a manifest that provides, at a minimum, the publisher's origin and the supported payment methods:

In this case the Legacy MasterCard payment method is a very simple protocol where the payment app simply returns the clear PAN, expiry and CVV2 to the merchant however the EMV Tokenised Visa Debit payment method has defined a mechanism whereby the app returns an EMVCo tokenisation scheme compliant token. The bank could have supported a "Legacy Visa Debit" payment method for the Visa Debit card too but chose not to because they feel enough merchants support the tokenised payment method and they don't want to take on the risk of sending the debit card numbers in the clear.

Step 1: The user visits a website, adds some items to a shopping cart and wishes to checkout. The merchant site calls the payment API passing a payment request object that lists the payment methods they support.

This merchant is a rewards/loyalty partner of the user's bank so the supported methods are:

The merchant doesn't support the "Legacy MasterCard" payment method because they have chosen to not put their website in scope for PCI DSS. If they make a call to the payment API and there are no payment method matches then they simply direct the user to a payment page hosted by their PSP where the user is able to make payments using legacy payment methods or even directly through a traditional payments page.

sidenote: We probably need to discuss a way in which the merchant can specify a weighted preference for the supported payment method.

Based on the payment methods supported by the merchant and the payment methods supported by the installed payment apps on the users device, the payment mediator prompts the user to select a payment app to use for the payment (N.B. the user chooses between payment apps not payment instruments, funding sources or payment methods).

Let's assume our user has a variety of apps installed but selects the bank app we described in the pre-steps.

Step 2: @dlongleyhttps://github.com/dlongley 's step 2 is not required anymore as the user has already selected their payment app

Step 3: Payment Mediator invokes the Payment App passing it the payment request (trimmed down so that only the data relevant for the payment methods supported by that app are present).

To further illustrate this through examples; on a mobile device the payment mediator will be the mobile OS and the selection of a payment app will be the familiar app selection pattern, on a desktop the browser will likely be the mediator and will prompt the user to select a payment app.

Step 4: The payment app helps the user make their payment using their selected payment instrument/funding source.

The user is now interacting with UI provided by the payment app. In this case it is their bank's app that they selected and the app has prompted the user to login (perhaps through a fingerprint scan on their mobile or an OTP).

The bank's app fetches the latest balance for all of the user's funding sources. The user doesn't have enough BankBucks points for this purchase but is given the option to split the payment and use their points for a portion and pay the balance using an ACH direct debit/their VISA card.

The user decides to use their VISA Debit card to make the balance of the payment and the app makes a call to the bank's tokenisation service for an EMVCo compliant token for that card.

The app returns a response to the website with the details of the payment, a portion paid via BankBucks points and the remainder via the EMV Tokenised Visa Debit payment method.

The merchant takes the response and passes it to their PSP who processes the two payments.

— Reply to this email directly or view it on GitHubhttps://github.com/w3c/webpayments/issues/31#issuecomment-163115817. This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.

Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.

dlongley commented 8 years ago

@adrianhopebailie,

User's don't care about payment methods and it's arguable whether they care about payment instruments. The purpose of the payment app is to abstract these away.

I disagree that users don't care about payment methods and I definitely think they care about payment instruments. Certainly in existing payment systems they do.

Before we decide to add another abstraction layer, can you list the benefits of doing so?

From my point of view, it seems like this abstraction has a lot of drawbacks. For example, it potentially makes it more difficult to bootstrap a wallet/browser that doesn't have "Payment Apps" stored in it yet. It makes it more difficult for people to store their instruments/funding sources in a cloud-based service and then use any device they want to make a payment, as the declarative information in the instruments can recommend to the browser/payment mediator default "Payment Apps/Payment Agents" to install and they could be auto-installed and invoked. There are a number of other issues (eg: non-compliance with Rule of Least Power, more difficult to implement automatic updates) that would also be worth considering when looking at such an abstraction. But before we get further into drawbacks, I would like to know what the benefits are.

Knowing the benefits seems like a better starting place.

adrianhopebailie commented 8 years ago

@mountainhippo

I disagree. In the traditional and physical payments scenario a user chooses which payment instrument they'll use to earn points or which funding source to use to manage cash-flow.

They don't care about the payment method. They don't care if their rewards card is a VISA debit card or a closed loop store card. Their perspective is that they have a wallet full of options when it comes time to pay and they pick one, having a good idea of the result of doing so in terms of what they will earn and when the funds will come from.

In the digital world we can offer users a much better experience. We don't want users to pick from a list of traditional payment instruments, we want them to pick from a list of apps which are more intelligent than payment instruments and able to combine payment instruments or help the user select the best one for the job.

Payment method should be insignificant to users as much as most users don't care what protocol is used to fetch a webpage in their browser.

I agree that we need to think about the incentives for payment app publishers in selecting a payment instrument / method if they support many so that apps don't intentionally select instruments/methods that result in high fees for the merchant.

Some ideas in that regard:

  1. Merchants should be able to express the methods they support in order of preference. How we force the selected payment app to follow that is an open question.
  2. Merchants should incentivize users to use the payment methods/instruments that cost them less in fees by offering the user discounted rates. It will be crucial for the payment request message to be able to express different prices per payment method and for the app selection dialogue to express the range of prices that the user will pay if they select each app.
  3. Users are going to use the apps that give them the best experience in terms of usability but also in terms of the benefits they get from using them (loyalty rewards, discounts etc). I expect merchants will begin to publish their own apps in conjunction with their PSPs and users will prefer these when shopping with that merchant because they will be able to process closed-loop payments like loyalty points etc.
ianbjacobs commented 8 years ago

@adrianhopebailie

You wrote: "The bank's app fetches the latest balance for all of the user's funding sources. The user doesn't have enough BankBucks points for this purchase but is given the option to split the payment and use their points for a portion and pay the balance using an ACH direct debit/their VISA card."

While I have heard that the ability to use N > 1 payment method for a given transaction is an important use case, it is not clear whether we should prioritize addressing it at the protocol layer. (It may be possible for a payment app to offer this service out of band.) Are you thinking that N instruments for a transaction should be part of the WG's API?

Ian

adrianhopebailie commented 8 years ago

@dlongley

I disagree that users don't care about payment methods and I definitely think they care about payment instruments. Certainly in existing payment systems they do

I'm not sure if we're on the same page wrt the definition of payment method. In this architecture a payment method is the protocol that is used between payment app and payee to exchange payment data. It defines the format of the payment request and payment response (and possible additional processing the payment app should perform before it can return a response).

When you walk into a store and pick the card you will use to pay do you make that selection based on the messaging protocol that will be used between the POS terminal and your bank? Or based on whether you'll need to put in PIN or signature?

I would assert that you are more interested in who issued the card and what you will get out of using it (loyalty points, rewards, discounts, cash back) or where the funds will come from (credit, bank account, etc).

If you are interested in which payment instrument you use then you'll use payment apps that surface the specific payment instrument as a user choice or use a payment app that only holds a single payment instrument.

Before we decide to add another abstraction layer, can you list the benefits of doing so?

I don't agree that we are adding a layer of abstraction. We are replacing one model (wallets, payments instruments and payment schemes) with another that is more appropriate to the Web (payments apps, a payment mediator and payment methods).

As I have described in the updated wiki here (https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web#definitions), the wallet/payment instrument metaphor doesn't work on the Web.

This model is more appropriate for this architecture as it accommodates the older concepts like physical payment instruments but opens up a far more flexible model for innovation by both the app publishers and PSPs.

ianbjacobs commented 8 years ago

@adrianhopebailie

Your comment above: "In this architecture a payment method is the protocol that is used between payment app and payee to exchange payment data. "

Does not seem to align with the architecture document, which defines payment method as: "A way of paying. A system and set of rules for payments."

I have understood payment method to be the things you say for X in the phrase "At this shop we accept X ". That would include things like "Visa" and "PayPal" and "Samsung Pay". I believe users, merchants, and payment system providers care a lot about visibility of those brands. (I think adding examples to the architecture document (as we've discussed) will help build shared understanding.)

While I am reluctant to do this, here are some terms to consider:

dlongley commented 8 years ago

I've come around to agreeing with @adrianhopebailie's approach for abstracting the details of payment instruments into payment apps. Which means, from my perspective, we may not even need to really talk about payment instruments at all -- we only need to talk about payment apps the payment schemes/methods that they support.

With this in mind, the name "Payment App" is a lot less controversial to me.

adrianhopebailie commented 8 years ago

@ianbjacobs

Your comment above: "In this architecture a payment method is the protocol that is used between payment app and payee to exchange payment data. "

Does not seem to align with the architecture document, which defines payment method as: "A way of paying. A system and set of rules for payments."

That definition needs an update to more closely reflect how "payment method" is being used in the API proposals.

Again, this is not something that directly translates to the physical world metaphor because the discovery of payment methods that are supported and filtering of payment apps based on this is entirely automated (and has no user interaction). The proposals are already talking about identifying the payment methods using a URI, not a very user-friendly label.

For illustration, I wouldn't consider "Visa" a payment method. I'd consider something like "Legacy Visa Credit", "Tokenised Visa Credit", "Encrypted Visa Credit v2" as payment methods that could all potentially be used with the same visa credit card (as payment instrument). In fact, a payment app could support all three or just one.

The payment method that the payment app uses defines what it expects the format of the request to be, how it processes the payment and what the format of the response will be. These will be different for the same payment instrument depending on how it's used (e.g. plain text, tokenized, encrypted, etc.).

I have understood payment method to be the things you say for X in the phrase "At this shop we accept X ".

Yes, but in our architecture this statement is made via a machine-readable payment request. It's not surfaced to the user at all.

That would include things like "Visa" and "PayPal" and "Samsung Pay". I believe users, merchants, and payment system providers care a lot about visibility of those brands.

That is true but the opportunity for branding would be in the app. In the same way as VISA doesn't issue cards but rather force their issuers to put their brand on cards, I'd expect brands that care about this to force apps that want to claim support for their payment methods to have some branding requirements too.

dlongley commented 8 years ago

Also worth mentioning is that in my view a "Payment App" is not a PSP or a Bank -- and it seems like there has been some conflation here or there with those concepts. A Payment App is just a piece of software that helps users register payment instruments/funding sources and then use them (eg: send them/specify them to a PSP) to make a payment. A Payment App specifies the payment schemes/methods it supports and then this can be matched against payment requests by the payment mediator to simplify user selection.

webpayments commented 8 years ago

On 12/09/2015 02:36 PM, Dave Longley wrote:

I've come around https://github.com/w3c/webpayments/issues/11#issuecomment-163365290 to agreeing with @adrianhopebailie https://github.com/adrianhopebailie's approach for abstracting the details of payment instruments into payment apps. Which means, from my perspective, we may not even need to really talk about payment instruments at all -- we only need to talk about payment apps the payment schemes/methods that they support.

+1, @dlongley and I discussed this a bit in the office and the conversation was good for two reasons:

I'll try to elaborate in more depth as time permits.

With this in mind, the name "Payment App" is a lot less controversial to me.

Yes, I was on the fence about 'payment app', but the discussion clarified enough for me and now I'm in favor of payment app w/ a few changes to the definition (to explain what it isn't, primarily).

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Web Payments: The Architect, the Sage, and the Moral Voice https://manu.sporny.org/2015/payments-collaboration/

shepazu commented 8 years ago

Hi, folks–

I also like "payment app", with the caveats described by others.

Regards– –Doug

On 12/9/15 2:52 PM, webpayments wrote:

On 12/09/2015 02:36 PM, Dave Longley wrote:

I've come around https://github.com/w3c/webpayments/issues/11#issuecomment-163365290 to agreeing with @adrianhopebailie https://github.com/adrianhopebailie's approach for abstracting the details of payment instruments into payment apps. Which means, from my perspective, we may not even need to really talk about payment instruments at all -- we only need to talk about payment apps the payment schemes/methods that they support.

+1, @dlongley and I discussed this a bit in the office and the conversation was good for two reasons:

  • It clarified what a payment app was and wasn't (at least in my mind), so that'll help with the definitions.
  • It simplified the interfaces necessary to make the whole ecosystem work, and may have gotten rid of our "decentralized registration" concerns as well.

I'll try to elaborate in more depth as time permits.

With this in mind, the name "Payment App" is a lot less controversial to me.

Yes, I was on the fence about 'payment app', but the discussion clarified enough for me and now I'm in favor of payment app w/ a few changes to the definition (to explain what it isn't, primarily).

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Web Payments: The Architect, the Sage, and the Moral Voice https://manu.sporny.org/2015/payments-collaboration/

— Reply to this email directly or view it on GitHub https://github.com/w3c/webpayments/issues/31#issuecomment-163371670.

adrianhopebailie commented 8 years ago

:+1: I think we're all on the same page here.

There is some interesting work to be done in the realm of open payment methods like Bitcoin so that standards are developed for payment app developers to implement but I'm not convinced that should be done by us or even within the W3C.

Unless there are those still opposed to the name based on it's similarity to EMV smart-card apps I am going to close this issue.

adrianhopebailie commented 8 years ago

There appears to be consensus that we use payment app. Closing this issue.