So I built Gumroad. I coded/designed from 12PM -> 11PM on Saturday and 8AM -> 11PM on Sunday. There are still tons of features missing (I'm working on AJAX file uploading next!) but I think it's reached that - buzzword alert! - MVP stage where I want to see if anyone's actually going to use the darn thing (I'm thinking about taking a 30% cut).
Here's an example Gumroad link: http://www.gumroad.com/l/hjbaod - I use Stripe for payments. Here are some screenshots I took while making it: http://letscrate.com/gumroad/gumroad-progress - I didn't use Photoshop so no crazy time-lapses!
I think it has some potential. What do you guys think?
The 30% cut is way too high though. Especially for higher priced links - I wouldn't want to sell my $99 game engine through your service. I think something like "5%, but at least $0.30" would make more sense. But maybe having such "highly" priced links wasn't your intention in the first place?
 http://impactjs.com/ (Can't mention it often enough :))
I'm also thinking hard about "Preferred" accounts. Basically, you send an email to firstname.lastname@example.org in the next 24 hours, whenever I do your balance at the end of the month you get as much as I can give without losing money on the transaction. ;)
Plus it's not clear to me that there are enough bitcoins to go around. Some comments below point out the fact that bitcoins can be divided down to multiple decimal places. That's great and all but I can't imagine a 'regular person' being comfortable with the idea that they currently posses .00152 bitcoins. I doubt most people think of a penny as .01 dollars, because fractions are confusing. Plus even if that .00152 bitcoins is enough to buy a car, it still just seems like a minuscule amount.
I don't mean to be a huge downer. I think bitcoins are an interesting idea, but if you want to sell things now a more traditional payment method would probably make sense.
But yes, it probably doesn't make much (commercial) sense right now.
Putting aside numerous other issues, bitcoin.org states "The total eventual circulation will be 21 million bitcoins".
[EDIT: DanI-S pointed out that bitcoins can already be subdivided. So this was switched from "there are too few bitcoins to support even American e-commerce" to "bitcoins are not valuable enough to support even American e-commerce". The number of fractional bitcoins is still an issue, but less immediately.]
At the current ~$0.70 / bitcoin, this means that every American will be able to have ~$0.05 in his or her electronic wallet, once all bitcoins are generated. Assuming that the rest of the world does not participate at all and that bitcoins are evenly distributed.
Sure, you could imagine an instant dollar-to-bitcoin-to-dollar conversion at the point of payment. Or you could imagine a bitcoin2.org that generates more coins. Or you could hope for a massive surge in the value of the bitcoin.
I'd put my money on Paypal sticking around, though.
I bet you could make some money facilitating lower fee transactions backed by bitcoins.
Also, the site owner could just trust the client to actually run his/her bitcoin-generating code for a couple of hours and send any generated coins - this should earn him/her ~$0.20/hour, rounded down because lots of people have crufty computers. Still not feasible, and generating bitcoins will only get harder in the future, but not as bad as I suggest below.]
Sure, if you're willing to leave your browser consuming 100% CPU for a couple of weeks. And if you're willing to pay the entire resulting 50 bitcoins (~$40-45) you generated (at the cost of ~$60 in electricty, I'd guess), or trust the site to return you the rest. In either case, you'd need to trust the site code to tell you that it's generated a coin, instead of silently sending it back to the server and continuing to run.
At least, that's my understanding of how bitcoins work.
 Only GPU-based generation is currently profitable, and there's no way NaCl can be given full access to the GPU - GPUs typically have DMA access, so being able to run arbitrary code on them is more or less equivalent to kernel-level access. In theory, you could verify the GPU code - but that's an enormous job, and there are lots of GPUs that you'd need to check for security holes. And security was not design criterion #1 for these devices, I'd guess.
Something like DirectX/OpenGL access makes sense, but running crypto algorithms through OpenGL (instead of CUDA or the like) is probably infeasible.
Still, you need to take fees into consideration. Also, the seller has to pay another PayPal fee when transferring the money every month.
PayPal's TOS specifically prohibit running a payment gateway or aggregation service, ie collecting payments on behalf of many sellers and then re-distributing the proceeds.
A service like this would almost certainly draw their attention, since one could be selling warez, pr0n, stolen credit card numbers, or any number of other naughty files through this service...
Someone else posted a tale of woe within the last month about their "experience marketplace" getting impounded by PayPal, ostensibly for the same reason.
<<The solution was first announced last October when the company said that the upcoming feature would offer "a competitive fee structure for micropayments, with pricing at 5 percent plus 5 cents for purchases under $12.">>
The only thing that I've seen that was commented on, but not objected to, is that it's 'similar to' PayPal fee structures. But even that's up to being refuted.
1) How soon until the money reaches PayPal?
2) There are no assurances that the CC data is safe. It looks to be sent over HTTPS, but you're assumed to be trusted.
(TweetDeck, Beluga two examples)
First, anyone who pays and gets to the resulting link can trivially share that link; of course, you can always ask them nicely not to do so, and in some contexts that will work, but in general the security model just doesn't work unless you authenticate each paid user at the destination. You need to come up with an answer to this.
Second, if you market this as a link shortener which requires payment, I think you'll get backlash from people who currently use link shorteners to share links on Twitter and similar; from that perspective it feels like the kind of thing you'd see used by Twitter spammers/scammers. Suggested fix: flip it around, and present it as an astonishingly simple payment system based on URLs, which happens to behave like a shortener.
Keep in mind that this is digital content so anyone could just rehost/resell/redistribute anything they bought or downloaded. But for something low-payment enough or the average silly download, why would they bother?
It's important to tell sellers that it's insecure so they don't assume it's locked, but please don't complicate this by adding DRM or sharing prevention. The most I'd do here is track downloads and let people kill their link and repost it if they sense abuse.
I actually wouldn't recommend adding DRM or sharing prevention. Instead, I'd just add a lightweight system to make it trivial to know who shared the URL. That will likely do wonders for getting people to play nice.
Optionally, you could add proxying through the gumroad site as an extra feature (perhaps at the cost of a higher margin on the sale), for people particularly concerned about the issue.
You could get around the link-sharing problem for those that wanted to avoid it by offering single-use URLs, and provide Gumroad either with a way of generating a new single-use URL for your resource, or a way to pull a new URL from your site. Both of these methods would require some degree of control over the resource, however (you wouldn't be able to do this for content hosted by third parties).
For those who aren't fussed about security, you could offer it as a really easy way to optionally pay for content - eg a rapid "Donate" method.
For each page request we'd generate a link to the file on BitGravity with a timestamp, expiration, and filename, and a hash generated from those concatenated with the requesting IP and a secret key. On BitGravity's end, they'd re-hash everything, and if it matched up they'd serve out the file.
The way I'd see it working is, I give Gumroad a link I want users to pay for, and Gumroad charges each user, serving up the content, but never sharing with them the link that I gave Gumroad. You could do this by fetching the content on the back end, and serving it up through Gumroad's own single-use URL.
Kind of tangentially, I wonder if there's value in letting a user select a charity to donate all of their sales to (no pressure on the user, just an option)?
So in a sense you don't care if people share the link for that period... maybe you even want them to, like a time-limited offer, so that they post to all their friends, "get it while it's hot!"
(The price could also rise or fall after each purchased open-period... perhaps even, depending on the number of downloads during the last open period.)
Your links can be one of two things: 1) a webpage, 2) a file.
For a file, I wouldn't worry about the DRM, as a person serving the file can have their own system, or you can use the system I'm going to propose for serving a webpage.
Essentially just use an iFrame.
So you have your public link: gumroad.url this leads to a paywall which then sends you to an auto-generated one-time link of gumroad.paidurl. This url is a simple page that loads an iFrame with the real private URL.
So gumroad.paidurl and gumroad.url both go to a paywall when user 2 tries to access it. And either paidurl or url will be the one that's shared. Yes, people can circumvent it by looking at the source of the iFrame, but 95%+ of people won't bother, and it's a heck of a lot easier than downloading and displaying the page through AJAX or server side.
I agree that the link shortening aspect of this site cannot be it's product. Emphasizing that at all can detract from the truly novel idea that exists in selling and buying micro-properties of internet knowledge. People need to see the incredible nature of a site which allows you to sell information which has high demand and low supply, but has no other method of paid distribution. For everything too small to put in a book, and not small enough to just give away. I think its brilliant.
In secret.php on your server you could then ask the Gumroad API (via another http request) how often this key was already used and deny or allow access. This would be super easy to implement for the seller - just paste in ~5 lines of PHP code.
Of course, I don't make the profit. The syndicate makes the profit. And everybody has a share."
-- Milo Minderbinder, Catch 22
File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 634, in __call__
File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 60, in get
File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 110, in is_logged_in
s = sessions.Session()
File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 562, in __init__
self.session = _AppEngineUtilities_Session.get_session(self)
File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 142, in get_session
ds_session = db.get(str(session_key))
File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1422, in get
keys, multiple = datastore.NormalizeAndTypeCheckKeys(keys)
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 180, in NormalizeAndTypeCheckKeys
keys = [_GetCompleteKeyOrError(key) for key in keys]
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2339, in _GetCompleteKeyOrError
key = Key(arg)
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore_types.py", line 364, in __init__
raise datastore_errors.BadKeyError('Invalid string key %s.' % encoded)
* Money laundering. Cap fees now.
* You are using Stripe, but you're still collecting CC data. Are you PCI compliant?
* Does Stripe allow you to do this? Really? Basically, you're acting as a third party processor, an IPSP. People can sell anything through your service (Think adult content)
I'm really interested if Stripe is aware of what you are doing and fine with it.
Glad the fees are capped. I saw a $100 link, so not sure about what the cap is.
As for collecting CC data, if it's passing through your code, even if you don't store it, you are accountable for it. I've seen the silliest things with people claiming they aren't storing CC data. And yet, you can browse file after file of automatically generated logs that contain raw CC data.
That you aren't storing CC data makes your life easier. However, I'd still review what you are liable for just in case. I don't say any of this bash you (I really like the idea!), but so you avoid any problems that cause you to shut down (because it's a cool idea!). I've been doing this for 10 years now, and as soon as someone opens up a payment system like this, money laundering and other schemes will review how to abuse it. So when I see something like this, I get nervous. I ask: how would I exploit it.
Maybe you should write a guide of all the ways you've seen people go wrong and the best ways to do things (and why). That could be useful to a lot of people on HN.
I take what I know for granted too much, I think.
" onclick="alert('do evil here')" onfocus="alert('do evil here')" foo="
It's great you've escaped < and >, but you need to do more.
Kidding aside, I dare you (not sarcastically, I would love to see another approach to the same problem).
Don't get me wrong. You did a great job getting this rolled out over a weekend and it looks nice. I must need some enlightening because I really don't get it.
Instead of setting up a store somewhere to list your ONE item, you put the template up on your website and link to it through gumroad.
Then, you give out the Gumroad link on Twitter: "Need a sweet Fireworks iPhone UI template? Buy it for a buck: gumroad.url"
Your twatting friends click it, give you a dollar, get redirected to your website. They download the template, you get a dollar - all in like 2 minutes while your oatmeal was cooking.
If this really is possible, you'd have to create a user who is somehow whitelisted to get the linked item in question.
(Hmmm, you may need to give some thought to legal questions raised when you're suddenly making money by selling every possible type of pornography into every jurisdiction of the world.)
If I had a bunch of files laying around my FTP that I never sold and would like to sell off for $5 a pop without the overhead of creating a store - I would use Gumroad.
Does that make it any better in your mind?
Also - once you've been redirected to the page, what's to stop you taking the link and sharing it yourself?
Also also: if I've got something to sell, can't I just bung it on ebay?
The second question has been answered.
This is a completely different model than ebay.
These are really bad questions. I'm not putting you down - its no big deal, but just a little critical thought should answer these for you.
But that's the whole point. There's nothing that allows a seller to do this at the mo.
> The second question has been answered.
Sure, after my post. The answer to which seems to be "there isn't". So a valid question.
> This is a completely different model to ebay.
Perhaps from the platform's perspective, not from the sellers. The motivation is to enable someone to quickly put up an item for sale. I can pretty damn quickly put up a single item for sale on ebay too.
You are completely wrong. The model is entirely different from the seller's perspective. See the author's original comment. I've included it below.
>How does this work for art though? I mean you want to see the icon/graphic/design/whatever before you pay for it.
This is also answered by the original comment.
"There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store."
The seller will be sharing a link with a person who they have a seller/buyer relationship with. The product in question is the last step in a process that the seller has complete control over.
No more of this. Cheers,
Right - and putting something up for sale on ebay and sending people the link is different... how?
Not sure how you would sell JS scripts since showing a working demo would require the file to be accessible to the user.
This can't be a minor problem, either. At any given time the percentage of your users who are being ripped off by some nasty scam will be between 10% and 90%. You'll have to be very careful about policing things, otherwise the first mention of your business in the media will be "gumroad enables porn bait-and-switch scammers".
If you only redirected based on successful payments, you could use this as a simpler paypal for charging clients on your site using unique gumroaded links.
If anyone buys the access to a a non-unique-link (ie: http://mybook.com/book.pdf), and then shares the redirected URL to a third person, this third person could load the link without paying, right?
This doesn't take into account all cases but a good chunk to start with.
You're being shared Gumroad!
With the "You're being shared". Sounds confusing.
If I buy something am I buying it from you or from the original owner?
How long do you hold onto the funds to deal with any potential chargebacks?
I think all content should be uploaded to your servers otherwise if someone gets to the final link they can just send others to it.
Also how do you deal with chargebacks?
Also link shorteners + asking for credit card information immediately can get iffy in terms of trust and fraud. I understand that it is an mvp though. Later you might be able to employ a buy credits system like istockphoto does.
How long until exact clones appear? What makes GumRoad the micro-paywall of choice?
How long until shortened<-->lengthened websites appear which reduces how many people pay up?
http referrers are easily spoofed, of course, but it'll be enough to prevent most people from sharing secret urls on twitter. You could also pivot and allow people to upload files to your own server, but that's a different story.
Digital sale processes still need streamlining for everyday users (especially one-off users) and I can see a service like this taking off.
To me it brings up an image of a road, covered with gum. I'm trying to get where I want to go, but there's all this gum on the road slowing me down. It's a huge and annoying obstacle. And that is a bad mental image, given that what you're selling is a sort of obstacle.
It's not too late for a different name.
Feature request: use the top half of the screen to show a preview of the linked page rendered as a PNG. Use the other half of the screen for soliciting payment. I want to know what I would get with the payment. How much of the target page is shown should of course be configurable by the page owner.
One interesting one for me, which is more an oversight, is that anyone can make money off of the sale of a link. There is no way to validate that the person posting the link, is the owner of the content. So someone could sell links to a page on HN, Reddit, Techcrunch, etc. at no expense to them.
If this did occur, I think it would cause a quite negative view of Gumroad links, as being scammy. In which case, people would begin to avoid them, reducing their effectiveness as a possible sales medium. Without oversight, as to who is selling a link, this might end up smothering itself out.
You'd have to write up some very specific usage scenarios that make that cut viable.
Apple's cut makes sense so far that you get some tangible advantages in terms of such things as exposure. You'll have to explain people what they get for the 30% cut.
Right now, I'm unconvinced that you get 30%'s worth. But, on another note, it's probably always better to start at a high price and dial it down than to launch a product and increase the prices over time. People will be crying bait and switch - justifiably.
PayPal's micropayments pricing is 5 cents plus 5% per transaction so this combination can be a big money saver.
We created a service for a niche market that was mostly using eJunkie at the time (lowest cost, word of mouth travels fast among groups of sellers) and we had to compete with them on price and features.
What if you went with max (5%, 0.01/MB)? 30% of 0 is still 0, after all.
30% is definitely high. I understand 30% has become a buzzword these days, but in reality it cuts a lot into merchants' margins. You may want to research on current digital goods market sites such as e-junkie, payloadz etc. Most seem to have a combination of monthly pricing and a "low" per transaction fee. Monthly fee certainly going to be a barrier for casual merchants.
After doing some quick research I found five or six sites with similar ideas. Most of them focus on selling digital files not links. The link idea sounds novel. The presentation is also very clean. Looks good.
How would this have played out if eg. Dropbox had run their challenge on top of Gumroad?
I'd like to see a "pay as much as you'd like" feature, where you can set a minimum amount (like radiohead and girl talk do) but still allow them to pay more.
Developer ≠ Businessman
Best of luck with it!
this tool should encourage casual use
it makes a perfectly simple product complicated.
please overthink your pricing-strategy. make it as simple as possible, iterate from there.