https://www.okpay.com/en/business/digital-wallet
"
Fraud is effectively deterred
We understand the risks online businesses face and take all necessary
steps to protect merchants from chargebacks. We verify the identity of
OKPAY users to make sure you only work with legitimate customers.
"
PerfectMoney: No chargeback policy Every transaction in Perfect Money system is final. Guaranteed.
OKpay: To ensure your safety, the OKPAY risk team works 24/7 to prevent chargebacks before they even occur.
Also “Completely non-reversible.”
Payeer: ?
Webmoney: not sure
See also comparison of some 30 payment methods in aspects including chargeback risks
Hey guys! Sorry, got online late today. I’ll probably be on off-and-on for the next 6-8 hours or so. Anyhow, yes, I would absolutely be interested in working on this on a contract basis! Ideally I’d like to do hourly contracting rather than a project bid, as I believe that aligns incentives better to actually get things done: for instance, when there’s a great idea and requirements change after the fact, as always, instead of having a crazy out-of-scope modifications rate like some large contractors which will go unnamed do, being hourly from the start means we try to get requirements right at the start, then I start working on the core things I know I’ll need, and if we want to do tweaks as we go (like add or remove support for a different payment processor) that should be relatively simple.
It’s also lower risk on both sides in my opinion: I don’t invest all the work up-front to make the software (and get tempted to cut corners to be able to pay the bills by getting to the milestone sooner) and the customer doesn’t risk paying for a “completed” project that doesn’t actually work for them when the actual requirements are different from the initial requirements.
I do think the overall estimate is actually pretty good for getting to a working version. I would expect that working at 20-25 NBT an hour, polishing up the requirements and specifications might be around 100-200 NBT, API / payment processor research will probably be about 200 NBT ultimately, writing and doing some basic testing on an internal wrapper library for these payment processors (research if there’s an existing FOSS library which works first, but I’ve often found making my own simple wrappers can be worthwhile; however, getting them to properly handle errors and such edge cases takes more time) around 200 NBT (just spitballing here), and maybe 200 NBT for the configuration and business logic of trades, oh, and maybe 200 NBT for the nu integration, and we’ll put documentation as 200 NBT. So even with reasonably generous estimates, a decent working version (we’ll just throw another 200 NBT for final integration and testing and ass coverage) should be done by around 1400 NBT. So my very rough estimate matches the initial budget estimate here.
I would perhaps suggest a slight change in description / concept of considering me the “development manager” of the project and directly putting the responsibility for the project on me. I understand the desire for verification, but I would think of it as: since this is intended to be an open source release, then part of what I’m agreeing to for acceptance criteria is sort of a “reasonable hacker” standard of: a reasonably competent sysadmin should be able to install, configure, and operate this system easily, that sort of thing.
I can see the logic of an administrator role which distributes funds as I report hours and which does a basic sanity check that I produce what I’m supposed to by the end. And actually, it would be nice to have a second paid person on the project for a tester role. So I can see putting that in there. I just have an aversion to being able to potentially not get paid, or not get paid until the code is perfect. I’m not worried about whether I can produce acceptable working code but the structure of “here are my initial thoughts; build my idea and report back for the money” has always terrified me because of the experience of requirement change and differing interpretations.
Anyhow, I’m still completely new to how things are done around here, just putting out my thoughts on ideal structure. I’d be willing to compromise on a fixed price contract as long as it’s not the open bounty (because of the possible risk of being beat to the punch, and I cannot afford to gamble that much with my income right now), but it would definitely be a hardship for me and would frankly result in a lower quality product without necessarily saving anything. It would however still beat the hell out of going back to killing time flipping burgers, so there’s that. 
I do think this is a very interesting project idea. Operating such a site publicly in the United States would constitute a money selling business to the best of my understanding of the law (but I am not a lawyer), but creating the code and releasing it without warranty should be safe I believe. And so long as some people somewhere start using it, then it’s useful.
Also, I just realized I hadn’t been thinking about the advantage of this being NuBits; I’d thought about it so far as a generic cryptocurrency selling/buying site. But the advantage of the NuBits thing is we could make the assumption the exchange rate is always 1:1. xD Personally, I’m enough of a Y2K kid that I think I’d just make the 1 as a constant variable so it could still be modified in a single place if something crazy happened (or for later support of, say, buying NBT with EUR and so forth (with additional modification, but at least already using a constant variable rather than hard-coding the logic of “1 currency unit equals one cryptocurrency unit” everywhere, as amusing as that could be.)).
Thanks for the reply @CoinaDay. There are a lot of similar sites selling bitcoin. We compiled a long list. I think someone who developed those sites should be able to make a Nubits exchange site for 10-20 hours work based on existing code base, including documentation and testing. However although @tomjoad as the outreach manager contacted most of them as I know, we didn’t identify someone who could do the job. So the reason why I put it as a bounty was that we could advrtise and attract offer in a broader community. However the problem with it is that bounty claimers could be someone totally outside the Nu community and is only interested in doing just enough.
It’s very good that you are interested in becoming part of t he community and your cost breakdown is close to my estimate.
@Cybnate set an example of how a manager interfaces deveoper with the community in NuDroid development. I have no problem if you ask for a grant to do the development as long as you keep the community in the loop and installments of payment are tied to measurable milestones.
The Nu shareolders on the other hand would worry about paying and not getting the product. In any case you need to craft a custodial grant proposal yourself and get it approved by the shareholders. As you have no track record in the community you might need a few feedback-iterations to get such request agreed and approved.
It’s great you have thought about it. It’s a tool for a global community.
Nubits pegged to the USD certainly makes such site much easier to make. NuBot and ALP software already get price feeds working so trading NBT with other fiats or even BTC isn’t hugely difficult to code. My main concern is in attacking vectors to such site. An NBT-USD site may be much attack-resistant.
Alright, I’ll try it.
There is no possible milestone apart from completion in my opinion, and I will consider support limited and optional after acceptance because otherwise a fixed price development project is suicide. I will be attempting to complete this within two weeks at the very most; ideally within a week. The code should be simple, clean, and easy to review.
I’m not certain yet which language I would use. I usually use PHP for hacking up a site, but for a financial system using its type system seems like a great way to introduce subtle bugs. I’m not a fan of Ruby, or at least its idioms: Rubyists seem to have a fetish for over-complicating things.
This is going to sound really weird, but would you be opposed to the idea of a compiled (or hell, interpreted I guess if a person wanted to get really crazy) C(++) server for it? I’ve never done a web-application in C before, but I’ve done C work and I think strong, explicit typing would be good here. I know web applications can be done in C, and I’ve heard of crazy good performance with it.
The biggest potential problem I think would be it wouldn’t work with some of the more cut-rate hosting, where you just get space for some PHP code or something but can’t run applications or get shell access. Also, the setup I’m imagining wouldn’t work for hosting multiple sites on the same server instance, as it would have the server embedded.
Actually…doing it as a C CGI probably would be pretty clean I think, and reasonably well-supported on hosts.
Edit: Is there a guide for how to draft proposals? I understand the general concept, but I haven’t seen a point-by-point description of how to do it properly and obviously I’d like to be able to get this through as smoothly as possible. 
For text of proposal, I’m basically thinking verbatim what you’ve got here with the modification of assigning it to me as developer.
About the best language to use to develop the site, devs like @desrever @CoinGame @woolly_sammoth @willy @woodstockmerkle @ttutdxh @dysconnect @jooize should know better than I do.
Reading past proposals in https://discuss.nubits.com/c/nushares/custodial-grant-passed will help greately. Basically you create a “[Draft] …” for feed back and iteration.
Then when you think it is ready, if you ask for payment upfront, put in an NBT address and an amount pair in the proposal for voting by changing the title to “[Voting] …”, and updating the hot list post optionally. Once there are 5001 blocks voting for it in a continuous 10000 block chunk, the amount is sent by the blockchain to your address.
However if the payment is not upfront, generally you will first make a motion to pass so that shareholders promise to approve your grant request when agreed conditions are met. You will put up grant requests later. Read Standardised Formatting for Motions to learn how to hash a motion.
I agree with all what @mhps said!
I think doing this by motion instead of grant keeps things easier than with a grant.
A grant would most likely require a “fund manager”, because I imagine NSR holders won’t pay you upfront and that’s what would happen, if you draft a grant with 1,500 NBT - as soon as it passes, the NBT are at the grant address.
As a kind of contract is required to allow you to claim money for your services (the grant would do that as well, but with upfront payment), a motion might be more appropriate.
With a motion that passed, the FLOT or any other entity acting on behalf of Nu could pay you for your services after you delivered what you were contracted for.
…just my 0.02 US-NBT.
It is going to be non-trivial to build a profitable service, where potential security issues aren’t even confined to the scope of strictly technical exploits. I won’t worry about what language to use until one can figure out how to deal with the high-level details. People these days just use Django or Ruby on Rails, both of which seem to be flexible enough and offer sufficient safe-guards for hacking.
Now regarding the pay, if indeed the service could be independently profitable, even with a very small profit margin, the 1500 NBT will only be a cherry on top, something to get people interested. If it’s not profitable then it might not be worth the effort nor the bounty. On the flip side, there are many discussions on this forum that lead to some information (though not comprehensively) on how to manage the risks in running a service like this, so you should look into that first.
Draft proposal, although it’s basically just what you wrote above. I read the thread on hashing motions but @assistant didn’t reply to my test message hash; either I did it wrong or it’s down.
@dysconnect, there is a difference between liquidity services and software development. I have no liquidity to provide. I am able to design and build software.
I am aware there are significant security considerations with this. Many of them are external to this project: for instance, an operator of such a site will need to secure their machine to start with which is non-trivial. I am not signing up for operating a service like this. Nor do I expect that my code will be perfect with regard to security but frankly this isn’t an especially complicated task from a security standpoint, it’s “merely” that it’s important to get right.
Edit: Eh, I don’t like calling it not complicated either…I mean, sure, there are interesting edge cases of various sorts. But it’s not like anything here is original research in the sense of solving some problem from an algorithmic standpoint.
A customer can send more funds than the site has available to convert and that will need to be handled. A customer could attempt a double-spend attack with NBT, and so a configurable option for number of confirmations required makes sense. I’m certainly glad to listen to specific concerns.
Can you give a few examples of possible security issues? The usecases given in the OP seem to expose very small attack surface although I think we should look hard into it.
As for profitablity, it’s not in the scope of this project to guarantee profit for the user. But I see almost no cost of running the site except for opportunity cost of funds put into the system and server cost, which is zero if you already has an VPS or run it on a Ras-pi. If set with 2-3% spread, which is normal in the Internet exchange world, profit (not normalized with hack risks) doesn;t seem hard to achieve.
On the other hand profit might not be the goal for some users at all. Nu could use this system to set up many not-for-profit nubit-fiat liquidity providing mini exchanges, the advantage being -
Haven’t had time to read all of the above but I’ve been longing for a direct way to buy Nubit - Fiat and sell Nubit - Fiat without the need of an exchange ever since I’ve heard about Nubits! This would help us out so much and have the additional benefit of us being able to remove the costly support of numerous exchanges in favor of B&C Exchange when it arrives. Customers could use Fiat to buy Nubits directly and then use those Nubits to fund their trading account at B&C Exchange!
This is what makes me hesitate to set this up, although the idea is definitely interesting. Many of these rules apply also in other countries like New Zealand.
Have you looked into Cryptopia at all? I know they operate out of New Zealand (they’re the only exchange for NYAN currently, which is part of my interest in projects like B&C Exchange).
It’s frustrating, because this would be a really cool type of operation to be able to run. I’ve wanted to do “buyabit” concepts and stuff like that before but the legal concerns make it untenable for me.
I should be safe writing and testing it though. And it would be fun to see what experiences people have operating it. I would expect the spread to be relatively small like NuBits typically has, so presumably it would be people with a lot of liquidity for the operation and a lot of volume going through who would do well with it.
A “LocalBitcoins” version for Nubits would be something interesting.
But I dunno what the required changes are…
We’ve got a different situation here…
Although @CoinaDay is gone, it’s still a valid point that contracting a community member to do the development has advantages. So I think I will just ask @desrever @CoinGame @woolly_sammoth @willy @woodstockmerkle @ttutdxh @dysconnect @jooize @Ben and any other developers I missed (and I can only mention 10 users in a post) – if any of you are interested in developing the web-based Nubit-fiat exchange software?
This software is not only a convenience utility to the Nubits seller/buyers. It is potentially as important as the Automated Liquidity Pool (ALP) software that enables individuals to provide liquidity to pegs. The difference is that ALP works for Nubits/crypto pairs on centralized exchanges; this software is for Nubit/fiat pairs on a single web page, taking advantage that there is no exchange rate to track for NBT/USD and no order book is required. The software is decentralized and free from exchange risks. It’s a missing piece of Nu liquidity provision system.
I welcome comments and suggestions on aspects of the proposal – scope, price, should it be a bounty or a fixed price contract offer?
Paging @glv @mably @JetJet13 @peerchemist @sandakersmann @erasmospunk @SigmundAlpha @pennybreaker please read the post above. I can only mention 10 users in a post.
thanks @mhps to bump this up . I will add this in the backlog, unfortunately at the moment I won’t be unable to allocate resources to it. I forwarded this post to a friend who might be interested
Personally I think the networks money is better spent throwing it at developing the NuBer LocalNuBits concept I wrote about.
Developing a gateway connected to payment processors puts the people in charge of that service in significant risk. Those processors could choose to shutdown the service, the service has to earn some money for the people running it (harsh truth… it won’t earn them anything. The demand for NuBits isn’t there yet). There’s probably other downsides.
Why does updating NuDroid to assist in becoming a LocalNuBits platform make more sense? Local NuBits traders can trade literally anything for NuBits. It doesn’t just have to be USD… It can be Euro, Yuan, Bitcoins, Ethereum, a car, cookies, cat food… anything. The platform would simply streamline the process of getting someone who wants NuBits in touch with someone willing to trade for them. Any web service connected to the platform wouldn’t actually be involved in any trading, and because of that it’s much less likely to be shut down. Any connected web service would be for metadata or statistics of the LocalNuBits platform. Trading would happen directly between buyers and sellers locally. It would put the legal obligations on the shoulders of the people making the actual trades as well. This would also encourage moving NuBits where we want them. Off exchanges and into peoples pockets where they will most likely use them. Like cash in their pocket instead of sitting on some exchange account (assuming they’ll meet somewhere in public and trade via mobile apps). Even if the mobile app gets banned the apk can still be distributed and installed.
I think there’s a lot more benefit in trying to encourage individuals to transfer NuBits among each other (even personally for goods and services).
I think these two projects don’t overlap in scope much and from what you describe the LocalNuBits site and NuDroid upgrade would cost in the tune of $20k while the barebone site in the OP will cost more ten times less – the cost is not only in the money, but also project management difficulty. So we are talking about an apple and an orange.
I don’t understand why developing a gateway could put the service provider at risk. If you mean the service provider has risk with the regulators, we see that regulation risk varies greatly across the world. In the US where traditional financial sector provides fairly good service and rules with an iron fist through the government there is little survival space to e-currrencies and cryptocurrencies. But in the emerging economic countries people are not happy with services from the banking sector and the regulations toward alternative services are more friendly, e-currrencies and cryptocurrencies thrive. That is why the biggest and most number of processors and exchanges are from Eastern European countries, Hongkong and China. The site in the OP could significantly reduce the difficulty for aspiring small service providers to buy/sell nubits.
It’s not truth but your opinion, unless you can show supporting evidence. I find more than 30 PEGs sites trading cryptos with e-currencies. How come they don’t get sutdown and for all we know are making money?
Further more, why the service provider of such NBT-fiat site have to make money from selling currencies? Does any Nu liquidity provider make money that way? With such software Nu will be able to pay NBT-fiat service providers just like it does with pool operators, at greatly reduced rate because exchange default risk is reduced.
Anyway if someone can promise to manage the project you propose I will support it. I will still promote the creation of the simple web interface for nbt/fiat in the OP because I like simple focused tools that users can tinker with and use as a building block to do amazing things even the creator of the tool might not imagine – and it only costs 1.5k.
I’m not comparing the services directly. We’re talking about what the market prefers. So maybe we are talking about apples and oranges, but we’re not doing it in the context of comparing them. We’re talking about whether or not the market prefers apples or oranges which is apt in this discussion. Also, i’m not sure where you come up with those figures but I’m fairly confident they’re conjecture at best. The difference between the two approaches is that we actually have a very talented developer and project manager for NuDroid who we can work with to define parameters for the project. That will also give us an accurate cost projection for shareholders. We have nobody to rely on in building the gateway service.
http://blockexplorer.nu/charts/numtrans
Check out transactions per day. Most of that is probably ALP payments. Our transaction volume on CoinMarketCap compared to on blockchain transactions tell the clear story of what is happening. For all we know it could be one person driving that volume. That is why I think encouraging people to get NuBits on their phone (which LocalNuBits trades would encourage) is better than some web service to purchase NuBits which has already existed and ultimately removed our asset. The suggestion of building a stand alone service for this purpose is neither novel or interesting.
https://bittylicious.com/ had NuBits available to buy through credit card for a while. I wasn’t expecting this but it looks like they took them down. Why? Probably because nobody bought them.
I think we’re confusing a bounty with costs here. Saying we’re willing to spend 1800 NBT is different than saying it will only cost us 1800. Considering nobody is jumping at the offer (at least openly) so i’m assuming it’s not a very attractive offer. Maybe it’s better to invest the time and resources in developing something more interesting. Make it very easy for anyone that wants to sell NBT to connect with people who want to buy it locally, and let them negotiate what pair they will tade with. Whether it’s NBT/FIAT, NBT/Car NBT/Baseball cards collection. The sellers will need to replenish their supply and they can get them off of the exchanges onto their phones. Which is what we want to encourage.
I think network money is better spend on trying something new, interesting, and innovative. Instead of trying to recreate existing solutions that evidence supports won’t be utilized. Though if someone decides to take up the bounty offer and build out the service then great. I’m just not sold it’s something people will be excited about or use. I think people going to crypto events showing off their NuDroid LocalNuBits wallet and trading on the spot is a much more compelling experience to promote.