Talk:Key:payment:*

payment:app ??

How to map the payment via smartphone-app ?

It depends on which kind of application/circuit are you using; you should probably propose something like: payment:nameoftheapplication=yes --Frafra (talk) 17:46, 17 March 2018 (UTC)

Agree with the need, not sure that spelling out each app is manageable. Example: The major local bike_rental system accepts their own Android and iOS app as payment. The renter has to download that app from one of the app stores and create an account, but once authorized, that app is only valid to perform this one function. There are already several bike_rental systems (both docked and dockless) operating in San Francisco, along with several forms of electric scooter rentals. Each has its own payment app and this is just for low speed modes of transportation. We will grow old and grey before we could record all of these. I think something simpler like payment:operator_app tells the end user they need to be prepared to download a vendor specific smartphone app without the OSM contributor community trying to assume responsibility to accurately manage all of this rapidly changing data. --AndrewSnow (talk) 02:54, 25 April 2018 (UTC)

I guess that there are two types of app payments: through digital wallet app or through the merchant's app. I agree to add the app's name under the payment: tag, but I recommend using country prefixes when the app is available in only one country to avoid trademark conflicts with other countries. I have added some examples on my diary entry and this this post as a proposal to classify Indonesian payment systems in OpenStreetMap. -- Reinhart Previano (talk) 02:54, 25 April 2018 (UTC)

payment:cash=*

In planet file from 2010-09-01 the key is only used two times. The tag is redundant, use payment:coins=* and payment:notes=* instead. Adjuva 00:31, 10 September 2010 (BST)

maybe because in contrast to coins and notes it was never noted on the wiki page. i see no problem with using cash as a shortcut for coins and notes. actually the separation is only because of vending machines. -- Flaimo 18:53, 16 March 2011 (UTC)

> actually the separation is only because of vending machines

That's it --Pyrog (talk) 16:41, 6 May 2020 (UTC)

Nowadays it has over 150 000 uses, distinction matters almost entirely for ending machines. See https://taginfo.openstreetmap.org/keys/payment%3Acash Mateusz Konieczny (talk) 10:04, 9 April 2022 (UTC)

I want to add that the tag cash=no is used by several stores and venues that are cash-free (but not money-free). --Christoffre (talk) 19:36, 9 April 2022 (UTC)

Accepted coins or notes

Some contributors use the following tags (probably for vending machines):

• payment:coins=10c;20c;50c;1€;2€
• payment:notes=5€;10€;20€

What should be the correct format ?
Some users add spaces.
How to specify cents ?

• 10 c
• 10c
• 10ct
• 0.10€

I prefer the last because cent is not a currency.

--Pyrog (talk) 16:53, 6 May 2020 (UTC)

insufficient tagging scheme

this tagging scheme can't always be used to map, if a payment method is explicitly NOT available.

example:

instead of payment:credit_cards=*mastercard;visa;diners_club;american_express;discover_card

it would be better to use:

payment:visa=*yes | no, payment:mastercard=*=yes | no, …

basically the same method used for different fuel types when mapping fuel stations (fuel:octane_91=yes,…). only yes | no values should be used. Flaimo 11:36, 9 January 2011 (UTC)

I agree. Lulu-Ann

I would like to change the information on the wiki page to a fixed yes/no/interval list (as stated above). any objections? -- Flaimo 19:16, 15 March 2011 (UTC)

The old use is still by far more common (ten times more uses of payment:credit_cards=* than payment:mastercard=*), so it should still be documented, even if with reasoning why it's not adequate. Alv 16:08, 6 September 2011 (BST)

Resolved: Not common anymore - see https://taginfo.openstreetmap.org/keys/payment:credit_cards#values Mateusz Konieczny (talk) 10:05, 9 April 2022 (UTC)

maestro

if i read it correctly, than "EC" and "Maestro" are the same thing: http://en.wikipedia.org/wiki/Maestro_%28debit_card%29 . if that is the case we should eliminate "EC" since it is only a synonym used in germany. Flaimo 23:37, 9 January 2011 (UTC)

"EC" and "Maestro" are not really the same. "EC" and "Girocard" is more or less the same. "Girocard" is the new standard for the "old" EC-Cards. Most EC-cards or Girocards does also have the Maestro Logo and the Maestro function. But there are also many Maestro-Cards without EC or Girocard function. Most EC oder Girocard accepting shops does not accept cards which have only the Maestro function. Therefore a further tag payment:girocard=* should be used for shops which accept EC or Girocard and not accept cards which have only The Maestro function. Freestyle1984 - 6 September 2011

charging stations

The tag payment:contractID=* isn't correct, it should be payment:ref. This means the number from the charging station, a contract number identifies the user who uses the charging station. And please, if you introduce a new tag without discussion, at least wearing a corresponding notice at the page charging station. User 5359 20:16, 10 February 2011 (UTC)

"contractID" is the name of a billing method. [1] Lulu-Ann

Wrong: German Zitat aus dem Dokument: "Zur Identifikation halten Sie bitte Ihre Contract-ID sowie Ihr Kennwort bereit. Zusätzlich geben Sie bitte die Ladepunktnummer an, welche sich seitlich an der Ladesäule rechts oberhalb der Steckdose befindet." English Quote from the document (Google translation): "For identification, please have your Contract ID and password ready. In addition, please provide the loading point number, which laterally at the charging station is right above the outlet." The correct term was payment:ladepunktnummer or payment:ref filled with the loading point number not payment:contractID (a contract number identifies the user who uses the charging station).

it's still wrong. if I interpret the PDF right, RWE charching stations only work for RWE customers. so "contractID" isn't a payment method, but rather an authentication method, since the payment is done later on by money transfer from your debit account or credit card. mapping those charging stations together with an operator tag should be enough. if it would be a generic charging station accepting different brands, then we would have to rethink the payment tags. so i will delete it from the list when I'm rewriting the wiki page. -- Flaimo 15:52, 16 March 2011 (UTC)

tolltag payments

I'd suggest we add payment:tag=operator1;operator2;.... as one of the payment options to the wiki page. Basically there are lanes, where you can use a tolltag on tollbridges. There are also car parks that will accept tolltags for payment and let you automatically in and out without getting a parking ticket. Marlow 13:12, 22 February 2011 (UTC)

if you mean something like e-zpass in the U.S. i would tag it payment:e_zpass:yes -- Flaimo 15:55, 16 March 2011 (UTC)

credit cards issued by certain banks only

While tagging payment options on automated, unmanned fuel stations, I noticed a small text next to the logos of accepted credit cards: "only cards issued by a Finnish bank". (There's also payment:notes=yes.) How to tag? Alv 16:03, 6 September 2011 (BST)

This is a valid one in Brazil, several banks supports only their special credit or debit cards in their ATM's and some supports only Brazilian issued cards - EVEN IF ACCEPTING INTERNATIONAL SYSTEMS SUCH AS VISA, MC OR MAESTRO. I havn't ventured into tagging payment forms yet (maybe other than a few telephones if they accept prepaid cards or coins) --Skippern 17:05, 7 September 2011 (BST)

Meal Vouchers

I started using payment:meal_voucher = yes to describe if the activity accepts payment with vouchers like Ticket Restaurant or Edenred. Perhaps should be needed to further specify the brand. --Sarchittuorg (talk) 19:12, 30 March 2013 (UTC)

Local currencies

According to Wikipedia there are around 2500 local currencies world wide, some of which are accepted in hundreds of shops. I would like to start mapping those shops, so what I came up with is payment:local:<name>=yes. Are there any objections agains doing it like that, or any suggestions to improve? Where should that be documented/configured so it is usable also by other tools?

I had the same question in my area. I started a discussion on the mailing-list for Belgium here : https://lists.openstreetmap.org/pipermail/talk-be/2015-February/007030.html --Julienfastre (talk) 20:28, 23 February 2015 (UTC)

We are also launching a local currency in my town (Bel Monnaie), and I would like to use OSM to map the shops which take it. However we are starting with electronic money using a plastic card first (with a QR code + PIN number), before printing notes, because it's simpler to handle. Therefore I'm wondering how to express this distinction. Also, shouldn't it be listed in the currencies (something like a subspace of the ISO names, like, currency:XLC:BEL=yes ?)? Mmu man (talk) 17:26, 23 February 2016 (UTC)

For info, I started to use the tags proposed here User:FrViPofm/Key:local_currency to add local currencies in Belgium (User:Vucodil/Local_currencies_in_Belgium) --Vucodil (talk) 13:41, 11 November 2019 (UTC)

Too complicated

Why not simply use payment=*=method1;method2;method3... and, for unsupported options, no_payment=*=method1;method2;method3...? A few known standard values could be defined, but the set would always be open and changing (imagine all payment options available in the world...). This way would facilitate mapping and usage of this information in applications.--Fernando Trebien (talk) 18:00, 3 May 2014 (UTC)

Using a value list on keys tends to create quite a mess, just look at the current values for payment, because there can be different ordering for the same set, and it's not as easy to parse and/or extend. Mmu man (talk) 16:25, 23 February 2016 (UTC)

contactless payment only

Some vending machines accept credit/debit cards, but only as a contactless payment [2] method, i.e. there is no "swipe" or "chip+pin" physical interface. Is there a way to tag this? E.g. here: [3].

If not, perhaps payment:contactless would be appropriate, as this method can be linked to a credit/debit card, but also to keyfobs etc. The tagging would be similar to credit_cards, as the processor is also Visa/MC/etc, like with other electronic "cards".

According to wikipedia:Contactless smart card#Contactless_bank_cards, they have separate brands for each and every contactless variant of their cards. So to be absolutely accurate, you would need to tag these (based on payment processor): payment:expresspay=yes + mastercard_contactless=yes + payment:visa_contactless=yes + payment:quickpass=yes + payment:quicpay=yes + payment:rupay_contactless=yes + payment:zip=*. One would be tempted to write payment:contactless=only, but what do you add if it only accepts contactless and coins, but not chip+pin cards? Bkil (talk) 15:21, 3 November 2018 (UTC)

Join sections Debit and Credit cards

Some of the mentioned cards in both section could debit or credit, depending on bank settings. For example Visa Classic and MasterCard Standard could be debit only cards. I have one such card. I propose to join sections Debit Cards and Credit Cards into one - "Bank Cards". If some of mentioned card types are 100% debit only, it could be specified in Comment section. OverQuantum (talk) 16:40, 16 November 2014 (UTC)

Yes, please. Bkil (talk) 15:15, 3 November 2018 (UTC)

payment:token_coin

What do you think about the tag payment:token_coin=X? There is now a discussion in the German forum [4]. For example, to pay for parking, at charging stations or in laundromats? See also [5] RoGer6 (talk) 18:45, 22 June 2016 (UTC)

payment:token

I have filled the definition of "token". I want to ask for correction. RoGer6 (talk) 00:15, 26 June 2016 (UTC)

Payment:cardlock

I don't know how it is the rest of the world, but in Canada and (to a lessor extent) the United States have cardlock gas stations, which allow customers with special post-paid cards issued by that chain to purchase fuel at designated cardlock-only unattended pumps. They are preferred by by commercial drivers and often found by major highways. Tagging these properly is critical because while most are located adjacent to conventional gas stations, some (particularly those in the CO-OP network) are built in sparsely populated areas where it would be less viable to operate a staffed station, and they are effectively useless for those without the appropriate card. We discussed tagging them as access=private on Talk-ca so that they would hopefully be ignored by any GPS units, but it many be best to create a new tag to accommodate them. There are several networks, but since with one exception they are limited to one or two brands I don't think it's necessary to create a separate tag for each. --Sammuell (talk) 03:53, 11 August 2016 (UTC)

At Germany there is a similar concept tankpool24. The situation is exactly the same: You cannot get any fuel as long as you are not member (have a customer card). I support your proposal to tag them access=private. But as payment I propose to use an individual tagging, which is payment:tankpool24=yes/no along with payment:credit_cards=no, payment:debit_cards=no and payment:cash=no. --U715371 (talk) 13:26, 11 August 2016 (UTC)

payment:coins:max

Would adding such a tagging method be useful? In my city, vending machines that sell public transport tickets accept coins up to a certain amount, and require using cards beyond that amount. I suppose that "payment:coins:max=50" would be the right way to convey that info, wouldn’t it? Bxl-forever (talk) 10:45, 16 July 2017 (UTC)

It is not clear from your wording what max should mean. I recommend introducing more specific tags, here are a few examples that come to mind (but do look up other synonyms as well before deciding)

• payment:coins:max_count,
• payment:coins:max_total_count,
• payment:coins:max_count_per_denomination,
• payment:coins:max_amount,
• payment:coins:max_total_value (I guess the last two would need currency specification as well, but defaulting to the local currency also sounds reasonable)

A related restriction is that certain simple vending machines only accepts a subset of all coins and/or banknotes. What should be the scheme for these? payment:coins:50HUF=yes and payment:coins:100HUF=yes along with or instead of payment:coins=yes? Or perhaps payment:coins=50HUF;100HUF? Alternatively payment:coins:accepted=50HUF;100HUF?

Another related restriction is when a place only accepts credit and debit cards above a certain sum. It could be tagged something like payment:debit_cards:min_amount, but we should definitely unite the wording before starting to use it.

Bkil (talk) 11:25, 16 July 2017 (UTC)

Thanks for this. Yes, I meant max_total_value in this case but your other suggestions also make sense for other cases. Bxl-forever (talk) 11:53, 16 July 2017 (UTC)

Cryptocurrencies

There are more and more different crypto-currencies, 1025 at the moment. Using Bitcoin is expensive (this will hopefully get better soon) and there are some new alternatives like Dash which are getting more popular. Indicating all of them with a separate subtag of payment might be cumbersome, and it's likely that there will be payment processors in the future that accept many of the popular cryptos. Although most cryptocurrencies have three letter code similar to the fiat currency ISO codes, there are also problems with them, sometimes it's confusing like in the recent case of Bitcoin Cash and its BCC / BCH debate.

I suggest to indicate cryptocurrency acceptance with payment:cryptocurrencies=yes and the acceptance one particular crypto with payment:cryptocurrencies:bitcoin or payment:cryptocurrencies:dash (and mark payment:bitcoin deprecated).

What do you think? --AndrasFuchs (talk) 10:15, 1 August 2017 (UTC)

I agree on the previous idea and I would add the following, what if instead of using a structure like payment:cryptocurrencies:bitcoin we use payment:cryptocurrencies:btc as the number of cryptocurriencies keep growing, using names can be confusing. Generally if you use a crypto you know the acronym.

How do we proceed? --Miguelvalenciav (talk) 02:23, 28 September 2020 (UTC)

Note that we have Proposal process for creating pages for unused tags and ones without support. Deleting description of actually used tags and adding description of tags that noone uses is not a good idea - I just reverted change that described nonexisting and unused tags as standard method. Mateusz Konieczny (talk) 19:26, 28 September 2020 (UTC)

There is currently a proposal in progress here. Feel free to join the discussion!

-- Andrasfuchs (talk) 22:45, 29 August 2021 (UTC)

Resolved: Solved by https://wiki.openstreetmap.org/wiki/Key:payment#Cryptocurrencies Mateusz Konieczny (talk) 10:09, 9 April 2022 (UTC)

payment:OV-Chipkaart

The key should be written payment:ov_chipkaart. User 5359 (talk)

payment:money_order

This key already exists 26 times and is also listed as official on the Russian translation of payment. (see https://en.wikipedia.org/wiki/Money_order) Is that a payment method? (on german Zahlungsauftrag https://de.wikipedia.org/wiki/Zahlungsauftrag oder Überweisung) User 5359 (talk)

A "Überweisung" corresponds to payment:wire_transfer. I'm not sure if there is a direct equivalent to a money order in Germany. --Mueschel (talk) 07:16, 24 July 2018 (UTC)

payment:invoice

This key already exists 11 times. For me this is not a payment method but a request for payment. I would like to define them as faulty on the wiki page. User 5359 (talk)

I'd say this is a kind of payment: You don't have to pay on the spot (like with credit card or in cash), but they hand you an invoice to be payed later / the same day but in a more convenient way. --Mueschel (talk) 07:19, 24 July 2018 (UTC)

payment:online

There is a new tunnel in Iceland, that can be prepaid online ONLY. So, it would be tagged as payment:online=https://tunnel.is

Ambiguous subkeys

This tagging scheme based on snake_case subkeys assumes that payment systems have globally unique names, or that data consumers will perform spatial queries to distinguish one payment system from another with a similar name. There is some potential for naming conflicts with this approach:

• 90677388 resolves a near-miss between the I-Pass electronic toll collection system in Illinois and the iPASS contactless smartcard in Taiwan. More than one mapper had mistakenly conflated the two, probably based on existing usage of payment:ipass=*, when attempting to normalize payment:I-Pass=* to normal key spelling conventions. Even adding the hyphen is imperfect: the iPASS website is at i-pass.com.tw.
• The cheekily named Cash App is often known as simply "Cash", conflicting with payment:cash=*. I don't know if anyone has tagged something with payment:Cash=*, only for it to be normalized to payment:cash=* by someone unfamiliar with the app.

If a mapper needs to indicate an obscure local or regional payment method, how should they clarify the specific payment method in a machine-readable way and avoid naming conflicts? Some electronic toll payment systems have accounts and transponders specific to a single toll road or bridge, so I'm not sure data consumers could count on this wiki to do a great job of coordinating and documenting them. For simpler keys like sport=*, denomination=*, and destination:ref=*, some mappers have coined *:wikidata subkeys, but it would be awkward for a payment:openstreetpay:wikidata=* subkey to clarify the parent key rather than the value.

 – Minh Nguyễn ^💬 06:15, 10 September 2020 (UTC)

• • It should be payment:cash_app=*, not payment:Cash=*. Usually "app" or similar is not added but in this case it is too confusing otherwise Mateusz Konieczny (talk) 08:35, 10 September 2020 (UTC)

It could be possible to insert a country code infix in between payment:*=* and the system suffix, similar to ref:*=*. Ie, payment:TW:iPass=* and payment:US:I-Pass=* (could even be payment:US-IL:I-Pass=* to cater for subdivisions as in other keys}. About the format, frankly I don't understand why every "electronic purse" has to be underscore-prefixed with payment:ep_*=* either, since the account (eg EP) and medium (app, card, etc) are different (which should be handled in a smarter manner). But what's the problem with payment:wikidata=*? ---- Kovposch (talk) 12:05, 10 September 2020 (UTC)

payment:wikidata=* would go nicely with payment=X;Y;Z, but there seems to be a convention here of using subkeys instead of a single payment=* key in order to potentially qualify each payment option with some additional details like a time interval. With a single payment=* key, we could use payment:conditional=* to express those time intervals, but there isn't a great way overall to cross-reference values between two keys that are set to lists of multiple values. It's too bad OSM's data model has no natural way to express an array of key-value dictionaries (though some mappers have tried with syntaxes like foo:1:bar. – Minh Nguyễn ^💬 20:03, 10 September 2020 (UTC)

I understand that. My question was coming from how awkward payment:*:wikidata=* may be. I feel better about it now. ---- Kovposch (talk) 07:44, 11 September 2020 (UTC)

In case I forget and for everyone's reference, there's at least Proposed features/Scheme for local payment systems abandoned. ----- Kovposch (talk) 09:02, 20 April 2021 (UTC)

@Triomphe346: Is that a proposal or existing usage? I suggesting using payment:CN:ETC=*, not payment:cn_etc=* (0 instances). See above, and cf place:CN=*. https://wiki.openstreetmap.org/w/index.php?title=Key:payment:*&type=revision&diff=2473291&oldid=2469931 --- Kovposch (talk) 15:55, 3 February 2023 (UTC)

@Kovposch: Thanks for the suggestion. It's a proposal and I agree with that payment:CN:ETC=* seems to be better. Actually I followed Wiki, which says "Two schemes are in use right now, 'payment:ab_servicename' and 'payment:AB:servicename' ", and it seems outdated. And two more questions here: 1. Is it required to use lowercase? I see all listed subkeys are in lowercase. 2. I didn't see any sample of 'payment:AB:servicename' listed in the wiki page, is it proper to list payment:CN:ETC=*? --Triomphe346 (talk) 18:14, 3 February 2023 (UTC)

1. Country code is a standard format where uppercase should be used. So you should use payment:CN:etc=*.
2. I don't see any examples for * payment:country_service either? It is correct to include if you start using it.
Worse, it is not differentiable from other service names with spaces. Eg "nc" in North Carolina's payment:nc_quick_pass=* is the same as New Caledonia . The common word "my" in payment:my_pertamina_app=* conflicts with Malaysia.
--- Kovposch (talk) 20:30, 3 February 2023 (UTC)

Could we use "payment:XX=only"?

Sometimes the store only can use certain kind of payment, but according to the Key:payment#Values, value "only" is not allowed.

But "only" is common in osm data. So I think whether we can modify the wiki description to allow value "only"? 快乐的老鼠宝宝 (talk) 06:39, 16 August 2021 (UTC)

1. It is not "not allowed", only what's documented.
2. Have you read Key:payment#Showing_that_the_list_of_accepted_payments_is_complete? payment:others=no allows multiple means to be completely listed out. payment:*=only would be limited to 1, not as extensible as payment:*=yes + payment:others=no.

---- Kovposch (talk) 11:07, 16 August 2021 (UTC)

*=surcharge

Places which accept credit cards may charge a surcharge to use a card vs other payment methods (cash) which would have no surcharge. So I'm suggesting using payment:*=surcharge to indicate yes payments via that method are accepted but will incur a surcharge. --Aharvey (talk) 03:29, 27 April 2022 (UTC)

This may conflict with payment:*=only and payment:*=interval. payment:*:fee=yes (as an extra) would be more extensible. Kovposch (talk) 08:20, 27 April 2022 (UTC)