Proposal talk:Digital wallet payments V2

Discussion of the initial version of the proposal (RFC 2023-10-16)

The following comments were received during the RFC period of the first version of the proposal, which is available on https://wiki.openstreetmap.org/w/index.php?oldid=2605153.

The RFC was closed on 2023-12-04 to make way for extensive revisions.

payment:US:google_pay

"payment:US:google_pay for Google Pay in the United States, payment:IN:google_pay for Google Pay in India"

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.

(copy of https://community.openstreetmap.org/t/rfc-feature-proposal-digital-wallet-payments-v2/104960/2 ) Mateusz Konieczny (talk) 14:06, 16 October 2023 (UTC)

If anything, it should be suffixed payment:google_pay:US=* . This shows it is a country variant of the payment system, not a country-unique payment system.
This is relevant to Hong Kong and Macau for Alipay and Wechat Pay. They are different versions from PRC, not entirely compatible. Many restrictions.
—— Kovposch (talk) 15:18, 16 October 2023 (UTC)

OK, then it makes sense in Hong Kong and Macau and places like this. but doing it everywhere is a bad idea Mateusz Konieczny (talk) 08:33, 17 October 2023 (UTC)

Yes, that's why I suggested suffixing. Avoids cluttering the namespace elsewhere.
—— Kovposch (talk) 11:09, 18 October 2023 (UTC)

I slightly agree with this, but how this could resolve the problem of conflicting trademarks (e.g. GoPay in Czech Republic isn't the same as in Malaysia and South Korea)?
—— Reinhart Previano (talk) 05:14, 19 October 2023 (UTC)

I agree with Kovposch, example of this kind of country suffix is place:CN=* --快乐的老鼠宝宝 (talk) 11:11, 22 October 2023 (UTC)

Dictatorial schemes for recording information

Forwarded from https://community.openstreetmap.org/t/rfc-feature-proposal-digital-wallet-payments-v2/104960/3 and https://en.osm.town/@InsertUser/111244969029209329, originally posted by InsertUser (talk)

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.

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.

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 Kovposch (talk) 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.

Persisting disconnect between paying medium, instrument, and service

Moving the method to val isn't a total solution. You have the disadvantages of semicolon multivals.
It should be emphasized eg credit card is a financial instrument, contactless is a physical method, and VIsa is a service. They can be structured accordingly. Eg payment:instrument:service:method payment:app:google_pay:qr_code=* (ignore other issues as I haven't read your first-party vs third-party solution) . This can be ordered for usefulness.
—— Kovposch (talk) 15:35, 16 October 2023 (UTC)

My original concern is whether this could clutter places with excessive tags, like tagging a small cafe with payment:contactless=* and payment:app:google_pay:qr_code=*. I also understand the consequence of using multiple values, including breaking compatibility with existing tagging schemes.
—— Reinhart Previano (talk) 05:14, 19 October 2023 (UTC)

Methods

I don't like how you have a mix of category and unique systems. Eg epc_qr can be some combination of merchant and epc_qr
Specific issues (This ignores whether they should be suffixed or vals):

• contactless : Can you explain what is "the standard Contactless payments as supported by other debit and credit cards" ? Can use eg EMV specifically . Are you trying to distinguish its NFC-A and NFC-B from Felica NFC-F ? Viz for JCB QuicPay . They better be rolled under nfc
• electronic_purses : I'm not sure about whether it should be considered a method or instrument. In either case, I prefer the clearer and simpler stored-value .
• first_party_app : This may have overlap with first_party_app and third_party_app ?

—— Kovposch (talk) 15:48, 16 October 2023 (UTC)

Country networks

I have doubts about the claim "these trademarks are commonly globally recognised and less likely to conflict between countries" . Eg FPS can be  Faster Payments Service , ignoring the relevance of this bank transfer for payment in UK. UPI apparently can be the abbreviation of UnionPay International.
—— Kovposch (talk) 15:53, 16 October 2023 (UTC)

Maybe country networks should be tagged using the country codes?
—— Reinhart Previano (talk) 05:14, 19 October 2023 (UTC)

Closing down the RFC period

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:

1. Prefer multiple tagging keys to avoid multiple values, which is still considered as bad practice in OpenStreetMap.
2. 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.
3. 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 https://wiki.openstreetmap.org/w/index.php?oldid=2605153.

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.

—— Reinhart Previano (talk) 16:53, 4 December 2023 (UTC)