Proposal:Digital wallet payments V2
| Digital Wallet Payments V2 | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | Reinhart Previano |
| Tagging: | payment=* |
| Statistics: |
|
| Draft started: | 2023-09-14 |
.svg){kind=icon}
This proposal primarily discuss the expansion of the payment tagging scheme which focuses on acceptance of payment apps and services as payment methods.
Due to the large number of payment methods supported in some digital wallet apps, this proposal will use a fictitious Indonesian digital wallet app called mobilePay, abbreviated as mPay, which allow users to pay with 7 (seven) different methods:
- QRIS (national QR code-based payment system and standard) payment QR codes,
- mPay-issued payment tokens (e.g. for public transport),
- a dedicated feature to scan parking tickets from partnering management companies, hence users’ mPay balance will be automatically deducted at the checkout gate,
- an mobilePay membership digital card, which is automatically issued upon account creation, which are scannable and accepted in several retail chains,
- apps, websites, and/or Point-of-Sales systems which asks users to input their mPay-registered phone number, in which users then asked to complete the payment in-app,
- using an external, third-party application which allows users to link their mPay accounts into the external app, as well as
- perform a direct (consumer-to-consumer) transfer between mobilePay accounts, e.g. using mobilePay’s own QR code. Note that the central bank of Indonesia require the sender account to be verified through a know-your-customer (KYC) process to be able to transfer funds across customers.
In addition to mobilePay, this proposal also uses other fictitious digital wallet trademarks: Digicash, iMoney, and eBank; as well as inter-wallet payment service: National Payment Gateway.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Proposal
Definitions
- Application, computer application, or application software should refer to the definition in ISO/IEC 2382:2015, which means the "software that is specific to the solution of an application problem". In this case, a website is still considered as an application as long as the website facilitates in digital wallet transactions.
- Payment service provider is an entity, typically an organization, which provides electronic payment services for users which may be done through applications.
- Digital wallet, not to be confused with electronic purses, is a computer application developed and/or endorsed by the payment service provider which offers its users access to electronic payments as offered by payment service provider. A digital wallet MUST be able to offer and use storage of monetary value (e.g. through top-ups or balance transfer).
- Some loyalty applications may also double down as digital wallet, e.g. for storing loyalty points or cashbacks which may be accepted as another form of payment.
- Multicurrency digital wallet is a digital wallet that offers storage and use of multiple currencies, including fiat currencies, cryptocurrencies, as well as transactionable loyalty points.
- Inter-wallet payment service is a service, offered by a payment service provider, which facilitate transfer across 2 (two) or more digital wallet application services (e.g. mobilePay and Digicash).
Scope
This proposal applies to objects that are eligible to be tagged using payment:* tags, and does not introduce changes to its eligibility. The new propose tags MUST be applied for objects (merchants, facilities, etc.) that supports payment through one or more digital wallet apps and/or inter-wallet payment service as described throughout this proposal.
Rationale
History
In 2020, Reinhart posted a diary to encourage Indonesian OpenStreetMap editors to tag places which supports certain digital wallet mobile applications, most notably GoPay (payment:gopay_id), OVO (payment:ovo), DANA (payment:dana), and LinkAja (payment:linkaja). This was done in addition to adding GPN-based debit cards (payment:gpn_debit) and Indonesian-specific electronic purses, including BCA Flazz (payment:ep_flazz), BNI TapCash (payment:ep_tapcash), and Mandiri e-money (payment:ep_mandiri_emoney). The proposal was informally presented to the “OpenStreetMap Indonesia” Telegram group before added to the wiki, before other contributors attempted to add these new tags into places in Indonesia (see all listed Telegram groups on the OpenStreetMap wiki).
Months after the proposal, the de-facto payment:gpn_debit was then included into JOSM and Vespucci.
It is also important to note that the informal proposal was made when Indonesian authorities as well as payment system association are migrating their existing, QR code-based payment systems into one, which is now known as QRIS (Quick Response Indonesia Standard). A new payment subkey, payment:gpn_qris, was then added into the list. However, the inclusion of this tag may cause some confusion when tagging places which supports a specific digital wallet app.
And for this purpose, the author of this proposal mentions mobilePay or mPay as a fictitious digital wallet describing some of the problems found in tagging Indonesian merchants:
- Not all mobilePay merchants in Indonesia accepts QRIS, hence payment:gpn_qris cannot be used as a drop-in replacement of, for example, payment:mobilepay.
- Some merchants “unofficially” supports payment through mobilePay through account-to-account transfer. Due to regulations set by the central bank of Indonesia, this transfer feature is only available through “verified” or “premium” accounts, which can only be obtained through a know-your-customer (KYC) screening process[1].
- Some OSM contributors might be tempted to add payment:mobilepay=yes, to indicate that the merchant accepts mobilePay, as the merchant has generally accepted QRIS as a form of payment (payment:gpn_qris=yes). There has yet to be a clear guidance on how should payment:mobilepay be added alongside payment:gpn_qris, either for compatibility reasons or others.
- Note that some mobilePay merchants only supports mPay payments through mPay-issued payment tokens or loyalty cards, which means that the merchant does not support QRIS unless if the merchant presents another QRIS code issued by another company/acquirer.
- It would be worthwhile to state the acquirer, the electronic payment service provider who is partnering with the merchant, of the QRIS codes issued by the merchant, as some acquirer may enable additional features which can only be accessed on specific digital wallet applications. For example, mobilePay allow app users to pay mobilePay-acquired QRIS merchants with mobileCoins or mCoins, a form of loyalty points, as well as their buy now, pay later service, mobilePayLater.
- Some Indonesian digital wallet apps including mobilePay are trademarked using generic names, especially in English. This would be confusing as other unrelated companies may use the “mobile pay” trademark in different countries to form a similar digital wallet service.
The current workaround is by adding these tag combinations into the merchant, due to the limited value combinations available for the payment tag:
- payment:gpn_qris=yes if the merchant supports QRIS, followed with payment:mobilepay=yes and payment:mobilepay:gpn_qris=yes if the QRIS code was directly issued by mobilePay as the merchant acquirer.
- ...and an optional ref:gpn_qris=NMID to denote the merchant's National Merchant ID (NMID). Note that NMID is identified by merchant name, owner, and location, hence one merchant can have multiple QRIS codes from different acquirers but bear the same NMID.
- payment:mobilepay=yes and payment:mobilepay:gpn_qris=no if the merchant accepts mobilePay payments other than QRIS, but this does not denote the other payment methods (see Methods 2 to 7 in the mobilePay example) that the merchant accepts.
Expansion of QRIS-like services in other countries
This proposal is further motivated by the expansion of QRIS-like national QR code-based payment systems in other countries, primarily across ASEAN and 
India, which includes DuitNow QR (Malaysia), QR Ph (Philippines), SGQR (Singapore), and UPI (India). QRIS and the aforementioned payment systems are interestingly based on the same EMVCo's payment QR code standard, which also allows them to interoperate which each other. This has already been practiced across ASEAN countries, i.e. DuitNow QR ↔ SGQR, SGQR ↔ Thai QR Payment, Thai QR Payment ↔ QRIS, and so on[2][3][4].
Apparently, Indian OpenStreetMap contributors have already been catching up with UPI, which has now (as of 2023-09-13) been tagged into hundreds of merchants, before I edited the wiki again to document the change. Google Pay formerly Tez) and Paytm in India have converted their QR-based payment stickers to be compatible with UPI, which now potentially introduce the mobilePay merchant problems as mentioned earlier, especially Problem 1 to 4.
Transaction middlemen of Alipay and WeChat Pay
Alipay and WeChat Pay has been accepted in thousands of merchants outside 
Mainland China, 
Hong Kong, and 
Macau. However, the integration of these payment methods often differ by country, and may involve another third-party payment service provider to facilitate the cross-border transaction.
In 
Indonesia, for example, Alipay and WeChat Pay merchants were partially handled by 
ALTO, a well-established local interbank network, before finally replaced with QRIS[5]. When users scan the regular-looking Alipay or WeChat Pay QR codes, they are redirected to ALTO's website before redirected to the respective digital wallet apps through deeplinking. This should be classified as an "indirect payment flow" as the QR code was not directly issued by Alipay or WeChat.
Payment through first-party merchant apps or websites
Some merchants (e.g. retail chains) may offer a dedicated mobile app which users can use to link with their digital wallet accounts. Additionally, some of them do require users to complete their transaction through their website or mobile app, despite in the physical shop. Some of these merchants include:
- Amazon Go (UK, USA)
- Because Coffee, the coffee shop chain of harlan + holden (multiple countries)
While OpenStreetMap has recognized payment:app as a dedicated payment method, there has yet a way to tell users that some digital wallets may be accepted, but though the first party website or app as offered by the merchant. Additionally, contexts such as these may be missing from more than 15,000 merchants tagged (as of 2023-09-13) using payment:app.
EMVCo's merchant-presented and consumer-presented payment QR code standards
EMVCo, the governing entity primarily comprised of Europay, Mastercard, and Visa (EMV), provides the de-facto standard for international, interoperable QR code-based payments, offers at least 2 (two) different mechanisms[6].
- Merchant-Presented Mode (MPM), which is performed by scanning the merchant's QR code, is more commonly implemented in countries, including
Singapore (SGQR). - Consumer-Presented Mode (CPM), which is performed by scanning the consumer's QR code, which may be useful for things such as public transport.
The Digital Wallet Payments V2 proposed schema SHOULD be able to identify the payment modes that the merchant accepts, as differences between the two may require users to perform different actions on the digital wallet app (e.g. pressing different buttons, or entering PIN before or after the scanning process). Additionally, OSM map clients who wish to use this schema MAY utilize this to improve their overall user experience.
Handling generic, multinational, and conflicting digital wallet and payment service trademarks
The case of mobilePay (Problem 6) may have caused confusion between mappers and map client developers to distinguish payment service providers by similar names. Taking the actual GoPay/GOPAY example, it is possible to mark accepting places with payment:gopay_cz=yes in 
the Czech Republic and payment:gopay_my=yes in 
Malaysia. However, there may be cases where, for example, GoPay in Indonesia (payment:gopay_id) decided to expand their operation into 
Timor-Leste. In this case, should Timor-Leste merchants accepting GoPay be tagged with payment:gopay_id=yes to match with the Indonesian counterpart, or create a new tag, payment:gopay_tl=yes?
At the meantime, some of these payment tags refer to existing digital wallets and payment service providers which have been available internationally, including Alipay (payment:alipay), Google Pay (payment:google_pay), GrabPay (payment:grabpay).
The new Digital Wallet Payments V2 schema require ALL existing payment tags related to digital wallet apps (NOT inter-wallet payment services) to be renamed using country codes, regardless whether the service and the trademark is registered in multiple countries or just one. In the case of GoPay in Indonesia, this also mean a rename from payment:gopay_id=yes to payment:ID:gopay=yes, and from payment:google_pay=yes to payment:US:google_pay=yes. This is also meant to anticipate things such as:
- 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.
- mobilePay balances cannot be transferred across countries.
- Two or more multinational payment service provider are registered with the same or similar trademarks (e.g. one in EU, another one in Japan and South Korea, and another one in ASEAN). Unlike the actual case of GoPay/GOPAY, all of these service providers operate in two or more countries.
Note that this rule is not applicable specifically to Alipay and WeChat Pay, as some international merchants accept them but for Mainland China merchants. See Case 6 on Examples.
Compatibility with older OSM map clients
This proposal introduces breaking changes to the Key:payment:* schema, which means that some OSM map clients may no longer be able to capture the acceptance of specific local digital wallet apps. In this case, the author of the proposal (as of 2023-09-13) considers that local digital wallet app information (including payment:gopay_id and payment:ovo) were tagged in less than 1,000 OSM objects, hence compatibility may not be much of an issue due to the low popularity of these tags.
Additionally, legacy payment tags with 1,000 or more OSM objects being tagged SHOULD be kept (but not used for to tag new objects) until 6 (six) months after the approval of this proposal, to allow map clients and contributors to migrate to the new schema.
Tagging
Tag Keys
The tagging rules of this proposal SHOULD be dependent on the two types of payment methods:
- Payment protocols or networks that provide standardised, interoperable ways to perform transactions accross supported financial apps and services, such as by using QR codes. In the case of existing payment methods as recognized by OpenStreetMap, American Express, Mastercard, SEPA, and Visa SHOULD be considered as payment protocols/networks (not individual apps) as they allow multiple bank and non-bank financial services to provide unified transactions.
- Payment apps, which are individual financial apps commonly in the form of digital wallet or electronic/mobile banking application.
Payment protocols or networks MUST NOT be tagged according their country of acceptance, as these trademarks are commonly globally recognised and less likely to conflict between countries. Some of these include:
| Tag Key | Payment Protocol | Country | Taginfo | Remarks |
|---|---|---|---|---|
| payment:duitnow_qr | DuitNow QR | Malaysia
|
Based on EMVCo QR code standard. | |
| payment:fps | FPS (Faster Payment System) | Hong Kong
|
Based on EMVCo QR code standard. | |
| payment:khqr | KHQR |  Cambodia
|
Based on EMVCo QR code standard. Individuals can create custom KHQR payment codes with existing bank accounts without the need to register for a business account. | |
| payment:qr_ph | QR Ph |  Philippines
|
Based on EMVCo QR code standard. | |
| payment:gpn_qris | QRIS (QR Code Indonesia Standard) | Indonesia
|
Based on EMVCo QR code standard. | |
| payment:sepa | SEPA Credit Transfer |  European Union
|
Some merchants also display EPC-standard QR Codes to allow faster payments to SEPA accounts, hence included in this proposal. | |
| payment:sgqr | SGQR | Singapore
|
Based on EMVCo QR code standard. | |
| payment:simple_pay | Simple Pay | Macau
|
Based on EMVCo QR code standard. | |
| payment:thai_qr | Thai QR Payment |  Thailand
|
Based on EMVCo QR code standard. | |
| payment:upi | UPI (Unified Payment Interface) | India
|
Based on EMVCo QR code standard. | |
| payment:vietqr | VietQR |  Vietnam
|
Based on EMVCo QR code standard. Individuals can create custom VietQR payment codes with existing bank accounts without the need to register for a business account. |
However, individual payment apps MUST be tagged using the ISO 2-letter country code (or 3-letter if not found) in the format of payment:<COUNTRY>:<app>, even though the app is available in multiple countries, such as payment:IN:google_pay for Google Pay in India, payment:HK:apple_pay for Apple Pay in Hong Kong, and payment:SG:paypal for PayPal in Singapore. See the rationale for this country-dependent tagging scheme.
Each individual payment apps may introduce nonstandard method of transaction, e.g. by using app-issued payment tokens or so. Indicating what or how the merchant supports payments for this specific digital wallet SHOULD be described by the tagging values.
Tag Values
Each payment protocol may use the following values to indicate the method of performing a transaction. Multiple values (aka. methods) may be tagged using the semicolon notation and recommended to sort the values in alphabetical order (A-Z).
| Value | Method of Transaction | mobilePay Example Case(s) | Real-world Example Case(s) |
|---|---|---|---|
yes
|
The merchant supports payment to this app, but its method is unspecified. This is a generic value and should be replaced with specific methods (e.g. transfer), if possible. | All Methods | - |
scan
|
Scanning a barcode or a QR code as presented by the merchant. This is a generic value and should be replaced with specific methods (e.g. payment_tokens), if possible. | Methods 1, 2, 3, 4, 6, 7 | Scanning barcodes on parking tickets. |
| Tag keys specific to payment networks (e.g. payment:mobilepay=upi) | Utilizing payment methods sanctioned by certain payment networks (e.g. DuitNow QR, QRIS, UPI). Only use this value if the payment app acquires or endorses the merchant to accept these payment method(s), (e.g. when the UPI QR code is issued directly by mobilePay) | Method 1 | Merchants that support QRIS, UPI, or other national QR code systems. |
bluetooth
|
Utilizing Bluetooth (commonly BLE) to trigger payments with the nearby merchant. | None | Cashbac in Indonesia.[7] |
consumer_qr
|
Letting merchants scan the QR code presented by the consumer/customer.
If the merchant accepts QR codes compatible with certain payment networks (e.g. UPI), use the network-specific tag keys and values instead. |
Method 5 | Some DANA merchants in Indonesia with DANA EDCs which can capture barcodes generated from the consumer app. |
contactless (see also payment:contactless)
|
Utilizing the mobile device’s NFC feature to trigger contactless payments. Only use this value when the app supports the standard Contactless payments as supported by other debit and credit cards. | None | Apple Pay and Google Pay merchants across the United States. |
electronic_purses (see also payment:electronic_purses)
|
Using an app-linked physical card to make purchases. | None | Some Ponta (Indonesia, Japan) merchants with physical loyalty cards. |
epc_qr
|
By scanning the merchant-presented EPC QR code to perform a transfer to SEPA accounts. | None | SEPA-accepting merchants. |
first_party_app
|
Using a first-party application (i.e. the merchant’s official app) to pay using this app. | Method 5 | Merchants that still require customers to download their mobile app to make payments. |
membership_id
|
Entering or scanning the Membership ID as generated on the app. If the Membership ID is the same as mobile number, use mobile_number instead. | Method 4 and Problem 4 | Some OVO merchants in Indonesia. |
merchant_qr
|
Letting customers/consumers scan the merchant-presented QR code.
If the merchant’s QR code supports certain payment networks (e.g. UPI) but originated/issued from this specific payment app, use the network-specific tag keys and values instead. |
Method 5 | Alipay and WeChat Pay QR codes (see Case 6 on Examples). |
mobile_number
|
Entering the account-registered phone number to continue the transaction in-app. | Method 5 | Some OVO merchants in Indonesia. |
nfc
|
Utilizing NFC that is available on the device. Use this tag if the merchant supports NFC-based payments other than the Contactless standard. | None | T-Cash (Indonesia), now merged into LinkAja. Some merchants accepted payment through NFC stickers officially known as T-Cash Tap, which is discontinued after the merge.[8] |
payment_tokens
|
A (dynamically-issued) payment token, usually generated by the customers’ app to be presented by the merchant. | Method 2 and Problem 4 | Performing GoPay and LinkAja transactions in Indonesian convenience stores and public transport ticketing gates. |
third_party_app
|
Using a third-party application (e.g. online store apps that are partnering with this merchant) to pay using this app. | Method 5 |
|
transfer
|
Performing a direct, account-to-account transfer between (consumer, not merchant) payment app users. | Method 7 and Problem 2 | Payment through cryptocurrency wallets and WhatsApp. |
Supplemental Key-Value Information
The ref:* subkey may be used with the payment protocols or digital wallet apps to denote the merchant's Merchant Identification Number. For example, ref:gpn_qris to denote the merchant's National Merchant ID (NMID) as registered in the QRIS system. This may be useful to denote the location of the merchant which issues the QR code, and to prevent fraud by re-checking the authenticity of the QR code and the merchant, similar to ref:vatin for VAT identification numbers. This tag is optional and not recommended for tagging small and micro entreprises for privacy reasons.
Example Case 1: Indonesian Barbershop
A barbershop chain in Indonesia allows users to pay, either through a store kiosk or from a mobile app. Both kiosk and the mobile app support the following payment methods:
- Credit/Debit cards
- LinkAja (only from mobile app)
- OVO
- QRIS (redirects to ShopeePay payment page)
- ShopeePay
Note that debit and credit card transactions through the kiosk are possible, but treated as online transactions (requiring users to input CVV and may subject to 3D Secure verification). Cash is no longer accepted by 2020 due to the Coronavirus pandemic and to encourage cashless transaction as part of a national campaign.[11]
When the customer decided to pay through OVO, they will be asked to input their phone number, then continue the transaction in-app as shown. Customers wishing to pay with LinkAja are then redirected to the LinkAja app by deep linking.
| Payment Method | Tag | Correct? | Explanation |
|---|---|---|---|
| Cash | payment:cash=no | Yes | The merchant explicitly no longer accept cash. |
| Credit and Debit Cards | payment:credit_cards=yes;first_party_app | Yes | If the kiosk or mobile app specifically list credit card types (e.g. BCA Card, Mastercard, Visa), use the credit card type-specific tags such as payment:jcb=yes. The inclusion of first_party_app also denotes that the app supports transactions from credit cards as well.
|
| payment:debit_cards=yes;first_party_app | Yes | If the kiosk or mobile app specifically list credit card types (e.g. GPN, Mastercard, Visa), use the credit card type-specific tags such as payment:gpn_debit=yes. The inclusion of first_party_app also denotes that the app supports transactions from credit cards as well.
| |
| LinkAja | payment:ID:linkaja=yes / payment:ID:linkaja=first_party_app | Yes | The most correct way to tag is payment:ID:linkaja=first_party_app since it is exclusive to the mobile app. |
| No | While LinkAja do supports QRIS, it is clear that the QRIS transaction on the merchant's side is handled by ShopeePay, not LinkAja. | ||
| No | Do not combine ambiguous values like yes with specific values.
| ||
| No | Do not use legacy, deprecated tag keys. | ||
| OVO | payment:ID:ovo=yes / payment:ID:ovo=first_party_app;mobile_number / payment:ID:ovo=mobile_number;first_party_app | Yes | The most correct way to tag is payment:ID:ovo=first_party_app;mobile_number since it requires customers to input their mobile number to the kiosk or the mobile app. Sorting the values in alphabetical order is strongly encouraged. |
| No | While OVO do supports QRIS, it is clear that the QRIS transaction on the merchant's side is handled by ShopeePay, not OVO. | ||
| No | No need to duplicate values to denote the methods of transactions accepted by the first party app (e.g. | ||
| No | Do not use legacy, deprecated tag keys. (The author of this proposal originally encourages mappers to tag OVO-accepting merchants as GrabPay-accepting merchants as well, due to the merger in Indonesia.) | ||
| QRIS | payment:gpn_qris=yes | Yes | This merchant clearly supports QRIS. |
| No | QRIS is clearly a QR code-based payment system, so no need to specify the way to perform QRIS transaction (i.e. by scanning). | ||
| No | No recursions. I'm serious. | ||
| No | While it is known that Thai QR Payment customers can transact with QRIS merchants and vice versa, no need to duplicate these tags. | ||
| ShopeePay | payment:ID:shopeepay=yes / payment:ID:shopeepay=gpn_qris;mobile_app | Yes | The most correct way to tag is payment:ID:shopeepay=first_party_app;gpn_qris since ShopeePay is supported through both kiosk and mobile app, and ShopeePay is the acquirer of the QRIS transaction method offered by the merchant. Sorting the values in alphabetical order is strongly encouraged. |
| No | Do not use tag names assigned for different countries (e.g. ShopeePay Singapore tagged to Indonesian merchants). | ||
| No | Do not use legacy, deprecated tag keys. | ||
| Mobile App | payment:app=yes | Yes | For compatibility with older OSM map clients. |
Example Case 2: Austrian Boutique
A fashion boutique located in Austria accepts cash and wire transfers through the SEPA Credit Transfer (SCT) network. However, in order to ease European customers to perform transactions with their mobile banking applications, the store also displays an EPC QR code on the cash register machine.
| Payment Method | Tag | Correct? | Explanation |
|---|---|---|---|
| Cash | payment:cash=yes | Yes | The merchant explicitly accepts cash. |
| SEPA and EPC QR Code | payment:wire_transfer=yes | Yes | Existing payment:* tag documentation includes SEPA into the tag description. Additionally, it is possible for non-SEPA banks to perform a wire transfer to SEPA bank accounts as well. |
| payment:sepa=yes / payment:sepa=epc_qr;transfer / payment:sepa=yes;epc_qr;transfer | Yes | The most correct way to tag is payment:sepa=epc_qr;transfer. While yes is considered redundant by this proposal, it is worth to note that the tag has been informally used to tag SEPA merchants before the publication of this proposal, allowing older map clients to continue considering this as a SEPA-accepting merchant.
| |
| No | While EPC QR may be considered as a "payment protocol", the payment QR code standard explicitly links to SEPA wire transfer, so no need to duplicate these tags. |
Example Case 3: Hong Kong Convenience Store
A convenience store in Hong Kong accepts cash, credit cards, debit cards, Apple Pay, Google Pay, Samsung Pay. It is known that the merchant supports the latest FPS (Faster Payment System) standard, but the acquirer of the payment method is unknown. Their EDC devices also support Contactless, hence the integration with Apple Pay, Google Pay, and Samsung Pay.
| Payment Method | Tag | Correct? | Explanation |
|---|---|---|---|
| Cash | payment:cash=yes | Yes | The merchant explicitly accepts cash. |
| Credit and Debit Cards | payment:credit_cards=yes | Yes | If the EDC device specifically list credit card types (e.g. Mastercard, UnionPay, Visa), use the credit card type-specific tags such as payment:unionpay=yes. |
| payment:debit_cards=yes | Yes | If the EDC device specifically list credit card types (e.g. Mastercard, Visa), use the credit card type-specific tags such as payment:mastercard_debit=yes. | |
| payment:contactless=yes | Yes | The EDC device supports the Contactless standard. | |
| Apple Pay | payment:HK:apple_pay=yes / payment:HK:apple_pay=contactless | Yes | The most correct way to tag is payment:HK:apple_pay=contactless as it is performed via Contactless. |
| No | Do not use legacy, deprecated tag keys. | ||
| Google Pay | payment:HK:google_pay=yes / payment:HK:google_pay=contactless | Yes | The most correct way to tag is payment:HK:google_pay=contactless as it is performed via Contactless. |
| No | Do not use legacy, deprecated tag keys. | ||
| Samsung Pay | payment:HK:samsung_pay=yes / payment:HK:samsung_pay=contactless | Yes | The most correct way to tag is payment:HK:samsung_pay=contactless as it is performed via Contactless. |
| No | Do not use legacy, deprecated tag keys. | ||
| FPS | payment:fps=yes | Yes | The merchant supports FPS. |
| No | Do not assume Alipay or WeChat Pay as the acquirer of the FPS QR code, even though their logos may be displayed alongside the FPS QR code sticker or EDC machine (for dynamically-generated FPS codes). |
Example Case 4: Indonesian Coffee Shop (with mobile app exclusivity)
An Indonesian coffee shop chain requires users to order exclusively through their own mobile app. However, the mobile app only accepts payment through GoPay (via deeplink), OVO (via mobile number), as well as QRIS from Paydia.
| Payment Method | Tag | Correct? | Explanation |
|---|---|---|---|
| Cash | payment:cash=no | Yes | The author of this proposal strongly encourage to tag merchants which do not accept cash payments. |
| GoPay | payment:ID:gopay=first_party_app | Yes | GoPay is only offered from the mobile app. |
| No | If the payment method is only supported using an external app, do not tag with yes to prevent assumption that the customer can perform GoPay transactions directly at the counter.
| ||
| No | Do not assume GoPay as the acquirer even though their logos may be displayed alongside the QRIS QR code. | ||
| No | Do not use legacy, deprecated tag keys. | ||
| OVO | payment:ID:ovo=first_party_app | Yes | OVO is only offered from the mobile app. |
| No | If the payment method is only supported using an external app, do not tag with yes to prevent assumption that the customer can perform OVO transactions directly at the counter.
| ||
| No | If the payment method is only supported using an external app, do not tag with mobile_number to prevent assumption that the customer can perform OVO transactions by entering the mobile number directly at the counter.
| ||
| No | Do not assume OVO as the acquirer even though their logos may be displayed alongside the QRIS QR code. | ||
| No | Do not use legacy, deprecated tag keys. | ||
| QRIS | payment:gpn_qris=first_party_app | Yes | QRIS is only offered from the mobile app. |
| No | If the payment method is only supported using an external app, do not tag with yes to prevent assumption that the customer can perform QRIS transactions directly at the counter.
| ||
| Paydia | payment:ID:paydia=first_party_app | Yes | Paydia via QRIS is only offered from the mobile app. |
| Yes | If the payment method is only supported using an external app, do not tag with yes to prevent assumption that the customer can perform Paydia transactions directly at the counter.
| ||
| Mobile App | payment:app=yes | Yes | For compatibility with older OSM map clients. |
Example Case 5: Public Toilet in Italy
Suppose a €1 public toilet in Itally accepts payments via coins, as well as credit and debit cards through Contactless. The public toilet also displays logos and symbols of Apple Pay and Google Pay, which is clearly known to support payments through Contactless. As a mapper, should I just only tag the facility with payment:contactless=yes, or also include both Apple Pay and Google Pay acceptance via payment:apple_pay=contactless and payment:google_pay=contactless?
While it's non-normative, the author of this proposal recommends not to add both payment:apple_pay=contactless and payment:google_pay=contactless for POIs which are less likely to offer special arrangements (discounts, loyalty rewards, etc.) with Apple Pay and Google Pay, to reduce the redundancy of tags. Retail chains and amusement parks could likely offer that, but not for public toilets, vending machines, and public transports.
Example Case 6: Department Store with Online Order ("Click and Collect") in the US
A department store in the United States allows customers to pay with cash, credit and debit cards, as well as Alipay and WeChat Pay for tourists from Mainland China. The store also offers customers to order and pay online through their website or their mobile app, which also supports direct payments from Apple Pay, Google Pay, Samsung Pay, and others through deeplinks and web-standard Payment Request API.[12] Contactless is supported on their EDC machines, allowing users to pay with Apple Pay, Google Pay, and Samsung Pay in-store as well. Alipay and WeChat Pay is accepted by scanning the merchant's QR code, but not through their website and mobile app.
| Payment Method | Tag | Correct? | Explanation |
|---|---|---|---|
| Cash | payment:cash=yes | Yes | The merchant explicitly accepts cash. |
| Credit and Debit Cards | payment:credit_cards=yes;first_party_app | Yes | If the EDC device specifically list credit card types (e.g. Diners' Club Mastercard, Visa), use the credit card type-specific tags such as payment:diners_club=yes. The inclusion of first_party_app also denotes that the app supports transactions from credit cards as well.
|
| payment:debit_cards=yes;first_party_app | Yes | If the EDC device specifically list credit card types (e.g. Mastercard, Visa), use the credit card type-specific tags such as payment:mastercard_debit=yes. The inclusion of first_party_app also denotes that the app supports transactions from credit cards as well.
| |
| payment:contactless=yes | Yes | The EDC device supports the Contactless standard. | |
| Mobile App or Website | payment:app=yes | Yes | For compatibility with older OSM map clients. |
| Alipay | payment:CN:alipay=yes / payment:CN:alipay=scan / payment:CN:alipay=merchant_qr | Yes | The merchant supports Alipay, but for Mainland China customers. This is also to disambiguate Alipay customers across different countries, such as payment:SG:alipay for Singaporean customers of Alipay/Alipay+. The most correct way to tag is payment:CN:alipay=merchant_qr. |
| No | |||
| No | Do not use legacy, deprecated tag keys. | ||
| Apple Pay | payment:US:apple_pay=contactless;first_party_app | Yes | The merchant accepts Apple Pay through Contactless as well as website and mobile app APIs. |
| No | Do not use tag names assigned for different countries (e.g. United Kingdom Apple Pay tagged to US merchants). | ||
| No | Do not combine ambiguous values like yes with specific values: contactless and first_party_app.
| ||
| No | Do not use legacy, deprecated tag keys. | ||
| Google Pay | payment:US:google_pay=contactless;first_party_app | Yes | The merchant accepts Apple Pay through Contactless as well as website and mobile app APIs. |
| No | Do not use tag names assigned for different countries (e.g. Indian Apple Pay, formerly Tez, tagged to US merchants). | ||
| No | Do not combine ambiguous values like yes with specific values: contactless and first_party_app.
| ||
| No | Do not use legacy, deprecated tag keys. | ||
| Samsung Pay | payment:US:samsung_pay=contactless;first_party_app | Yes | The merchant accepts Samsung Pay through Contactless as well as website and mobile app APIs. |
| No | Do not use tag names assigned for different countries (e.g. Indonesian Samsung Pay, now linked to DANA (payment:ID:dana), tagged to US merchants). | ||
| No | Do not combine ambiguous values like yes with specific values: contactless and first_party_app.
| ||
| No | Do not use legacy, deprecated tag keys. | ||
| WeChat Pay | payment:CN:wechat=yes / payment:CN:wechat=scan / payment:CN:wechat=merchant_qr | Yes | The merchant supports WeChat Pay, but for Mainland China customers. This is also to disambiguate WeChat Pay customers across different countries. The most correct way to tag is payment:CN:wechat=merchant_qr. |
| No | |||
| No | Do not use legacy, deprecated tag keys. |
Rendering
The provisions made on this proposal SHOULD NOT affect the rendering of maps in standard map styles (standard, cycling, public transport, topographical, etc.). It should be made useful when map client users wishes to reveal more information about specific points of interests.
Features/Pages affected
This proposal will significantly affect the Key:payment:* wiki page. To make sure that the documentation is not flooded with vast new tag keys from various digital wallet apps, it is recommended to move them into country-specific pages, such as Key:payment:US:* to handle United States-specific digital wallet apps.
External discussions
Comments
Please comment on the discussion page.
- ↑ https://www.bi.go.id/id/publikasi/peraturan/Pages/PBI-200618.aspx
- ↑ https://www.mas.gov.sg/news/media-releases/2023/launch-of-cross-border-qr-code-payments-connectivity-between-singapore-and-malaysia
- ↑ https://www.bot.or.th/en/financial-innovation/digital-finance/digital-payment/cross-border-payment.html
- ↑ https://www.bi.go.id/en/publikasi/ruang-media/news-release/Pages/sp_2423222.aspx
- ↑ https://keuangan.kontan.co.id/news/ini-penjelasan-alto-terkait-operasi-alipay-dan-wechat-pay-di-grand-indonesia
- ↑ https://www.emvco.com/emv-technologies/qr-codes/
- ↑ https://cashbac.com/en/how-to-use
- ↑ https://www.electronicpaymentsinternational.com/news/telkomsel-to-launch-nfc-enabled-mobile-payments-service-in-indonesia-191015-4697007/
- ↑ https://instore.blibli.com
- ↑ https://desty.menu
- ↑ https://snki.go.id/gerakan-nasional-non-tunai/
- ↑ https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API