Over this past weekend I had the idea to build a sort of link shortener but with a payment system built-in. 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.
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).
I love the idea! This makes it really easy to sell scripts (e.g. your own jQuery plugins or whatever) for $5 where it would normally be too much work to set up some payment processing.
The 30% cut is way too high though. Especially for higher priced links - I wouldn't want to sell my $99 game engine[1] 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?
I disagree. Take a bare minimum of 15%. That seems to be about what's competitive for non-merchant-account payment systems. You'll need to keep margins up.
Exactly. And keep in mind, you're competing against someone setting up their own web store. If I didn't use your service, I probably wouldn't go through all of the trouble of setting something up. In that scenario, I make $0. If you charge 30%, and I price my stuff at $10.00, I make $7 per transaction, which is $7 more than I would have made without your service.
No, that's definitely a good point. I'm going to switch to a .30c + x% (tiered) model - aim to make at least $70-80 of that $99 if you use Gumroad.
I'm also thinking hard about "Preferred" accounts. Basically, you send an email to sahil@slavingia.com 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. ;)
I can't imagine bitcoins in their current implementation gaining traction as a form of payment with 'regular folks'. I mean the whole idea is complicated enough that even I as a technically minded person have trouble fully understanding how it works.
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.
> Bitcoins [...] _could_ become as universal as PayPal is today
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.
The obvious hole in your chain of reasoning is that "$0.70/bitcoin" would obviously change when every American attempted to fill his wallet with bitcoins.
Bitcoins probably won't take off (cf the failures of all the other alternative digital currencies so far), but the whole number of bitcoins is no more a roadblock than the limited number of ounces of gold in the world was to getting everyone using gold as currency. The problems basically lie elsewhere.
I'd put my money on paypal sticking around, but I'd also expect the volume on the Bitcoin/USD markets to increase as the value climbs (presumably from rate of new bitcoins from mining declining). I think we could see services using fractional bitcoins behind the scenes and USD (or euros) end to end.
I bet you could make some money facilitating lower fee transactions backed by bitcoins.
[EDIT: the text below is correct, but a bit too snarky. My apologies.
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)[1], 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.
[1] 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.
I like that idea. It seems like microgeneration is a feature Bitcoin is currently suffering from a lack of. As competition increases, generation seems to be more and more centralized. A low-traffic way to generate small amounts of Bitcoin in a peer-to-peer network would be a great addition to a future Bitcoin protocol.
This doesn't seem like a good match. With different hardware and prices of electricity out there it would be hard to make the system fair for everyone. Also, although minting coins is an important feature of Bitcoin, it seems there's a certain amount of miners needed to offset threat of fraudulent transactions; going significantly above that amount is just wasting planet's resources.
You definitely don't want to use PayPal for a service like this, unless you want to lose all your un-swept earnings when they catch on.
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.
And it has to be a completely separate account. They basically force you to either pay way too much or violate their terms by having two separate accounts. :/
<<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.">>
Suggestion: you should now build a second app which generates a stream of single-use urls that are invalidated as soon as they are accessed, and which proxy through to an original base url. Then hook the two apps together and profit.
I would include a sample URL or two on the homepage - I was confused as to how I would get people to buy/what the sales page would look like - but thanks for clarifying with the attached URL.
Cool idea! One quick thing: I would change the
"(Minus our cut)"
wording to something a little more friendly. Maybe transaction fee or something along those lines.
Love the idea! I'd also love a thumbnail/pic for each link, though. Something that might give them a little more evidence of what they're getting into.
Stripe reps have stated repeatedly that whatever their fee structure looks like right now, it's not representative of what it will look like when they come out of beta.
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.
Wow - that's fast feedback! On a separate side-note would you be interested in early access to apps for similar sort of reviews / blog postings, or is that inappropriate to ask?
That's not inappropriate to ask at all. It's a fun hobby. Look through my site and you'll see I've done this a long time and have some big wins that launched first with me.
Interesting idea, but I see two main issues with this.
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.
I think #1 is a bit of a red herring. The security problem is not what this is solving. It's the ease of getting paid for some content, with less hassle overall.
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.
The difference: sharing the file violates the original author's copyright, but sharing the URL to it on the original author's site doesn't.
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.
That second formulation is how I thought of it in the first place.
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.
We used something like this for our content at Naughty America.
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.
To address the first problem, you should offer a passive solution and not require the user to set up anything special in the way of single-use URLs. In fact, I assumed the issue of payers sharing the end-link was such an obvious problem that the service would have already addressed this and had it built-in by default (but of course, MVP/first-release, I understand).
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.
Sure, that would make sense for content that could be so served (for example, the pencil icon used as the example here) - but not all content is like that. What about content you want people to interact with (a blog post on your site, a special beta registration form)? You also take on all the problems of becoming a content distributor rather than a link distributor.
I agree with everything you said. If this were my project, these are all problems I'd be thinking about and trying to address. Looks like you're on the right path ;-)
and I would add that the content distributor problem is also a good one to solve (with your solution). May even be more profitable... a lot of people want to sell stuff, not link.
Interesting, I didn't think about the implications of "donate."
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)?
Another interesting variant might be: payment unlocks the destination link for X minutes. (After that, the true destination URL is changed somehow. Yes, that adds complication on the true hosting site or the necessity for Gumroad to proxy.)
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.)
I like the idea of the proxy, why not have it so you do a direct link and gumroad takes a small percentage (1%?), and if you want it proxied gumroad takes a bigger percentage (5%-10%)?
Here's how I would structure things to mitigate link sharing. It won't prevent it entirely, but will reduce it about 100x without affecting UX.
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 haven't thought much about this solution, but wouldn't it be simple to just proxy the content back to the user? This would work fine for downloadable goods, maybe not so much for secret links to sites.
Think long term adjustment to the mentality of the site. If that link was worth something, why would the buyer just give it away? It's possible that the buyer would try to sell it and compete with the original seller, and all subsequent buyer might follow, but that would be something the original seller could take into account in pricing their product.
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.
You could allow access to that link about 5 times. After that, display a link that says something along the lines of "Thanks for using us. This link has been used 5 times already. If you wish to access it again, click here and we will send you an email with another authorization code (or whatever)".
That way your users don't lose access to their stuff, and you can keep track of abuse. It's not a perfect solution, but it's better than nothing.
"But I make a profit of three and a quarter cents an egg by selling them for four and a quarter cents an egg to the people in Malta I buy them from for seven cents an egg.
Of course, I don't make the profit. The syndicate makes the profit. And everybody has a share."
File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 634, in __call__
handler.get(*groups)
File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 60, in get
if is_logged_in():
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)
* 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.
That's cool. Far too many people ignore what a solid relationship with the upstream payment provider can give you.
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.
> 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.
That's not true. If CC data is passing through his system, their are things he needs to be aware of. You'd be surprised at the logs that are generated by people who don't store credit card information. Somehow, that unstored CC information winds up in a random logs directory, unencrypted and open for anyone to see.
I'm no expert, but I don't think this is true. I've witnessed a few payment systems being implemented, and just having this data pass through your system you need to adhere to some compliance rules (which are softer vs. actually storing the data though).
Correct. We are doing a PCI compliance certification right now, for a service that does the same CC flow as this. We don't store, but just forward. But even that requires a PCI certification.
Coming from direct QSA experience, you can be liable for CC data if you are collecting, transmitting, or storing the data. Basically any touchpoint in the flow of CC data you're involved in holds you legally liable for PCI-DSS. Kind of like speeding on the freeway... doesn't really matter until you get nailed doing it, and PCI council fines are devastating. I'm glad to discount our product extensively for any bloggers here... https://www.secure128.com/trustwave-trustkeeper-pci-complian...
Just drop me a line to say hello and I'll give you whatever price you feel reasonable.
As with many ideas I see floated and mvp'd on HN, I'm jealous. Great idea, good execution. I'd agree with others that the 30% is too high. 5-10% would be acceptable.
Seriously? I'm not sure I could take anyone seriously that tried to sell me a link of "value." Why not just share the link for free like people have been doing since the beginning of time?
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.
Imagine you have a Fireworks iPhone mockup template.
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.
For many of the things that people might want to do, a "patronage" model isn't so bad either: the creator demands $1000 for the work behind the link; people can leave an e-mail address and pay anything from $1 to the full remaining price, and will be notified as soon as the work is available.
I think this has tons of value, almost like a mini-kickstarter without the need to advertise for a kick for communities of people (forums, etc) who want new features or some kind of quick bit of work done.
Disable direct links and proxy the content, that way you can create unique URIs for every buyer. Then you can do all sorts of things like add a watermark on the content page containing the credit card number of the buyer or just add expiration time to the links. That'll limit sharing somewhat, although I don't think it's a huge problem.
More likely usage scenario: pornography. Niche pornography.
(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.)
I think there are some links that do have value. For example, if I wanted to release a new web app to my Twitter followers but wanted some sort of barrier (without having to set it all up myself) - I would use Gumroad.
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.
What's being sold isn't the "link" but ability to access what it points to - an image, a blog post, etc. I think it's a great idea with oodles of potential - a link-based mini-paywall :).
Loving the simplicity of the idea. The simplicity is worth a higher cut (though maybe not 30% ;-)) and makes it a lot more attractive to use in small situations. One thing you need to beware of, though, is the filing requirements.. you might have to start issuing tons of 1099s and that process will cost you.
If this becomes a high traffic site, it could really help fight internet piracy. If I have a high demand, hard to find video, I'm far more likely to try to sell it than just give it away. And even if I can't because the site is closely watched by the actual copywriter holders, the idea that money can be made off any online property can give internet knowledge and assets the feeling of physical worth, to the degree that people may grow hesitant to just give away their video and music files. It also has potential to detract from the information free-for-all of the internet, as people may also grow hesitant to share in general, but that would only be for sellable things, so blogs and general information are basically out. If successful, this site could make major change in the attitude of the internet. In essence, conflict exists between copyright holding companies, who believe their intellectual property should be paid for, and the general population of the internet, who freely share information constantly. This conflict could seriously benefit from a general shift toward the resounding feeling that information and online assets are worth something and should be bought and sold. That could be of serious detriment to the culture of the internet, but the communities could also gradually adjust. After all, the feeling that assets have monetary value is the way we live in the real world, its only a matter of time before the internet starts to follow.
In the world of payments, that doesn't really matter at all. Payment processors can't afford to have high fraud % customers, so if fraud becomes a problem they'll just drop him.
Come on, if you want to see the icon/graphic/design/whatever before you pay for it obviously the seller can show you a smaller/low-res/watermarked/whatevered version.
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.
> If you want to see the icon/graphic/design/whatever before you pay for it obviously...
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.
> 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.
> "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."
Right - and putting something up for sale on ebay and sending people the link is different... how?
I'd like to think that this has lower overhead than eBay. Nothing is there to stop you for now - I think this is more for casual use than building an entire business on top of. Yes, I'm thinking about adding in a preview option with cluttering up the experience.
Yes, how do you deal with the (hundreds, thousands, millions) of annoyed customers per day who were promised one thing but wound up paying for another?
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 the payment fails, will you still redirect to the link?
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?
Yup. For now, there is no security built into the link once you get through that payment wall. I'm thinking about how to do that without hurting UX - though it's low on the priority list anyways.
If you potentially host the files/keep track of static/unique URLs on your site, you could keep track of who is the first owner to ensure that no future users also claim to be the owner and resend the file/link as their own.
This doesn't take into account all cases but a good chunk to start with.
Traceback (most recent call last):
File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 634, in __call__
handler.get(*groups)
File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 60, in get
if is_logged_in():
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)
BadKeyError: Invalid string key agdndW1yb2FkciMLEhtfQXBwRW5naW5lVXRpbGl0aWVzX1Nlc3Npb24Y.
Am I missing something or could you just employ a download method rather than link? Maybe something like how istockphoto does it. Although the link leads to a purchase terminal, if they make the purchase it would prompt a download rather than a link they could share.
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.
Traceback (most recent call last):
File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 636, in __call__
handler.post(*groups)
File "/base/data/home/apps/gumroad/1.349498677539326613/main.py", line 292, in post
db.delete(link)
File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1491, in delete
datastore.Delete(keys, config=config)
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 516, in Delete
keys, multiple = NormalizeAndTypeCheckKeys(keys)
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 178, in NormalizeAndTypeCheckKeys
keys, multiple = NormalizeAndTypeCheck(keys, (basestring, Entity, Key))
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 157, in NormalizeAndTypeCheck
(types, val, typename(val)))
BadArgumentError: Expected one of (<type 'basestring'>, <class 'google.appengine.api.datastore.Entity'>, <class 'google.appengine.api.datastore_types.Key'>); received None (a NoneType).
You can tell clients to check the http referrer for your domain. That would (mostly) stop people from posting now-useless destination URLs online.
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.
That would hurt the UX. For example if someone gets the link to a blog-post-in-the-making they shouldn't have to go through Gumroad to access it every time.
Brilliant little idea, I think the big selling point is speed and ease of use. I might create a similar product to this for BitBuffet.com (a similar file selling service I created), as I think the process can be further streamlined.
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.
Huh...I guess that makes more sense, but actually my first impression of the name was to think of Candyland. Like the Yellow Brick Road, but with gumdrops and such. Cheesy, but positive. I wonder which interpretation is more common?
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.
First off, I like the idea, but there are some noticeable flaws, many which have been brought up.
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.
While providing an authority model is often a great business, it's a fallacy to say that provenance is mandatory to be taken seriously. See: Twitter, eBay, 4chan, TechCrunch
I saw it mentioned here already, but the idea of a "Name your Price" option would be really cool. Just like how Bandcamp does it. I'm always more motivated to support artists that chose this option.
Honestly, I'm not sure - hence them not being listed - but I think I'm going to go with 30%. And then for people making >$x a month dropping that in tiers. Thoughts?
30% commission is for when you are selling people's stuff for them. Unless you have a huge audience who can't wait to buy random stuff on the internet (like Apple does), 30% is outrageous. If Paypal started charging 30% commissions on money transfers people would drop it like a hot potato.
Yeah - I'd rather try my luck at Kickstarter and pay their 5% fee and PayPal's 2.7%.
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.
Or eJunkie - it lacks the (apparent) simplicity for but for $5 a month you can make an unlimited number of sales for up to 10 digital items and then you've got PayPal/processor fees on top of that.
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.
great idea, but if your site is getting traction, you'll have to face tons of imitators -- after all, you already said that this is a weekend project. They are going to undercut you like crazy if you are doing 30%. So might as well make it as enticing as possible, maybe just 3% overhead (or even 1%).
My recommendation is to establish the %age markup based on file sizes, since that would be the basis for infrastructure costs such as storage and bandwidth.
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.
I've been thinking about this exact problem for a few weeks now. I have gone as far as buying a domain for it (epayfiles.com) and I just started coding. I think I'll continue on with my project I'll just focus on a different payment niche.
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.
There's some potential for gamification here. Here's a Gumroad URL which, when paid for, unlocks some kind of challenge that you must solve in order to find a new Gumroad URL. Which unlocks another challenge that leads to another Gumroad URL, continuing for n steps until you unlock the final reward. Each step costs less than a dollar.
How would this have played out if eg. Dropbox had run their challenge on top of Gumroad?
I like it, there's a lot of functionality missing, as you said but tons of possibilities.
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.
Why wouldn't stripe just implement this themselves? Since their payment processing service (and API?) is 99% of the project, seems like they'd make their own and cut you off if this gained any traction.
One? That sounds like a rather awesome API, unless you just redirect to a payment processing system over on their site. Mind sharing the one line of code? :)
Just a caution, if you are taking in money via paypal and then paying out via paypal, paypal will probably shut you down within a month. They don't like competition.
i love the idea, i hate the new "We have a tiered system for pricing:" basically it says: if you earn less, we will take even more. so basically if - lets say - earn 2 dollars (casual user who sold a psd template for 1$) this service now takes 2$ - 230c = 1.40$ - (1.40$ 0.3) = 98c
this tool should encourage casual use
and
it makes a perfectly simple product complicated.
please overthink your pricing-strategy. make it as simple as possible, iterate from there.
please tell us when the first (real) vc are knocking on your door ... this is just awesome and has more potential then the most startups covered by techcrunch and co
Nice - how about this as a feature: # of downloads allowed. This would allow people to sell just 1 copy or set up something like a groupon-esque clone. First 50 people get 50% off. Then after 50 people say you're too late. Just an idea.
I really like this idea, especially for art. It solves the "what if someone just passes the final link around" problem because if you're getting 1 of 25 copies of something you're less likely to go out of your way to reduce the rarity of the item you bought.
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?