I have a website where people do simple cognitive psychology experiments. Currently, people volunteer. To increase numbers of responses, I would like to offer micropayments in a manner similar to Mechanical Turk*.
My question is, What would would be the best system to use to make these payments? I would guess that both paypal and flattr would be options. Has anyone with experience with setting up a micropayment system like this be able to offer advice?
cheers,
Mark
*I am not thinking about using mechanical turk itself, just because I do not think I would be able to control the web based studies exactly I would need.
Flattr would work in your scenario:
Each person doing the test would need a Flattr account.
They’d need to login with their Flattr account on your site (like on fundd.de) or connect your site with their Flattr (easy with OAuth).
Once they’ve taken the test you manually Flattr them and by controlling your monthly budget you control how much each click is worth.
Our API makes setting this up fairly easy and straightforward http://developers.flattr.net/
Downsides:
Required to sign up with an additional service.
Flattr currently caps monthly spending at €100 so if you have lots and lots of testers you’d run into problems of making the payment high enough. We are reconsidering this, at least for users in good standing.
Monetary incentives for testers bring in a different crowd and can influence the results of their tests but you probably already know that.
Cheers,
Teller
PS. I work at Flattr.
I've done quite a bit of searching for a CMS platform or robust framework that will perhaps facilitate the management of signup and subscriptions right of the box with a Twilio tie in.
Thus far I've only been successful at finding how many startups have been funded by the Twilio fund, who's building the nextgen voice enabled app, and various other things of that nature vs any real meat. Seems that there's a dearth of meaningful information without applying a plethora of negative google filters to reduce matches and even then it's still not giving anything real meaningful wrt my search.
So, I'm hoping that someone may have a better eye on the lay of the Twilio landscape as far as already existent systems go that can handle the bulk of needs that exist for a "regular" CMS esque site that needs to also handle subscriptions and e-commerce related tasks.
Hitherto I've just planned to build something out myself, but I wanted to do a sanity check before I spend a lot of time that could perhaps be obviated.
My suggestion would be to find a CMS that does everything you want (except the twilio links), on the platform you want, and then just add the Twilio stuff in. Twilio is simple to use, and should be simple to add-on to most open source CMS's. It'll probably be the easiest part of the project....
I understand that apple no longer allows me to send "device data" to third-party services. As a result of this, Flurry and presumably every other analytics company no longer collects OS/hardware version data. However, this data is very valuable to anyone trying to target development toward the people who are actually using the apps.
I can imagine a few different ways to collect this data.
1) Send a custom event indicating the hardware/os version to Flurry. This, of course, is in direct violation of the agreement with Apple. However, I suspect plenty of people are doing this, and just not getting busted. Still, not an ideal solution. Even if Apple didn't notice that we were sending this data, I'd rather not have the possibility of the app getting pulled hanging over my head.
2) Use an analytics package which allows me to collect data on my own server. Localytics is one company which seems to offer this. However, I don't think they offer this with their free plan. Is anyone aware of any free (or cheap) analytics tools which will allow me to send data to my own server?
3) Roll my own solution. This could either be an entire replacement for Flurry, or I could continue to use flurry, but send only the device data to my own server. This is a little clunky. I'd much rather have all my analytics data in one place. And would much rather not have to deal with building my own tool if I don't have to
So, is anyone else collecting device data? Are you using one of the above techniques? Or maybe something different I hadn't thought of?
Hi maybe "Testflight Live" could help you.
As far as I know Testflight is allowed by Apple.
https://testflightapp.com/sdk/live/
I've heard of people using UIWebViews to connect to a webpage with a counter. The counter is incremented each time a page is accessed, and the pages are separated by feature/UIView. This way the developer can tell which features get the most usage.
As far as device data, you most likely are looking at rolling your own tracking mechanism, probably going through a server like Google App Engine that's set up to receive your data.
I made this an answer so I could continue to check back, because I'd like to know some more info as well. I voted up your question and favorited it
Good luck, sir
I dont know what to say. About 3 days ago I released a script to the public. Today I realised, after searching on google that someone had already nulled (removed my protection) and pirated the script.
How do I stop users from pirating the script? It is written in PHP.
Please help or suggest some solutions.
Thank you for your time.
UPDATE By releasing to the public means that I have started selling it to users.
UPDATE My program is priced at only $49. Very reasonable for the functionality it offers. I do not understand how I should stop pirates from pirating my code. The replies which most people have given are rather sarcastic. I was hoping for some good advice. I know there is no silver-bullet. But some techniques which you have used in your PHP programs.
The only real way to prevent piracy is to not give the user the program at all! What I mean by this is have the logic you want to protect remain server side and offer a client interface.
There are a few companies that offer protection services, but these are expensive and can sometimes still be overcome.
If you're worried about this happening again, try obfuscating your code. Here is a free program to do just that on PHP code.
I'm not trying to be sarcastic here: forget about them. Here's my rationale:
You can spend tons of time trying to
prevent pirates from pirating your
stuff, or you can spend the same
amount of time giving your paying
users more functionality.
Extreme copy protection does not give your paying users anything but more
hoops to jump through to use your
application - which might lead them
to get frustrated.
Pirates will pirate your applications
no matter how much time you spend
trying to stop them.
Budget a certain
amount of time to put in basic copy
protection - just enough to keep the
honest people honest.
Most importantly: Don't irritate your paying customers.
They are the ones you need to make
happy.
There's not much you can do.
Be flattered your work was deemed worth the effort!
How do I stop users from pirating the
script?
Do not release sensible source code to the public...
[EDIT] After a few downvotes, I decided to comment on my answer:
Any code that is released public has a chance of being hacked. This is the number one reason why Javascript is not secure. No matter how much you will obfuscate it, compress it or translate it to some random japanese dialect, it is still source code that the user has access to. Hence it should not contain any sensible information such as passwords or such. All sensible data should be stored in the server side where it is kept hidden from the user.
If you are releasing a php framework containing both the server and client code; then you have no way of fully protecting yourself. PHP is, like Javascript, an interpreted language. You may translate it, compress it, or obfuscate it as much as you want, (and it's probably the best thing you can do) you will never fully protect it when released to the public.
Again... If there was a magic way to prevent code from being broken, it would have been known for a long time. No-cd patches / cracks for new games/softwares now are almost released the same day as the softwares themselves. It is, as noted by Paul, a form of flattery for you, even though I understand how sorry you may feel.
There are a few instances where programmers ended up with bullet-proof protection, but it usually involved high-end engineering.
With PHP, you're mostly out of luck. It's an interpreted language, which means that you are essentially forced to give away the source code. Sure, there are obfuscators (tools that "scramble" the source code to make it near impossible to read for humans), but they can be circumvented as well.
There are product like Zend Guard which seem to offer a better level of protection, but from my understanding, your customers need Zend Guard installed as well, which is almost never the case.
There are several methods of handling this:
Offer your product as a service. This means finding appropriate hosting in the cloud, etc. This removes access to your code base, thus preventing direct piracy. Someone can still reverse engineer your stuff, but I'll touch on that later.
Add a unique identifier to each version of the script sold. This can be done automatically, and is great to do with obfuscated code (another, complementing method). This will give you the ability to track whoever pirated your code. If you can track them, you can sue them (or worse).
Pursue legal action. You'll need to know who leaked the code in the first place for this. Their PayPal information or even an IP address should be enough. You go to your lawyer, ask him to get a court order telling PayPal/ISP to release the identity of the thief, and then start tracking them down. If they're located overseas, your only real option is to freeze/appropriate funds from PayPal/credit card. Banks will be sympathetic only if they have a branch in your country (which can be targeted for legal action).
Ignore it, and simply build your business model around the support that you offer.
The sad fact is that information cannot be secured completely. There is no way to prevent a team of Indian programmers from reverse engineering your program. So you just have to be better than them, and constantly improve your product (this is "A Good Thing (TM)", so do it anyways)
Also keep in mind that DRM and other solutions are often controversial, and will reduce your sales (especially among early-adopters). On a personal level, I would suggest viewing this as a compliment. After all, your script was useful enough that someone bothered to pirate it within a week!
PHP is easily decoded, so for people who really want to know, it's easy to find out the source code. However, there are certain obfuscator programs such as this one that'll make your PHP script almost unreadable for those trying to decode it.
What kind of protection did you think you had added to a PHP script, anyway? You should add a line of the form:
if ($pirated)
exit();
and then make it mandatory (in the licence agreement) that users set the $pirated variable accordingly.
Forget trying to prevent it
Go the way of CakePHP (see sidebar on front page) and many other open source projects and ask for donations.
People actually do it!
Contact the pirate and let h{im,er} know that you will be forced to take legal action against them if they do not abide by the license.
I agree with #Michael.
Try ionCube or Zend Guard. They are both commercial offerings, but you say that you are selling your software so it might be worth it. Although nothing is foolproof and can be reverse engineered with enough effort and technical skill, these solutions are probably good enough for the average PHP script vendor.
I agree with Samoz's suggestion to keep the logic server side, however this can often be hard to do. The best strategy is to make the user want to buy it by offering updates automatically to registered users, as well as installation, advice and good support. You are never going to sway people hell bent on pirating, however your goal should be to persuade those who are undecided as to whether to pirate or purchase the script.
Any obfuscation/decryption technique for PHP can be cracked
Jumping in very late to this conversation, but saw this question featured. Nobody mentioned contacting a lawyer and pursuing litigation. You likely saw the script on a server - hosted by a known hosting company - you can probably get a DMCA takedown to have the script removed. If you really press the case, you may be able to sue for damages.
Found this link to assist in going this route:
http://www.keytlaw.com/Copyrights/cheese.htm
You could always pirate it yourself to the internet and hope that any nuller will think "its already been grabbed" so don't bother. But pirate a real buggy version. When users come to you looking for help you'll know they have a pirate version if they question you about specific bugs you purposely added and you can approach them accordingly
If your script won't consume a lot of bandwidth, you could keep your "logic" server-side, as samoz suggested, but if your users won't use it responsively ( a crawler, for example ), this could be trouble.
On the other side, you could become a ninja ...
Attach a copyright notice to it. Some companies will actually care that they're using software properly.
Actually I think it's easier to protect PHP scripts than desktop software, because with latter you never know who is running the cracked copy.
In case of PHP on the other hand, if people run your software on public web servers, you can easily find them and take them down. Just get a lawyer and turn them in to the police. They could also be breaking DMCA laws if they remove your protection so that gives you even more ammunition.
Technical way to protect your code is obfuscation. It basically makes your code unreadable like binaries in compiled languages (like Java). Of course reverse engineering is possible, but needs more work.
In general it's hard to prevent users from stealing code when the program is written in a scripting language and distributed in plain text. I've found that http://feedafever.com/ did a really nice job of being able to sell PHP code but still give the code to users.
But the solution to your problem is very dependent on the domain of your program. Does this script run on the users machine with no internet connection? Or could this be a hosted service?
I'd also suggest looking at some of your favorite software, and seeing how they convinced you to pay for it initially. The issue I find isn't always "how can I prevent my users from stealing my software" but sometimes more "how do I convince my users that it's in their best interests to pay me". Software piracy often comes when your product is overpriced (Ask your friends what they would pay for a software package like the one you are selling, I've found that I have historically overpriced my software by 20%).
Anyway, I hope this helps. I'm glad that you are trying to create software that is useful to users and also not incredibly crippled. I personally of the mind that all software that isn't shrink wrapped or SAAS should be free, but I totally understand that we all need to eat.
The trick is not to try to prevent the piracy (in the long term, this is a losing battle), but to make the legitimate version of your product more accessible and/or more functional than the pirate versions.
"Making it more functional" generally means providing involves additional features or services to registered users, which cannot be replicated for free by the pirates. This may be printed materials (a users manual, a gift voucher, etc), services such as telephone support or help setting the product up, or online extras within the software.
I'll point out that companies such as RedHat are able to make significant amounts of money selling open source software. The software itself is freely available -- you can download it and use it for free without paying RedHat a penny. But people still pay them for it. Why? Because of the extra services they offer.
"Making it more accessible" means making it easier to get your legitimate software than a pirate copy. If someone visits Google looking for your software and the first result is a pirate download site, they'll take the pirate copy. If the first result is your home page, they're more likely to buy it. This is especially important for low-cost software: pirated software may be 'free', but usually it takes more effort to get. If that effort is outweighed by the low cost and lack of effort of simply buying it legitimately, then you've won the battle.
I saw anti-piracy working once only. Quantel EditBox systems (a post-processing video solution), Hardware+Software+Internet solution against Piracy. Workstation only works after checking if the bank received the monthly rent. If not, workstation was locked. Funny days when this happens... (Funny days for me, no work at all... No funny day for the hacker.)
Well, PHP is far away from hardware solutions... so I guess your only real choice is a server side protected against a tiny unsafe client pushing content, as pointed in some answer yet.
piracy != copyright infringement
There are known routes to litigate copyright infringers.
Does it really matter enough to hire a legal team?
Obfuscation do add something. It will not be fun to try to modify your code at least even if they can take the first version of it. In best case they will try to find some open source project that does something similar. Guess this would give you an fast fix at least for your problem?
Does anyone else find that the documentation of a lot of payment processors have poor or incomplete documentation as to how to use their API? Or it's just plain confusing?
Recently I have setup both PayPal and Beanstream and found that both are either confusing or don't include full documentation.
For example, in the BeanStream documentation, they say they will return a "message_id", which is great, but no where do they tell you what the different id's mean. It also comes with some text, so you can start creating a list, but there is no way to check to ensure you get either a valid one or the one that means it was successful.
Has anyone had this experience?
Edit: I will agree that when you email them they are helpful, but unfortunately most of them are only open normal business hours for general tech support (other than emergency) which isn't always useful as that isn't when it seems like I do my integration.
well, this isn't really specific to payment processor documentation, in that, all things being equal, well documented APIs will help encourage development. for what it's worth, i've worked with paypal, authorize.net, ups, and usps APIs, and didn't find them overtly confusing (not implying that they were a particular joy to get through).
that being said, i wish more documentation was like PHP's. despite it being such a scattered language, the documentation is really quite good.
Having worked with a lot of APIs, not only for payment processors but for lots of other ecommerce related web services, I have to say to that while the docs can be less than stellar, they usually aren't that bad, and if you send them an email or give them a call, they will usually be pretty helpful.
I have found the documentation and code examples from Authorize.net and Nova's ViaKlix very helpful. I stay away from PayPal.
This may not be much help to you, but as you get more an more experienced w/in particular domain the interfaces get easier. By weird twist of world, I've coded a whole bunch of credit card interfaces, and once you kind of get the lingo they all work the same.
The only other suggestion I would offer is to avail yourself of support resources in addition too the documentation provided. We recently worked with a relatively well known payment gateway, and while their documentation completely sucked (by their own admission as well), the support staff was incredibly knowledgable and more than willing to help out/explain.
I've used Realex and PayPal. Realex documentation is fine. Clear and straightforward. PayPal's is absolutely eye-bleedingly horrible. And I'm the kind of weirdo who enjoys reading documentation so much I've been known to read it for fun (I've read through the entire OpenID specificiation, even though I have no immediate plans to use it).
I've only worked with PayPal, but the simple version (where you just set up an HTML form on your web page and submit it with the PayPal button) is super-easy to work with. And if you're looking for near real-time payment feedback, I always found it easier to just write a program to check my PayPal email account periodically, and parse payment details from the body of the email itself.
I've had to use Authorize.net for several sites and the supplied documentation is 'just ok' assuming you are working in the somewhat limited technology sets that they supply sample code for. It was a breeze to get it up and running with PHP but considerably lacking when trying to pull off the same thing in ColdFusion.
Several other sites done via PayPal which IMO was a much better experience.
PayPal is a nightmare when it comes to setting up and testing the test account (Sandbox).
Re: Beanstream you have to login then you'll see the documentation link on the left hand side.
The design is so '90s and they recommend using IE.
Re: Paypal I adapted this code from http://www.php-suit.com/paypal for my Zend Framework project.
Note: you've got to have ssl:// socket transport wrapper registered otherwise (visible in phpinfo()) you'll have to tweak the code to use curl.
Here is how to get the code using SVN
svn checkout http://paypalphp.googlecode.com/svn/trunk/ paypalphp-read-only