Amazon forces Unglue.it to Suspend Crowdfunding for Creative Commons eBooks
blog.unglue.it
blog.unglue.it
Amazon is not the first to suspend taking on such accounts until they have better grip on the regulatory implications.
You hand over your credit card upfront in anticipation of a possible payment in the future.
I think the real problem here is classifying crowd funding as a product purchase or an investment.
Is it possible the reason is because kickstarter is not interfering with their primary business?
Seems like a pretty straightforward transaction to me.
An online business is actually less useful for laundering than the brick-and-mortar shop, since you don't have cash payments.
They treat their 3rd-party sellers like garbage. They make up a large percentage of their yearly income and don't even offer any kind of support beyond automated responses. Amazon also doesn't keep the same standard of service as their sellers.
They have bots that will auto-ban your account with no recourse.
If a customer complains, they get their money back in 99% of the cases (even if it's > 1 year later) without ever having to return the item (I got scammed by many customers this way). Amazon also has no way of banning a customer, so they can keep doing it, leaving you negative feedback, and their bots will auto-ban you (good luck getting it un-banned after this happens). So you end up losing all of the money and the item you sold.
If I buy an ipad and complain, Amazon (If I'm buying from Amazon.com..and not a 3rd party seller) will make me return it before I get a refund.
I was a seller for many years and finally called it quits. They know they can get away with it because they are biggest site on the Internet (besides Ebay).
Ebay has its problems, but at least you are treated with respect as a seller. After moving everything to Ebay, all of my problems went away.
What's wrong with that?
2. Numerous companies already use us so our api is battle tested and offers all standard features (all or nothing, real time charges, split payments...etc)
3. Smooth and quick onboarding process for fundraisers using an OAuth 2.0 flow. No disjointed flow or long application process for your fundraisers. They can accept payment directly in their WePay account.
4. No redirect on checkout. Pick from an iframe or tokenization. White label experience for your donors.
5. Our api was built for marketplace/platforms.
With all the payment services available, why go with the one that is run by the company that your "business model" threatens most?
Edit: ok... not knowing exactly how delayed payments work for pledge style funding, I don't know which payment services can handle that. As far as other options, there are many. I just don't know if any others will handle the delayed payment part. If the options truly are only PayPal and Amazon then I see a huge hole that needs to be filled.
UnglueIt could cut Amazon out of that entirely. Rights holders would get the money directly and Amazon would get jack. May be it isn't about that but they would never admit that anyway so who knows.
Lots of self published authors use creative commons work as a cover art, so it even can be creative commons licenced.
Many books are sold on the Kindle Shop without DRM. Some large publishers (e.g. science fiction publisher Tor) is selling books on the Kindle Shop without DRM.
We'd love to hear of alternative payment systems. I'm looking at using subscriptions in https://www.braintreepayments.com/docs/python/subscriptions/ to simulate conditional payments. http://www.quora.com/Online-and-Mobile-Payments/What-payment... leads to https://www.wepay.com/ and https://www.balancedpayments.com/ I'd love to hear of people's experiences with these payment systems and any others we should look at for unglue.it
Then, you have the issue as to whether or not the card has the amount available in the future when you intend to charge it...
If you use SpreedlyCore, for example, you point your signup/billing form to their server, which stores the card data then redirects back to your site, so the user never sees anything but your site yet the payment data never hits your server. If you use Stripe, for example, the form submission gets intercepted by JavaScript that sends it to Stripe instead of your server, then returns a token in a callback. If you use services like these, there's virtually no compliance burden at all.
> Then, you have the issue as to whether or not the card has the amount available in the future when you intend to charge it...
You'd have that issue whether you used a 3rd party processor or your own merchant account. Amazon Payments wouldn't have given them money when the customers' cards had no funds either.
BTW: There is no PCI-DSS or PA-DSS level that allows storing of verification codes, for either businesses or payment software companies. The whole point of that code is that it's never stored.
"No, you simply send the card details to the payment gateway which vaults them. You get back a token to reference to make the actual charges in the future. You don't have to do an authorization up front. Virtually every payment gateway has such a feature. There's no need to implement storage on your own and take on the compliance burdens."
Neither Authorize.net nor MES do. (Two of the largest in the US, that I've been using for the past few years.) I only know of a few specialized players that offer such functionality.
http://www.authorize.net/solutions/merchantsolutions/merchan...
http://merchante-solutions.com/files/MES_PaymentGateway.pdf
I'm surprised you've been using these gateways for years and didn't know about these features. CIM is prominently advertised on the first page you see every time you log in to the gateway.
I haven't had either of those features enabled in my UI, but that wouldn't surprise me as I've often had to ask them to re-enable basic features (like backoffice w/ MES) when they get accidentally turned off. I'm presuming these features need to be negotiated as part of the deal, and as I haven't needed them, they were never brought up.
With Braintree you could put customer CC numbers in their vault and then manually run the transaction later, but it'd cost you a flat fee plus a penny or two per/card/month. (They do support running validations without completing a transaction.) It doesn't seem like the end of the world, though. And the architecture isn't super complicated. I assume you already had to handle telling Amazon whether to go through with the charge or not after the time period? Maybe Amazon also was keeping track of the pledge amounts for you?
(Contrib Id or Card Id, Pledge Amount, Campaign Id) doesn't seem like that crazy of a thing to store on your own system.
If there are other processors that support pledges, we aren't aware of them (though we welcome suggestions!).
We're working on an alternative funding model that lets us deal with this, but that's a question of business logic as well as software. Mind you, we have a fair amount of both in place already, but there are a lot of moving pieces. We'll keep people posted via our blog, newsletter, Twitter, & Facebook page.
What you can do quite easily with WePay is to send bills by email, each including a link to the payment page with the amount filled in. This makes it pretty simple for people to pay at that point. But it isn't, admittedly, automatic, and some people could ignore the bill. I don't know how big a problem this would be in practice.
This makes crowdfunding projects like this a little tricky, since they doesn't map well to the legal agreements that make up the existing payment systems.
I think the legal gray area comes from customers believing that they are buying a product from the crowdfunders. This is covered by an advisory by the FTC; to be covered by dry-testing exception, the following conditions need to be met:
* In promoting the merchandise, the merchant can make no suggestion that the merchandise will be shipped or that customers expressing an interest in it will receive it.
* In all promotional materials, the merchant must disclose all material aspects of the promotion, including the fact that the merchandise is only planned and may not be shipped.
* If any part of the promotion is later dropped, the merchant must notify subscribers of the fact within a reasonable time after soliciting their subscriptions.
* If, within a reasonable time after soliciting their subscriptions, the merchant has made no decision to ship the merchandise, it must notify subscribers of this fact and give them the opportunity to cancel and, where payment has been made, make a prompt refund.
* The merchant can make no substitutions of any merchandise for that ordered.
It seems obvious that crowdfunding efforts don't meet these criteria.
[1] http://business.ftc.gov/documents/bus02-business-guide-mail-...
Those are serious questions that only a lawyer can answer.
Uh, no. By that definition, every transaction would be an equity transaction.
Equity specifically refers to an ownership interest in a business.
Wanted: a dedicated backend for crowdfunding that other businesses can leverage for their crowdfunding projects.
The only two competitors are Paypal and Amazon Payments, and they should be easy to beat because they are actively turning away legitimate business.
In other words: if it were "that easy," there'd already be a lot of competition. But, Visa et. al. aren't real big on letting just anyone be direct inputs to them and the kinds of activities we're talking about here look a lot like fraud to existing ISOs/MSPs.
Even if there were some non-discrimination law that touched on this sort of situation, it's not inconceivable that they view Unglue.it as competing in their core market. I can't imagine many cases where a company would be legally obligated to provide services to support a competitor. (Sure, local phone utility companies are in that situation, but that's for solid historical reasons related to government backing of their monopoly on infrastructure.) [I'm obviously not a lawyer or an expert on these things, so corrections are welcome.]
For instance, I have a coworker who keeps insisting that Apple should have been hit with an anti-trust suit like MS since they only allowed the Safari browser on iOS (for a time). He was dead serious (for some reason he truly hates Apple and wants to see the corporation fail, still owns an iPhone though). It was based off a flawed understanding of the laws and the markets the laws apply to. A lot of people seem to jump to the legality of the actions of the group in charge of a particular platform without considering whether that platform is one of a larger marketplace.
As other comments have noted, Amazon has decided as a matter of policy not to accept new crowdfunding customers until the legal and regulatory issues (i.e., money laundering, refunds, undelivered goods/failed projects, etc.) are worked out.
You can still use Paypal (takes a long time to get approved) or Stripe (you must set up your own backend). Alternatively, you can go directly to a card processor (but you must then satisfy very stringent and expensive security requirements).
While TeddyPass is not a crowdfunding app, it is a recurring billing app and Stripe works well for it.
So why not, for every pledge, obtain a Stripe token with the project funding date as the one and only rebill date? If the project does not fund then you cancel the "subscription".
Again, we're not in the crowdfunding business but that's how I would do it if I were in your position.