Hi @Taya_S, thanks for raising this and I’ll be as thorough as I can. I wanted to say this has been a learning experience for me and I’ve really enjoyed getting to understand OSM better. However I do apologize for perhaps making a few mistakes as I went and I really appreciate the support and guidance.
My relation to MoneyBadger: I’m Ben Blaine, Head of Growth at MoneyBadger, a Bitcoin Lightning payments company in South Africa. I should have disclosed this affiliation explicitly from the start, that’s on me. I just set my username to MoneyBadger / Ben Blaine but realise now that’s not enough context.
How I ended up here: I’m relatively new to OpenStreetMap. I was directed to engage with OSM by the BTC Map community (btcmap.org), which pulls currency:XBT and related tags from OSM to display Bitcoin-accepting locations on their app. So my goal has been to add accurate payment-method metadata to existing OSM nodes so they appear correctly on BTC Map. I’m not adding new points of interest or importing geometry.
I’ve been doing this in my spare time, honestly partly for fun, and it’s been well received in the Bitcoin community. But I recognise that good intentions don’t replace following proper process, and I’m still learning how OSM works. I’m reading through the guidelines and clearly have more to learn.
Clarification on data sources: In my original post I mentioned using store finder pages and Google Places. Through this discussion I learned that using Google Places is not allowed, and I haven’t done so. As for the store finders. I’m not importing coordinates or data from them. I’m using them purely as a cross-reference to validate existing OSM data. For example, I check the merchant’s store finder to confirm a location is still open before tagging it. This has actually helped me catch stale OSM data. I found several Shell locations in OSM that no longer exist, and I left those untagged rather than adding incorrect information to BTC Map.
What the tags mean:
-
currency:XBT=yes and payment:lightning=yes indicate the store accepts Bitcoin via Lightning, which is factually accurate at these locations.
-
payment:lightning:companion_app_url points to a page explaining how to complete the payment. These stores have QR codes on their payment terminals. Some Lightning wallets can scan these directly; otherwise the page links to the MoneyBadger app, a simple QR scanning app (no account required, no user data collected) that passes the payment to the user’s own Lightning wallet. Please note this app is not our core product, it is simply a useful tool we made for the community and it does not itself have a commercial aspect to it. Our business is enabling payment providers to accept BTC LN. The tag gives users the practical “how do I actually pay here” information. If the community feels this tag is inappropriate, I’m willing to remove it. BTC Map requested that we add it to give helpful information to users who want to understand how to make Lightning payments at these stores, because we are leveraging off of the stores’ existing QR payment system.
-
payment:onchain=no and payment:lightning_contactless=no clarify what’s not supported.
-
check_date:currency:XBT records when I verified acceptance was live.
How I verified the data: The nodes already existed on OSM. I added payment tags only. The payment acceptance is verified directly with each merchant and via our payments data showing that people are successfully making transactions and I have personally been to many stores to test. The QR payment option is integrated into their payment terminals across all stores, deployed on the same devices as Mastercard and Visa. This applies to Engen, Shell, Pick n Pay, Bootlegger, and others. We have direct confirmation from each merchant that the capability is live network-wide, so this isn’t speculative tagging based on third-party sources. I accept that source=survey was wrong for earlier edits. That was a mistake.
The process problem: I acknowledge I didn’t follow the Automated Edits code of conduct. Even though I was adding tags to existing nodes, the scale. 1500+ objects. Clearly required prior community discussion and documentation. I should have:
-
Documented the edit on the wiki
-
Discussed it here before making the changes
-
Used a dedicated import account
I understand if the edits need to be reverted. If so, I’m happy to follow the proper process from scratch. Document the proposal, get community input, and re-apply only with approval.
What would you recommend as the best next step?
P.S.
- I’d like to direct people to btcmap.org which relies on OSM tags and which is getting a lot of positive feedback from the Bitcoin Community. I am being careful to only tag existing OSM points, cross-referenced to get a high confidence that they are still active store locations, and where there is a high confidence that the payment option is live and well supported in the stores.
- I’m trying to get rid of our 1. Google My Places map because it’s become unfeasibly slow - however it did get a lot of attention from the Bitcoin community and we’ve had a lot of positive feedback about it’s usefulness. I am working on 1. our own map as well which we have a bit more control over and doesn’t rely on OSM tags. However we would still want to add high confidence merchants to BTC Map.
- The 1. Engen and 1. Shell edits got quite a bit of love on X, which tells me the community appreciates this.
