81–90 of 215 posts
* 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.
Earlier quoted context omitted.
Trying to sell the link to Gumroad for $100?! Stop trying to profit off of my work! :D
It's profit all the way down.
Of course, I don't make the profit. The syndicate makes the profit. And everybody has a share."
-- Milo Minderbinder, Catch 22
Earlier quoted context omitted.
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 ;-)
Earlier quoted context omitted.
No, it isn't. Bitcoins are clever and all, but how many people would be willing to set it up just to see a link?
Just a crazy idea, when something like NaCl catches on perhaps gumroad could generate bitcoins client-side in lieu of payment?
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.
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 o…
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.
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…
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.
What do you plan on doing about fraud? Seems like it would be way too easy to move money around with stolen credit cards.
He's not doing the payment processing, Stripe is.
Things you have to look at fast. * 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.
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 o…
I've tried it and purchased on my own link. 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.