• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

DashPay Point-of-Sale

Would you support this proposal if it was submitted?

  • Yes

    Votes: 26 81.3%
  • Yes, with some changes

    Votes: 5 15.6%
  • No

    Votes: 1 3.1%

  • Total voters
    32

kodaxx

Member
Hello, I would like some feedback on my planned proposal. The official pre-proposal can be found at this link:

//vv OFFICIAL PROPOSAL LINKED BELOW vv
DashPay Point-of-Sale Proposal v.01

dashpayterminal.png


What is DashPay POS?

DashPay POS is a free mobile point-of-sale app designed to run on mobile platforms (Android, iOS, Windows Phone), desktop platforms (Linux, macOS, Windows), and standalone hardware terminals. This project is designed for merchants to be able to accept Dash quickly, easily, and securely. In order to further adoption of Dash we need to make it easy for merchants to accept Dash as a form of payment. This system will enable them to do so.

Budget Breakdown

50 Dash - Nitya (server) - development efforts, testing, hosting fees
50 Dash - kodaxx (client) - development efforts, testing, graphics
60 Dash - Hardware terminals, ledgers/keepkey/trezor (compatibility testing)
5 Dash - Reimbursement for this proposal
-------------------------
Total: 165 Dash

More Project Info

official project proposal: click here
alpha source code: click here
demo video: click here

---------------------------------------------------------------

Some FAQ:

-What is the objective?

This project addresses a basic need of Dash - adoption. This project will be a tool to help merchants accept dash easily once they’ve decided to participate in the Dash ecosystem. Not only will this help those who have decided this, but it may sway others who would like to, but think it is too difficult.

The objective of this project is to reduce the complexity for merchants willing to accept Dash as payment, and to create a great experience for customers wanting to purchase with Dash.

-Why use this instead of a mobile wallet?
One of the main reasons a merchant would use this app over the standard mobile wallet would be to have an experience they are familiar with. It has been designed to be very closely related to credit card processing machines in this respect.

The main reason however, besides ease of use and familiarity, is the fact that this terminal is not a wallet. In fact, it only generates the address and payment requests to a wallet that the merchant controls on a different machine. This means that there is no control of the coins from the POS software. This situation works especially well when you have employees that may access this machine as well.

Plus, keeping your private keys offline is always a bonus!

-What are the features planned for this release?
  • Works on Android, iOS, Windows Phone - Mac, Windows, Linux
  • Compatible with Trezor/KeepKey/Ledger Hardware Wallets
  • Generate a new account on first run. Customize store name, create backups, etc.
  • Enter sale amounts in your local currency (only supports USD at the moment) and have them converted to an amount in Dash using http://coinmarketcap.com exchange rate
  • A QR code payment request is generated with your receiving address, sale amount, store name, and 'use InstantSend' for your customers to scan
  • Unique addresses are used for every sale that are a part of your HD wallet. One private key
  • Get an on-screen notification when the requested amount is received at your address
  • Detects partial payments and allows multiple parties to pay the total amount owed
-Are there features planned beyond this release?
  • NFC touch-to-pay with mobile phones using Dash Wallet
  • Multiple currency support (USD, CAD, UAD, etc.)
  • Offline payments system using plastic EMV-type cards for customers
  • Ability to have payments converted to fiat instantly

License info
This software (client, server, everything) will be released under a free open source license (MIT license). If this project is funded we do not intend to code in any percentage charge to the merchant or any other cost mechanism.

Any thoughts?
 
Last edited:
Thanks for this project.

As most of the people have no experience with PoS-software, could you please explain in simple words, why merchant will use this app instead of using standard Dash Wallet (mobile for example) for receiving payments in Dash? What are benefits of this app for them?

Thanks.
 
My suggestion is to split payments up dependant on delivery of each phase of the project instead of the entire amount upfront.

We have had issues with certain projects not delivering on promises lately.
 
Nice!
I would suggest to feed rates from few sources, instead of coinmarketcap.com only, and then calculate an average of some sort (or give user a choice where to fetch from). Could calculate DASH/USD rate by fetching BTC/USD from some large btc exchange like Bitstamp and DASH/BTC from Poloniex for example, should be pretty simple afaik. For websocket "push" version you can grab some code for both exchanges there https://github.com/UdjinM6/bitlisten/blob/gh-pages/src/ratebox.js if you wish.
Also, make sure to make app description as neutral as possible when submitting to Apple appstore to avoid rejection/delisting :rolleyes:

EDIT:
PS. finally someone is using that proposal template, that's kind of a xmas gift to @kot I guess :D
 
Cool idea, Kodaxx!

One thing any POS will need is a CAD / USD dollar amount for merchandise, which will automatically be converted into current DASH equivalent.

This is a feature that is sorely lacking in current wallets, as well.

:)
 
Thanks for this project.

As most of the people have no experience with PoS-software, could you please explain in simple words, why merchant will use this app instead of using standard Dash Wallet (mobile for example) for receiving payments in Dash? What are benefits of this app for them?

Thanks.

Of course! One of the main reasons a merchant would use this app over the standard mobile wallet would be to have an experience they are familiar with. It has been designed to be very closely related to credit card processing machines in this respect.

The main reason however, besides ease of use and familiarity, is the fact that this terminal is not a wallet. In fact, it only generates the address and payment requests to a wallet that the merchant controls on a different machine. This means that there is no control of the coins from the POS software. This situation works especially well when you have employees that may access this machine as well.

Plus, keeping your private keys offline is always a bonus!

My suggestion is to split payments up dependant on delivery of each phase of the project instead of the entire amount upfront.

We have had issues with certain projects not delivering on promises lately.

This is something I have attempted with this proposal. This proposal is for a v.01 with a base set of features, or a 'phase 1', if you will.

It's possible to receive the separate portions of dash upon delivery of the individual products (ie when client app is delivered, receive that portion. When server is delivered, receive that portion, etc.)

Phase 2 and 3 will bring much more exciting and innovative features.

Right now we're playing catch-up to bitcoins current merchant features, then...We surpass them.

Nice!
I would suggest to feed rates from few sources, instead of coinmarketcap.com only, and then calculate an average of some sort (or give user a choice where to fetch from). Could calculate DASH/USD rate by fetching BTC/USD from some large btc exchange like Bitstamp and DASH/BTC from Poloniex for example, should be pretty simple afaik. For websocket "push" version you can grab some code for both exchanges there https://github.com/UdjinM6/bitlisten/blob/gh-pages/src/ratebox.js if you wish.
Also, make sure to make app description as neutral as possible when submitting to Apple appstore to avoid rejection/delisting :rolleyes:

EDIT:
PS. finally someone is using that proposal template, that's kind of a xmas gift to @kot I guess :D

Thank you for the link! This is totally possible, do you mind explaining the benefits of doing it this way?

Cool idea, Kodaxx!

One thing any POS will need is a CAD / USD dollar amount for merchandise, which will automatically be converted into current DASH equivalent.

This is a feature that is sorely lacking in current wallets, as well.

:)

This is definitely something I have planned. Multi currency support is very important.

Unfortunately I do not have it planned for the v.01 release, but I will structure code for easy additions later.

I do hear you though! Dash is global, and the point-of-sale app will be as well!
 
Note: Airbitz is looking to incorporate Dash... and they have a really nice "Merchant Mode" for their app. Just a heads up that there may be some competition in this space. Check them out to make sure you can differentiate significantly.
 
Note: Airbitz is looking to incorporate Dash... and they have a really nice "Merchant Mode" for their app. Just a heads up that there may be some competition in this space. Check them out to make sure you can differentiate significantly.

Thank you! I will definitely check them out. I have some ideas that I think will differentiate this, not only from airbitz, but maybe from anything in crypto space
 
...once they've decided to participate in the DASH ecosystem. So, like, 5 guys with websites who have no need for a retail services or even DASH because over the web it's no better than BTC...

Not trying to knock you down. There's potential for this if you bend it a little bit...

Of course, I'm open to all criticism. Where are you suggesting I bend?
Why?

Socialism doesn't make the world go round.

I plan to release it under the MIT license so the dash community can also use it as they see fit. What if I stop development? This way it can continue.

I don't really think of open source software as socialism. I'm far from a socialist myself.
 
There is already merchant POS software for DASH. I am an Ambassador for BlockPay which in my opinion has the best POS system out there since it takes instant BTC, ETH, DASH, LTC, STEEM, etc; you can look at it at blockpay's website (can't post yet).

Would you be interested in doing a joint venture with BlockPay and integrate their software with yours? One way it could work is your hardware could still accept hundreds of crypto-currencies like their BlockPay "s" does, but instead of converting to bitUSD (or bitEUR/bitCYN) automatically for merchants, the merchants could have an option to receive DASH instead; that would be the part you would probably need to code.

Combined with your hard wallet integration and other hardware features, I think your device would be far superior to any physical POS the credit card folks could ever come up with. Plus, they are already partnered with Odoo so your hardware/software could run right along cc payment options.
 
Would you be interested in doing a joint venture with BlockPay and integrate their software with yours? One way it could work is your hardware could still accept hundreds of crypto-currencies like their BlockPay "s" does, but instead of converting to bitUSD (or bitEUR/bitCYN) automatically for merchants, the merchants could have an option to receive DASH instead; that would be the part you would probably need to code.

Combined with your hard wallet integration and other hardware features, I think your device would be far superior to any physical POS the credit card folks could ever come up with. Plus, they are already partnered with Odoo so your hardware/software could run right along cc payment options.

Very interesting. I will talk with nitya about this. Have them reach out to me on dash nation slack! I'd like to know more
 
I really like the project. Merchants having several options is not a problem in my opinion, the more the merrier. However, I'm gonna be with @camosoul here and say that without a revenue model I'm afraid this can fall into oblivion. Being open source is not enough for other developers to develop if you move on. Maybe in the future, with a big installed base of merchants it could be fine, but with our current situation that won't happen. I would rather have some plans on how to support/maintain this. If that involves some payments somewhere, so be it. Or maybe a support proposal down the line, I'm not sure.

One stupid and yet unpolished idea to help adoption/maintenance of your software... how about if on installation you could include an address for a small fee on payments? that way people would chase merchants to use this software and would support the merchant because they would be earning money. Kinda like an affiliate program.
 
I really like the project. Merchants having several options is not a problem in my opinion, the more the merrier. However, I'm gonna be with @camosoul here and say that without a revenue model I'm afraid this can fall into oblivion. Being open source is not enough for other developers to develop if you move on. Maybe in the future, with a big installed base of merchants it could be fine, but with our current situation that won't happen. I would rather have some plans on how to support/maintain this. If that involves some payments somewhere, so be it. Or maybe a support proposal down the line, I'm not sure.

One stupid and yet unpolished idea to help adoption/maintenance of your software... how about if on installation you could include an address for a small fee on payments? that way people would chase merchants to use this software and would support the merchant because they would be earning money. Kinda like an affiliate program.

Hey @fernando,

Thanks for the input here! One of the great things about how this project is set up is the ability to have it both ways I think. For starters, the MIT license will allow any business to come along and create a revenue model around this software, but will also keep the parent project free.

Nitya and I have been in this discussion for awhile now - we plan to add services on top of this POS system (ie, instant fiat conversion for a percentage fee, selling hardware terminals, etc.) but we would still like to keep the base project free for the community to use as well (and of course, push improvements to the parent project).

Many companies already operate this way with a few key products. Adobe does this with brackets/edgecode and cordova/phonegap. For example, Adobe bought the company that made Cordova and donated it to the Apache foundation, and made a fork of it themselves and named it Phonegap. Phonegap is a "cost" service that provides extended API's and automated build tools, etc. We think this model will work well for us.

I hope I've addressed your concerns - if you need any clarification, I'd be more than happy to provide that for you.
 
Last edited:
You have to do the hard thing that nobody wants to do, or this is just another wallet app.

Any vendor who wants to (which is nobody) can already accept dash with a mobile app (or any of the other equally block-rate dependent pseudo-solutions that already exist) and manually exchange it. It's a mess of crap they don't want to deal with. Those who do can't run away fast enough once they're exposed to the ponzi elements and the anti-business attitudes they find here. They don't even need a mobile app. They could print a QR code.

Part of my theory on adoption has to do with solutions like you mention here feeling "hacky" and unprofessional/unfamiliar. My goal is to make DashPay POS a legitimate and professional business solution. My mom owns a clothing store and has been in business for ~25 years and there is no way she is learning how to print out QR codes, etc. She takes one look at a Dash address and her eyes go cross.

You have to combine it as a package with a fiat conversion service.

Speaking of my mom - what you mention here is also true. There's no way she is going to want to figure out how to exchange Dash for dollars. There's also no way she's interested in holding Dash. If these issues were solved, there's no reason she wouldn't accept it. If it was easy for her to do, and she ended up with cash - then all she needs is a customer demand. (which is another issue in itself)

It's also a larger part of what we plan to accomplish with this project. Once the app and hardware terminals are at a certain point with functionality (ie multi-currency support, NFC capabilities, major bugs squashed, etc.) we will innovate on top of the platform (as a paid service) with features such as card-type wallets and instant conversion to fiat.

The reason I don't mention this in *this* proposal is to keep from promising a house before the foundation is laid.

I offered to do this a year ago. DASH didn't want it. They want to do the half-measures. another app. Marketing. Conferences. The easy stuff. No actual hard work is wanted, and even the attempt to do so is stifled at every opportunity.

I like the direction you're thinking, but the problem is that you're not going far enough. Which is par for the course here... If you really want this to be a useful, productive, and successful endeavor, you're better off going private and forgetting about the social justice warriors who control the votes here.

I can assure you that plenty of hard work will be involved here. In this stage itself, and much more hard work in stages further down the road. I want exactly what you mention, which is the reason I started this project in the first place - nothing that fills this gap yet exists.

We just need to take this one step at a time.

The worst problem now is that IX is user-side initiated and open-loop...

I already did the legal research on MSB FinCEN and State-level Money Transmitter laws, and have more than enough asset to put up for doing it. But, without a serious, working TX locker, we're still left waiting for blocks just like bitclones... Why should I, or anyone, take that risk? Especially when it could be easily fixed, yet not being fixed. If John Connor hadn't spazzed out on XVC, I'd be using XVC to do it right now.

DASH only persists in the market space because everyone else is screwing up even worse... As soon as someone stops being a total screw-up, that person wins.

If you have done the research, do you mind if I reach out to you during that phase of the project? Navigation of legal regulations here in the US and abroad is mind-numbingly difficult. I agree than XVC had some interesting tech as well - and you may have seen me in that community before. It's a shame what some developers end up doing...

As we see here, the lure to partner with pre-existing broken-by-design pseudo-solutions is already afoot...

I'm not sure what you mean here, but I can assure you that any talk about partnering with any other solution thus far has been only that. If any decisions are made regarding the contrary, it will be made known.

If there is anything that you feel I can expand on, please let me know
 
Bingo. Make it basically a credit card terminal, but it uses DASH and pumps Dollars into the bank account. Anything less is Dead On Arrival. No silly POS system integration. A simple stand-alone terminal. Any old android phone with a bluetooth thermal printer will do. Skip all the fancy NFC stuff, stick to the lowest common denominator.

This is exactly what I'm going for - integrating NFC is trivial, honestly and the way the NFC will work is that it will be active in the background on phones/tablet/terminals that have NFC chips. If the phone does not have an NFC chip then it will not affect the normal operation of the terminal.

In our system design, there is not any integration with existing solutions. It will be a standalone terminal. All a merchant has to do is put the amount charged in the 'other' category on their POS (supported by almost all existing POS) and they will still get all the accounting, inventory management, etc. that they are already used to.

Asking a merchant to "switch to 'such and such' POS system because it supports cryptocurrencies" will fall on deaf ears.


You need a skeletal end-to-end solution to which you can then feature-add. The one step at a time thing can easily die because the steps don't actually go anywhere.

Start at the hardest point so that you don't invest a lot of effort and then hit a brick wall. You end up with everything "except that one thing." So figure out what that one thing is likely to be and attack it first. That way you don't fight up to it and run out of steam. Attack that hardest point first, and it's all downhill from there. Start with the Compliance and creating a DASH to USD arrangement with an exchange that has appropriate APIs. The app and the technicals of the service are actually the easy part.

Many have tried to go down the path you are setting upon, they all did it backwards and gave up; and I see you trying to do the same thing. This isn't even criticism; this is guidance from experience.

Skeletal and modular is what we intend to design here. I understand exactly what you're saying here, and this has definitely been thought out.

The DASH to USD is a different proposal entirely, and one that I know is possible to accomplish.

One thing that is important to remember is: I'm new to this community - I will need to do a few projects (like this one) to prove that I am competent and capable of accomplishing what I'm setting out to do here.

Why wait? This is the part you should be doing first.

I can understand what you mean here, and you are probably right. I am also a firm believer in 'more than one way to skin a cat'. I think this project alone will at least add value to the community and give us time to work on the more complicated issues of actually creating the DASH/USD business.

Like I've said before, the DASH/USD is a different proposal entirely (and one I intend to make). In itself, the instant fiat conversion service will be terminal-agnostic. I don't care how they accept their DASH - if it comes to the service, it's getting converted (less service fee) and deposited. Unfortunately it's not what I'm working on at this moment, but I am thinking about it's integration with every move.

Every State is different in regards to it's Money Transmitter laws. Lots of nonsense paper. The main sticking points are usually bonding and presenting a net worth of a certain value, which varies from state to state. Ignore California and New York initially. Too burdensome. Deal with them after you get established. One of the up sides is that they generally don't have any hard and fast rules about any particular type of asset being worth $XXX,XXX. Most are between $100,000 and $300,000. If your crypto is worth that much, you're set for the biggest hurdle. All you have to do is organize silly papers. Every state has a department for doing just this, and they're usually pretty helpful.

FinCEN actually had me confused for a while... There really is no cost. You just have to perform an electronic registration of your MSB every 2 years. That's it. No fees. I know. I didn't believe it either.

This is good info, thank you for this


Only that I see you taking this from the same wrong angle that every other failed venture in this vein has taken... I'd like it to win. Don't keep doing the same thing expecting a different result...

Software Developers always think the solution to everything is to write code. When all you know is hammer, everything looks like a nail. This is not a nail, and everyone who treated it like one has failed.

To be clear, I am a software developer now, but I haven't always been. In real life I'm actually a machinist (not sure how that helps here lol). I learned to code with the goal in mind of offering something to the cryptocurrency community because I believe in the idea, and for reasons you mention below.

DASH itself is a perfect example. You can polish the user interface all you want, if there's nothing to back it up, it doesn't matter. I like to use women as an example... You can make your "interface" really easy for them to use, but if there's no reason...

There is a reason you can count the number of women involved in Crypto on one hand... It's a bunch of nerds who just plain don't get it. You can't just walk up to a girl, whip out your ding dong, and explain how advanced, shiny, and easy to use it is... Doesn't work. Well, some girls are like that. But, not most... :p

^^ This...crypto is full of a bunch of nerds that just plain don't get it (I still love em though!). I could dredge up some past posts in different communities where I am saying almost identical things as you (and I still am). I was making those posts when I didn't know how to code and other software developers were not responding or saying, "code it yourself"...so now I am! Lol.

As for consumer demand: no up front costs. If it collects dust and gets used once a month, so what, it doesn't cost anything so no big deal. All they pay is a percentage of the transaction, just like a credit card terminal. It's familiar and simple.

Customer scans QR code. Money shows up in bank account.

No Identity theft or fraud problems. No chargebacks. No contracts. No privacy concerns. No PCI compliance. No employee theft. Very literally, nothing but money in the bank.

Exactly the experience I want to see. I honestly think we are coloring within the same lines here - I'm just coloring a leg and you're coloring an arm lol.

One day the whole picture will be clear as long as you're dedicated to coloring the whole thing.
 
there are some POS solutions already, eg.
plus some more. My questions:
- what is the unique feature that is not available in the other solutions?
- will it also support Bitcoin (maybe other cryptos)?
- how does the DASH to fiat conversion work?

Cool find! I had not seen those before. There are some differences though.

These apps you point out seem to be full POS apps (requiring a merchant to switch software) but the app I'm proposing in akin to a dedicated standalone credit card terminal.

It's use is compatible with any standard POS (even square register!).

Bitcoin does have some apps like this (blockchain merchant, bitpay, etc.) But Dash does not.

To answer your questions:

-This proposal is the foundation for many unique features to come. But to be clear - these features are not very unique to crypto in general. Right now I'm playing catch-up to bitcoins current merchant features.

One thing that does differ this solution from any existing is the support for instantsend detection. Imho instantsend will be super important for merchants.

-Plans to support multiple cryptos are not currently in motion (though theoretically it's a few lines of difference for each Bitcoin fork). The reason we don't currently plan on supporting other currencies is because other coins do not have instantsend. To accept other coins in a timely manner would mean 0-confirm transactions for merchants, which is not very safe.

-Dash to fiat conversion is still in planning stages and is not slated for this proposal. To be clear, this is something that will be implemented in the future and not in this release.

If you have any other questions, please let me know
 
Back
Top