Ask HN: How are lean startups easily accepting CC payments?
I'm not the biggest fan of PayPal (reading enough horror stories over the last decade tends to cool you on some companies), but if it's the best option out there I'll use it.
I'm curious what the other single-person startups or small team startups that don't have the expertise to do full integrations with authorize.net/Braintree/etc. are doing to collect recurring/subscription payments?
I am hoping I'm missing some amazingly simple "all in one" company out there where a user can just enter credit card details and be done. I'm avoiding Amazon Payments and Google Checkout because of the required "create an account" step that a few companies have blogged about mucking up their follow-through with new customers.
Any tips would be much appreciated.
Links for reference (for anyone else in this boat) Intuit's full solution: http://payments.intuit.com/products/online-credit-card-processing.jsp
PayPal's full solution: https://www.paypal.com/us/cgi-bin/webscr?cmd=_wp-pro-overview
BrainTree's full solution: http://www.braintreepaymentsolutions.com/services/recurring-billing
If anyone is using any of these successfully for subscription-based payments I'd love to hear about it. I spoke with someone at Recurly who (fairly?) pointed out that subscription management isn't the primary feature of any of these services, so some of the implementations are awkward; on that note I'm not ready (since I have little idea of how this business will do) to purchase more management layers like Recurly into my billing process until business picks up.
124 comments
[ 45.4 ms ] story [ 2832 ms ] threadbut if you just want to start taking customers' cash ASAP, you can do that with a paypal hosted button in about 5 minutes.
WPP lets you accept credit cards w/ paypal - no paypal acct necessary - and there's tons of sample code out there that's basically copy and pasteable, and lots of code monkeys are familiar with the intricacies of paypal integration.
Which bank did you use? My experience has been that if you're doing ANYTHING other than e-commerce, it's a long uphill struggle. I've tried Chase, B of A, and Wachovia.
I also read a great post on setting up payments the right way, on the cheap, but I can't find it now. Will post if I do.
One nice thing about PayPal is you can use them for Offline, Web and Mobile payments - there are pros and cons to consider, might want to contact a few companies and explain your needs.
check activemerchant if you use ruby.
It's vastly, vastly better than our experience with Amazon SimplePay/FPS
PayPal is _absurdly_ easy to set up and start collecting money.
You do though, need to understand that Papal's main business advantage over banks is their automated fraud prevention/detection - if you do anything that might come close to triggering their automated systems, you need to watch out. In my experience, that's almost always been accepting payments significantly before shipping something that can be tracked. Pre orders often get accounts locked. Non physically shipped products (thing "digital downloads" - software, music, or ebooks) often get accounts locked.
If you're not doing that kind of thing, or if you're doing it and are prepared to put up with Paypal holding on to your money until they believe your customers are happy, then PayPal is a reasonable solution (we have a client who starts accepting pre-orders for e new edition of his book every October, and PayPal hang on to _all_ money put into his PayPal account until 3 or 4 weeks after the books start shipping in early January. This has been going on for 4 years now, exactly the same every year, but the client is perfectly happy with that situation, he's mainly accepting pre-orders as a way to more accurately guage how many copies to print in the first run, he doesn't need to have the money up front but it's a great way for him to know really firm minimum order numbers for the first print run. It's only when he gets drunk over Xmas/new year and starts ringing PayPal up and screaming "give me my fucking money!" at anyone who answers the phone that it's a drama, unfortunately _that's_ been going on for 4 years now too...
Tl;dr, use PayPal to start with. Never leave more money in the PayPal account than you're prepared to lose. Never leave that money in a bank account linked to PayPal either. Make sure you've got a backup payment method at least planned, that you can switch in sufficiently quickly that you don't go broke between when PayPal cuts off your money and the new payment system is in place (that means get your merchant account and Internet merchant ID applications in process _now_, not after you have a PayPal problem.)
Anything else out there like that? That is, all the flexibility of being able to run charges programmatically, without the overhead of being PCI compliant?
I've coded with both Authorize.net's and First Data's APIs, and Stripe is much, much better in comparison.
can anyone get me an invite :-)
If you want to accept credit cards on your own site, you need to learn about PCIDSS compliance, you need to apply for a merchant account, and you need to a payment gateway that works with that merchant account.
It's well within reach of a lean startup. The application is usually a page or two long, you'll get approval from the underwriting bank within a week or so, and most MAPs also resell the payment gateway accounts so they set that up for you and you get everything at once. The fixed costs will be a statement fee and a gateway fee, $20-30 a month total.
It's terribly difficult to understand the fees you'll be paying with a merchant account. They're far more complex than whatever you get quoted will lead you to expect, and it's absolutely common for providers to change the fees on a monthly basis such that after a year you have no idea what you're paying. There can be dozens of classes of credit cards each with different rates when you charge them. My only advice for dealing with that is to try not to tie your code to your processor so that, when you grow enough for the fees to matter, you can shop around for a better deal.
You don't get to take shortcuts with the PCI stuff. The fine for a credit card being compromised from your server because you weren't PCIDSS compliant start at $500,000 per incident (paid to Visa/MC) plus legal fees and costs to provide credit monitoring to the victims.
If you accept credit cards directly on your site, you'll be required to fill out a self-assessment questionnaire and have a compliance scan against your server run on some basis. For most ecommerce setups, it'll be quarterly. What that costs depends on your merchant account provider; some contract with and pay a compliance company for you, others you have to pay some or all of the costs yourself, which can be a couple hundred dollars a year. SecurityMetrics seems to be the most popular service for the scans.
The technical part is easy. An Authorize.net integration will take you a couple hours at most. There are libraries for the popular payment gateways in every programming language known to man, and prebuilt shopping carts will have plugins/modules/whatever written by people already.
It's just like any other API. You POST some data to some server to make a charge/authorization/refund/etc and get a response to parse. If your app integrates with Twitter, you've already done much harder work than integrating a form with a payment gateway.
http://developer.authorize.net/api/sim/
http://www.e-xact.com/hosted-checkout/
Pretty nice if you want to do things like "we'll bill your credit card only when item ships", etc.
The reason is because, to do something like AIM or CIM, payment gateways need to store CVV numbers as well, resulting in a very expensive level of PCI compliance.
I'm not extremely well versed with fraud semantics, but IMHO placing an authorize on a card reduces the risk of fraud, refusing to pay, etc.
https://www.pcisecuritystandards.org/merchants/self_assessme...
Multiple calls to PayPal were useless. They told me that when I applied for adaptive payments, they reviewed my entire account and decided to require that I always include CVVs. In over a year, I had almost no chargebacks so fraud shouldn't be the reason.
The next day I applied for Authorize.net and was accepted the following day. It's about about the same price as when I was with PayPal, but with none of the hassle.
In summary, if you want credit card based recurring subscriptions, PayPal is just as expensive, significantly more restrictive, has terribly designed APIs, a sandbox environment that doesn't work as often as it does, and is kind of like smoking next to a barrel of gun powder.
“PayPal’s reporting is extremely limited.”
“Virtually impossible to use for serious businesses without extensive external code or a system to manage customer flow/cross/upsells.”
“You spend too much precious time on e-commerce tasks and way too little time on marketing and dev.” “For business-to-business products, clients do not take you seriously as a potential supplier if PayPal is your main payment method.”
“PayPal has very strict rules about the orders they are willing to let through, so merchants end up with fewer orders going through/lost revenue. They are quite picky about declining certain credit and debit cards other services would otherwise accept.”
“I log into my PayPal account and what do I see? “For my protection” they have limited the ability of my account to withdraw or send money but most severely, they also disallowed the account to receive payments! Frantically, I go to MacGraPhoto’s buy page, click buy and see a message “The seller can’t receive payments at this time”. At about the same time I get an email from a potential customer that says that he can’t buy the bundle. In the server log I see other people trying buy the bundle and leaving. Lost sales. Not good. Not good at all. My PayPal’s page lists lots of things that I need to provide to PayPal regarding my personal identity and regarding the sales. Some requests are totally not relevant to the case or to our business…And, it’s totally impossible to directly talk to the people who actually decide…I receive another email from PayPal. The subject was new: “PayPal appeal denied”…So, now the money (most of which is not even ours but of our bundle members) is held for 6 months. Sure, they are “making every effort to minimize any disruption to your business”. Sure, no disruption at all…Needless to say, I didn’t get any response not after 72 hours and not after a week. I called support again and was told that they won’t respond me because my appeal was denied and they don’t reopen cases…I won’t be using PayPal to sell anything from now. They have grown too big to be efficient and caring for their customers. Quick to make totally disruptive decisions and to dismiss legitimate businesses without really taking a look at what it is…They took the liberty to totally halt our business, to cause lots of lost sales and a major cash flow blow only because we got successful with one promotion, after being their customers for a long time. Right, they “regret any inconvenience this may cause”. They are “making every effort to minimize any disruption to your business”. If you’re selling anything and use PayPal as your only payment option, I urge you to reconsider. They can cut your oxygen supply right at peak of your success, of course “for your own protection”…we decided to leave PayPal as our e-commerce service at Apparent Software and moved to FastSpring.”
“No branding on PayPal order pages means fewer purchases! My order page needs to blend in with the rest of my site or too many people will bail on us”
“No fulfillment support”
“Revenue is lost because a decent number of customers are located in countries PayPal won’t accept payments within for whatever reason.”
“As much as I like rolling my own solutions, it’s too complicated to offer quantity discounts, coupon codes, and multiple currencies on top of the PayPal API alone.”
“Tax responsibilities are on the client, ugh.” (US and EU VAT)
“Huge problems with spam filters on PayPal — we automatically send out logins once an order is processed yet a higher percentage is not received than is received.”...
It is a bundled payment gateway+merchant. You don't have to get PCI compliant and you don't need a merchant account (no min transaction volumes, fight chargebacks for you etc).
The down side is they only offer hosted payment pages and not suitable for everything... You need a finite set of goods/services you want to sell (eg monthly plans). You can't automate the process if you're building an online store where your customers can upload items for sale (eg AppStore).
Payment processors refer to their business customers as "merchants".
Entrepreneurs ALSO refer to their payment processors as "merchants".
Some samples: "I'm going to come out and say it: FastSpring is awesome. I haven't experienced customer service this good in my life. Every query I've had, from stupid questions to difficult questions to bug reports has been dealt with brilliantly." - Daniel Kennett, kennetnet
“FastSpring is definitely the best company I have ever interacted with (note: the best company ever, not just related to e-commerce).” - Ruman Stankov, Triland Inc.
I believe that since they would handle everything transaction wise, you don't have to worry about being PCIDSS compliant.
You can always decide to put Chargify on top of that if you want. Bonus -- if you end up getting a merchant account with your existing bank you can swap that in later. (Though you probably will get a better rate w/ Braintree).
If Braintree had a micropayments option I would almost certainly have tried to go with them.
No need for a merchant account and they easily handle affiliate commissions (if that's something you want).
Downside is that people will see Clickbank.com on their credit card statement, not your merchant name (but that's the same with a basic PayPal account as well).
Upside is they have a very good track record at processing recurring payments successfully (much better than PayPal) and they don't freeze your account like PayPal or Google Checkout does.
About 10% of the people who click the "buy it" button on my product get to the Amazon sign-in/registration page and then bail. Abandoned funnels always sting, especially so close to completion, but is a 10% abandonment rate worse than it would be for a more direct credit card payment system? I doubt it, though I admit that I don't have any solid data to support that assertion. Might be worth trying.
I'm one of the founders of Chargify. Whether or not you choose to use us (our focus is the management of recurring billing, products, coupons, proration, etc.), here is an article I wrote to help startups and SMBs understand payment gateways and merchant accounts:
http://support.chargify.com/kb/merchant-accounts-payment-gat...
If you just need to accept credit card payments of any sort, this is the foundation you'll need. PayPal Website Payments Pro is their version of gateway + merchant account, but frankly, after seeing hundreds of merchants choose this or that solution, I recommend other gateway/merchant account combos.
I hope it's helpful info.
Thanks.
--- Lance
About Simplified Ecommerce: We specialize in subscriptions and our goal is to support a merchant throughout their entire lifecycle; finding product- market fit before they have a merchant account (similar to clickbank or fastspring), affiliate marketing to accelerate their growth, transitioning to their 1st merchant account and switching or adding merchant accounts as they scale.
Throughout their lifecycle, adding or switching a merchant account is as simple as submitting new merchant account credentials. All their custom hosted payment pages, integrations, pricing plans, affiliate relationships, reporting...remains intact. All customer data is stored in our independent level 1 PCI compliant gateway vault and is fully portable.
Our primary market is the non developer. Although Recurly, Spreedly/ Spreedlycore, Chargify and others have great, robust API's, we offer simple copy & paste "Buy Now link" type integrations. Merchants can customize hosted payment pages, switch merchant accounts, add subscription plans and set up affiliate programs in minutes, with just a few clicks. We also provide the consumer interface so subscribers can cancel, up or down grade their subscriptions without any additional integration or programming by the merchant.
I'd love to hear your feedback and happy to answer any questions. We are planning to expand our private beta in the next couple months, contact me if you're interested- Colin at SimplifiedEcommerce.com
Additionally, I've used their recurring payments product (extra $30/month tacked on to Website Payments Pro). Its also really easy. You just send the transaction ID from a previous payment instead of the CC data , and PayPal looks it up in their vault.
Only shitty part with PayPal is you have to offer payment via paypal.com as an option ("Express Checkout"), which means you get to code an extra checkout flow! But maybe you were going to offer PayPal as an option anyway, so that's moot.
Authorize.net is great too, especially if you already have a merchant account setup with your bank. Their API is also super easy, and supported out of the box by most shopping carts.
I've chosen not to use Recurly or Spreedly. Handling money is a bitch, I want a partner with deep domain knowledge who lives and breathes payments. Keep in mind if you store your billing data with one of these guys, and they close up shop - you're fucked. Do you want to depend that heavily on a business with no 800 number and < 10 staff?
At the end of the day though, you'll have to make the call yourself. You've got no reason to believe me, the blog posts you've read, or anyone else you don't know personally. This is your business, your life - you can't just punt this one to the crowd.
As I remember it, you also have to have a direct Paypal link on your cart page (if you have one) - that bypasses any checkout process you might have (though you can redirect them back for address etc after). A bit of a pain all told!
The fact that they give data portability is great and the "transparent redirect" is super convenient, knowing that i have practically nothing to worry about from the PCI DSS side of things. If I ever get to the point of needing it (which I may soon) it looks like they have the ability to manage multi-merchant accounts from the same system http://www.braintreepaymentsolutions.com/services/multi-merc...
Although I have heard great things about Stripe, really want to check that out soon. Also, after looking at the prices for Chargify or Recurly, it really doesn't seem to be that much of a value add for something that can be easily accomplished with the Braintree API.
I'd be inclined to pick something like that rather than use Paypal.