Two significant differences this proposal brings are:
The tag values should now correspond not just about whether a certain payment method is accepted, but also how the merchant or the point of interest accepts the payment method (e.g. by performing Contactless or scanning the merchant’s QR code).
The tagging scheme requires that ALL existing digital wallet applications to be tagged according to their country of origin. e.g. payment:US:google_pay for Google Pay in the United States, payment:IN:google_pay for Google Pay in India (formerly Tez), and payment:CN:alipay for Alipay in Mainland China (to support merchants who also accepts Alipay but for Mainland China customers). More information about this requirement has been thoroughly discussed on the Rationale section of the wiki page.
Through this proposal, the author hopes that payment-specific information on POIs can be further clarified, which may also benefit users by informing how they should prepare to perform payments with
their favourite digital wallet applications.
Please discuss this proposal on its Wiki Talk page.
why we would do this? That is extremely annoying for editors (both in meaning of human mappers and software developed for mapping). And has basically no benefit at all - you can take borders and preprocess data if you need it.
In particular
When one multinational payment service provider, e.g. mobilePay, decided to leave Russia due to economic sanctions and spin off their services into a new, local payment service provider. In this case, batch renaming can be done easier as changes to it may not affect mobilePay merchants in other countries.
is extremely weird, as such tagging is not required to achieve stated goal at all.
This proposal appears to reflect a lot of effort, but unfortunately also appears to draw more from external more “dictatorial” schemes for recording information than it does from other OSM tagging schemes. Especially with regard to the references to “RFC 2119 and RFC 8174” the first of which only appears once on the wiki (on this proposal) and the second appears only three times. In any case the “MUST”, “MUST NOT” and “SHALL NOT” wording is in direct contradiction to the usual principle of “Any tags you like” and the general attitude towards gradually improving tagging schemes over time. I also don’t find reference to external ISO standard particularly encouraging as they are normally out of the price range of hobbyists even if this particular one is freely accessible (for now).
The Scope section appears to be of the impression that the wiki is binding when it comes to how mappers map and this is generally not the case outside of the organised/automated editing guidelines and codes of conduct. This is emphasised in paragraph 4 of the proposal process wiki page. The strict timeline for compliance indicated in the “Compatibility with older OSM map clients” really doesn’t mesh with the way things have been done previously and places quite a burden on volunteers.
Despite or perhaps because of its length it’s not entirely clear how this actually changes the payment scheme and what is considered depreciated by it except by reference to the examples or playing spot the difference between the old and proposed payment pages. IMO what is changing and why should be summarised in the “Proposal” section of this page, which currently appears to be a glossary instead.
This also departs from the on the ground principle as it requires mappers to add information that is unlikely to be signposted in many (most?) cases.
Aside from the concerns raised by @Mateusz_Konieczny I would have difficulty deciding whether to vote for or against this as it stands as what it actually changes is quite buried in the bulk of the text and I would be concerned I was missing something.
After receiving some useful feedback, I decided to temporarily close the RFC period to revise the current proposal. There are some significant changes that are planned to be made, including:
Prefer multiple tagging keys to avoid multiple values, which is still considered as bad practice in OpenStreetMap.
Favoring the distinction between payment instrument (e.g. credit card), service (e.g. Google Pay), and method (e.g. Web Payments API). However, the solution introduced in the future version of this proposal could also apply to other forms of payment, such as distinguishing payment:visa with payment:visa_debit and payment: visa_electron. It is possible for the proposal to be “upgraded” to become simply “Payments V2”, but I will let this decision to come from the next RFC period.
Providing a compromise on handling conflicting trademarks, to allow contributors to add a vast number of local/regional digital wallet trademarks into OpenStreetMap tags, and to keep compatibility with the existing payment scheme.
MediaWiki (the software behind the current OpenStreetMap wiki) allows us to generate a permanent, archived link. Hence, the original version of this proposal will still be available on: Proposal:Digital wallet payments V2 - OpenStreetMap Wiki
As the author of this proposal, I would like to thank the community for sharing useful insights on how the proposal could be suitable for mapping projects according to different electronic payment cultures.