I use Stripe for Gumroad and it's amazing. Unfortunately, it's still private for now.
Anyone else think this thread reads like a stripe bot love-fest?
Ask HN: How are lean startups easily accepting CC payments?
91–100 of 125 posts
Re: Ask HN: How are lean startups easily accepting CC payments?
#92Earlier quoted context omitted.
Authorize.net's AIM gateway also allows the flexibility to authorize now and capture later - without the webapp needing to store the credit card info. Pretty nice if you want to do things like "we'll bill your credit card only when item ships", etc.
Everyone _should_ do that, as CCs generally take a dim view on charging before something actually ships.
Yes - which is why what webapps do is only authorize AND charge when something actually ships. Most payment gateways (including Authorize.net's other products like SIM) support this workflow.
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.
Re: Ask HN: How are lean startups easily accepting CC payments?
#93Earlier quoted context omitted.
I didn't mean to upvote you, I misclicked. I disagree with most of what patio11 said, and have found (like bryanh) that using ActiveMerchant with Auth.net was no harder than when I tried Spreedly. As such, I'd pass on patio11's advice and instead just get an authorize.net account, integrate that, and forget about it for the next five years.
Do the credit card numbers ever travel via your server? Even temporarily in memory? If so you are liable for PCI-DSS section C, which is a LOT of hoops to jump through. Spreedly saves you from that.
It took us a couple hours to be in compliance with section C. If memory serves, we dealt with a vendor who did a scan, made us install AV software on our Linux boxes, and one or two other minor process adjustments. It wasn't a big deal.
Given Spreedly's current prices of the lesser of $0.20/transaction or 2%/transaction, this minute quantity of work is currently providing us with a return of approximately $12,000/mo. (We had over 60,000 transactions in March.)
Cost: approximately 3 man-days.
Benefit: currently sitting at approximately 1 man-year/year and growing.
It's true that if we'd gone of business within 25,000 transactions, we would've been better off with Spreedly, but given the time, energy and money that we were committing to the business, optimizing for that case seemed absurd. As such we made a small bet that we'd succeed, and that bet is currently generating enough savings (as compared to using Spreedly) to cover an FTE. Some people might say it's a rounding error on the revenue (and I suppose that's true) but I view it as a small bet that is paying off at an enormous multiple.
Re: Ask HN: How are lean startups easily accepting CC payments?
#94[Breaking this into multiple comments, because it is too long. The subsequent parts will be replies to this] We've been accepting credit cards for about 10 years, but I've recently been looking into all of this because (1) I'm pretty sure we are getting reamed on fees by some of our current providers, and (2) we are starting a new line of business under a different brand name and want to set up credit card processing…
Use SaaSy and you don't have to think about any of this. Not so with any of the other recurring billing services though.
Re: Ask HN: How are lean startups easily accepting CC payments?
#95If you want something simple without writing much code, go with PayPal. You'd expect some "horror stories" from a payment processor with 232 million accounts. Virtually all of them involve someone doing something that'd raise flags at any merchant account provider or bank, it's just that people think PayPal isn't a bank so they should be able to get away with anything. 10,000 horror stories still leaves 99.99% of use…
I asked software vendors we work with who had previously used PayPal for their e-commerce to list any issues or limitations they experienced when using PayPal. The following outlines some of the issues that they experienced. No doubt there are countless happy PayPal clients out there as well, these are just issues some have run into that everyone should at least evaluate.
“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.”
“They have virtually no fraud screening.”
“(PayPal is) more difficult to set up – documentation spread all over the place, and forum answers sometimes misleading”
“There is no support for discount codes/vouchers (this really surprised me)”
“No experience with (PayPal) customer service yet- but I’ve heard bad things”
“Their system is very clunky, as far as looking up orders, pulling reports, checking a history etc…”
“PayPal heavily favors the purchaser not the vendor selling, as in chargebacks or disputes etc.”
“I don’t get notification of orders on a consistent basis, I have to login and check orders daily”
"We sell off multiple sites with the same PayPal account and the reporting to figure out which sites generated which sales is a nightmare”
“Lacks professionalism”
“Their UI stinks, it takes me a while to figure out how to do things in their system”
“I have heard too much about PayPal’s abuses to trust them. When I see something where the only payment option is PayPal, I select a different option: not buying.”
“No ability to offer upsells (at least that I can figure out)”
Re: Ask HN: How are lean startups easily accepting CC payments?
#96Horror stories you may have heard aside, I've setup PayPal's website payments pro for many clients, with tremendous success. Never had any trouble with them, and my PayPal rep has always been reachable by phone and very helpful. 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 in…
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.
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!
Re: Ask HN: How are lean startups easily accepting CC payments?
#97I use Stripe for Gumroad and it's amazing. Unfortunately, it's still private for now.
Anyone can send me a invite?
Re: Ask HN: How are lean startups easily accepting CC payments?
#98My 3 year old site depends on recurring billing so this is something I've researched pretty well. If you have many non-US customers, as I do, the short story is that PayPal is really your only option. All alternatives depend on credit cards, which are not nearly as common outside the US.
I am aware of the horror stories around PayPal but I haven't had any serious problems in the last few years and I do hundreds of (recurring) transactions per day with them.
That said there is a pretty long list of annoying bugs in PayPal's recurring billing solution and most of the bugs have been in there for years. The technical bugs you can work around, but the "usability" bugs are quite annoying:
* If a user changes his credit card it will cancel all his subscriptions, unless he follows a specific set of steps that he won't find out about until it's too late
* If a user want to change a subscription and uses a different account to log into PayPal than the one he signed up with he gets the unhelpful error message that his "subscription has expired"
* If a user has two or more subscriptions and tries to change one PayPal will present him with a list of which one to change. This is a list of cryptic numbers. If he picks the wrong one it is near impossible to correct without canceling and resubscribing
* There is no way to pro-rate a subscription: if someone makes an annual payment for bronze tier and a day later decides to switch to silver tier PayPal will not charge the new price until a year from now.
I could go one. There are also internationalizations issues but I guess those only apply when you are outside the US like I am. (E.g. If you are outside the US then all the amounts in messages to your customers get formatted with a comma as a decimal separator, even if your customers are in US and you have your language set to US English). I've filed a bunch of bug reports over the years but I've never gotten a bug actually fixed.
Re: Ask HN: How are lean startups easily accepting CC payments?
#99My opinion on this: it is very difficult for me to add value via coding the world's best possible rebilling user experience and backend admin code. It is orders of magnitude easier for me to add value via either marketing (which I need to do more of) or adding features to the product that get it in the hands of more customers. This strongly suggests that I should not be writing billing code, ever. You need a bunch of…
I do believe a blog post about how to practically implement such things into a framework (say Rails or Django) would do well.
I don't know about the GP's project, but I implemented my own for historious by using PayPal's recurring payments feature. I store the user's subscription expiration date in their profile, and when the PayPal rebilling notification comes, the date is just reset by X days, which is stored in the PayPal "extra data" field (signed, of course).
Doing the charges yourself is exactly the same, except you have a nightly cronjob to find the accounts that expire today and rebill them. I don't think there's enough material in this to warrant a post.
Re: Ask HN: How are lean startups easily accepting CC payments?
#100My opinion on this: it is very difficult for me to add value via coding the world's best possible rebilling user experience and backend admin code. It is orders of magnitude easier for me to add value via either marketing (which I need to do more of) or adding features to the product that get it in the hands of more customers. This strongly suggests that I should not be writing billing code, ever. You need a bunch of…
It doesn't take much to improve the billing experience over sending someone to an external website, to pay with payment pages that are minimally customizable to match your site. You lose the ability to tweak and test one of the most important parts of the customer acquisition experience. There's a >10% conversion rate gap between different checkout flows I've tested on one of my ecommerce sites. I've written my own s…
dan, because you are holding the CC information on your site and POST'ing it out to external services at authorize.net, did you have to do any work for the "PCI" compliant/privacy stuff I see?
I read a few posts on forums that if the customer financial data is ever on a page you wrote, you come under the realm of at least some PCI compliance because of a possible XSS attack getting that information out of your forms.
That made the hosted "checkout" pages seem a lot more attractive to me... curious how you handled this.