We are a small startup here in Northern NJ. We decided to do a deal site, even though its getting a little hairy now, this idea had some twists we thought would be nice.<p>After designing, conceptualizing, and building the frame, we had to pick a provider for payments. At first Authorize.net looked good but they did not offer a way to build in the tipping concept without us storing the CC#'s on our end (If you have looked at the paperwork involved you would know why this was a turn off to us).<p>Doing more research lead us to find PayPal, posts on forums pretty much outlined the concepts. Even though their documentation is all over the place (x.com,cms.paypal.com, dead links...) I pushed through it, I even wrote a PHP Class to simplify what we needed.<p>https://github.com/gtsafas/PayPal-NVP-API<p>So now it was built, I had tied everything that needed to be into paypal, week of testing in sandbox and everything seemed good to go. After talking to support they informed us we need to upgrade to Website Payments Pro when going to production, so we did.<p>Week 1, all is well payments / tipping pulled in a few sales.<p>Week 2, We had a great deal from a really popular place over here so we decide to run the capaign. After starting to get sales (quite a few) we get this lovely email from PayPal...<p>"After careful consideration of your application for PayPal’s Website
Payments Pro and/or Virtual Terminal product, we are unable to approve
your application at this time.<p>Many factors were taken in consideration including time in business and
past performance, type of merchandise and delivery risk, and inherent
risk for chargebacks and buyer complaints. Due to the heightened
visibility that accompanies a merchant account, Website Payments Pro and
Virtual Terminal is not available to you at this time."<p>We never were told it was an application, the words they used were "enable" and the payments were working fine, how were we supposed to know that they blindly let people use the services they haven't approved yet.<p>So now all purchases fail when the person tries to make them and as a result we now have cancelled the deal and temporarily closed down the site.<p>PayPal is not for entrepreneurs and I should of known better than picking them as a choice.<p>(There is much more I can complain about, but what is the point now? The damage to our revenue and client confidence is already done. )<p>Can someone recommend a Payment vendor that would satisfy my needs and not kick us in the nuts?
You're going to get variations on that <i>quite a bit</i> when looking for a merchant account, since what you are doing actually is very risky. This is not a Paypal issue so much as it is, shall we say, a divergence in perceptions of reality vis-a-vis how much payment processors care that your business requirements are their business requirements. Supporting pays-only-if-event-happens is your business requirement. It is very, very quirky for payment processors. They can do quirky things. They're expensive, require reams of paperwork, and you have to be able to convince them that you're good for it. Operating history of a week will not do this.
> PayPal is not for entrepreneurs and I should of known better than picking them as a choice.<p>I don't think PayPal can be blamed for being aware that there are already thousands of small time deal sites and most have no discernible business model whatsoever, not even a potential future buyer.<p>Frankly, you have no idea what the rate of chargebacks is. You've barely run the thing yet. I would expect the company that processes millions of transactions a day to know what puts them at risk for chargebacks. I also don't see daily deal sites having a high rate of chargebacks is such an outrageous idea. Sounds pretty reasonable to me, they are exactly the kind of customers who would file a chargeback.<p>I'm no fan of PayPal on the vendor side either, but this sounds like poor planning to me. Not factoring in a 2nd payment processor just in case you have trouble with the first one is a bad idea, especially when you are in such a risky, fast-growing sector.
Check out WidgetPay (<a href="https://widgetpay.me/" rel="nofollow">https://widgetpay.me/</a>), which is built on top of the Stripe API (<a href="https://stripe.com/" rel="nofollow">https://stripe.com/</a>), and run by my startup.<p>I've compared using it vs PayPal on my blog: <a href="http://denis.papathanasiou.org/?p=572" rel="nofollow">http://denis.papathanasiou.org/?p=572</a><p>If you're comfortable with coding, though, you should just go to Stripe directly.
Tip: you might wanna delete some of the info on the github readme file. I am not sure if it is real but you have CC acct numbers and passwords on there.
It sounds there was a miscommunication, PayPal is pretty explicit on their website that you need approval for Website Payments Pro (it's on their "Getting Started" page when you apply for an account).<p>When you were speaking to the rep they perhaps should have gone into more detail about the process involved, but it doesn't seem that they purposefully misled you.<p>Miscommunications happen in business, it's one of those things. Chalk it up to experience and next time your in the same situation you'll know to ask more question.<p>PayPal have their faults, but I don't think this one of them.
I know Authorize.Net was ruled out, but couldn't you just use the Authorize.net CIM to avoid storing credit card data? We've been using Authorize.Net and the CIM and it's been great - and they are professional.
Hi, saw that you are based in northern NJ. I have started a group on Meetup.com for startups in NJ and it would be great to have you in our group:<p><a href="http://www.meetup.com/njstartups" rel="nofollow">http://www.meetup.com/njstartups</a>
That sucks! We have TONS of daily deals site customers, it's not that hard... Here's a little primer:<p><a href="http://feefighters.com/blog/payments-for-group-buying-sites/" rel="nofollow">http://feefighters.com/blog/payments-for-group-buying-sites/</a>
Drop me a line if you need more help getting set up.