Hacker News new | comments | show | ask | jobs | submit login
Stripe And A/B Testing Made Me A Small Fortune (kalzumeus.com)
409 points by craigkerstiens on Aug 6, 2012 | hide | past | web | favorite | 154 comments



At ConversionVoodoo we've found that the gains pulled out of cart-work are staggering vs. other areas in your funnel - 50%+ improvements to be had even on high volume / "well optimized" projects (10k+ sales/mo).

Three easy places to start:

a) Simplify the UI - Make it as simple as possible for people to enter their payment details - large fonts, cross-browser tested, minimal pages, optimized for the lowest screen resolution of your average user on up.

b) Reiterate TRUST messaging - testimonials or buying popular symbols (Verign /McAfee / etc) and even dialing in the PLACEMENT of those logos is high-value eg http://www.conversionvoodoo.com/blog/2010/07/proper-placemen...

e) Implement a Cart Abandon strategy - either sending "instant discounts" via email good for 24hrs to complete order, calling dropped carts, or hitting a pop-up of live help or similar is easy money.

Add to this all the usual - proper messaging on buttons, lightning fast response times, mobile optimized version too, etc and you instantly gain a massive advantage over your competitors.


We have got numerous case studies on the checkout page http://visualwebsiteoptimizer.com/case-studies.php

Some of the common tactics that have worked for our customers:

- Providing a summary of what they have ordered and making sure there are no hidden surprises (extra taxes or shipping charges)

- Adding trust indicators like Verisign seal (yes, they really work!)

- Not requiring them to create an account just to checkout

- Adding phone number and physical address that customers can reach out in case they need help

- Good looking design (people subconsciously associate good design with higher trust. If you have an odd color, or a grammatical mistake, or a dangling element, it tells how careless you are at designing the most critical page, so you would be careless with their money as well)


Wow, I am not a target customer for modern e-commerce. I would never return to a store that had behaviors like this:

> e) Implement a Cart Abandon strategy - either sending "instant discounts" via email good for 24hrs to complete order,

Training users to haggle at checkout and not trust the list prices

> calling dropped carts.

harassing people offline after they leave your store?

> or hitting a pop-up of live help

Does anyone believe in live help? All I ever see it do it block content I am trying to read, providing the equivalent of menu-driven CLI (the scripts agents follow) when I already have a powerful GUI in front of me.


patio11 and other wise people have said this much better than me, but here goes: you are not like most people. You are likely to be a hacker, engineer or at least a computer power user. Most people are not. These techniques will work and print money with these other people which are not like you, and they are the majority.


patio11 and other wise people have said this much better than me, but here goes: you are not like most people.

After realizing this, one must then get over the idea that accepting money from such people is unethical.


Why is it unethical?

Many people are nervous - even scared - when purchasing online, because of the numerous stories of "having stuff hacked".

Live help lets them know there's a human being at the end of the line.

Abandoned carts are often a manifestation of that fear - so again, contacting them afterwards lets them know that there's a real person there.

And many people like the idea of something but when it comes to the actual commitment get cold feet - discounts can help in that case.


I didn't say it is unethical, just implied that it's possible to have the idea that it's unethical. Maybe accepting money from less technologically capable people feels like unfair manipulation to some. Maybe the idea was planted as unwitting sabotage by intimidated, less technologically capable people trying to counteract a feeling of inferiority.


Live help drives conversions on our ecommerce site. Our customers ask questions more often than I would expect.

Cart abandonment coupons haven't worked for us at all. My thinking is that our 10% discount isn't steep enough but I have no data. Since I don't have any insight in to what people do after they abandon the cart I'm not sure throwing discounts at them is an effective strategy.

Calling dropped carts? That's not something we have the bandwidth to do.


Through a lot of experimentation. I've found out that you need to offer at least 40% to get any significant conversion of the cart dropouts. At least for the shareware desktop software I sell.


> Training users to haggle at checkout and not trust the list prices

Definitely, this is quite a risky one. Just speaking for myself if I notice a Cart Abandon strategy, I will always abandon my cart in the future to keep getting the dicsount.


Firstly, the merchant still gets the sale and is happy (it's like boasting about getting 20% off at Bed Bath and Beyond). All the merchant has to do is skip an email here and there (if they want). This is to say: you have not found a loophole; you are not a concern to the merchant; no one should be frightened by this tactic because of your story.


> Firstly, the merchant still gets the sale and is happy (it's like boasting about getting 20% off at Bed Bath and Beyond).

True, but they would have gotten more money had they held their ground. I was still going to buy the item, sometimes I abandon the cart accidentally because I got distracted.

However if you shove a discount in my face assuming I'm about to walk, I'm going to use it even if I was just about to pay full price without hesitation.

> This is to say: you have not found a loophole; you are not a concern to the merchant; no one should be frightened by this tactic because of your story.

Assuming the 15%-20% is all extra markup, this is true. Also it's not "my story" for the record. Sites like retailmenot index cart abandon strategies. Way more people are going to use that discount than just those you intend. If that's an acceptable loss, then great.

It's still not necessarily a great idea depending on your business.


>It's still not necessarily a great idea depending on your business.

But that's the whole point of A/B testing, rather than argue of hours based on intuition and anecdote you can actually test these ideas. No need for debate here, just run experiment and look at the results.


It's not so easy to run correct A/B test in that case. At a minimum you should measure long-term impact of emailing discount to users who abandoned shopping card. That means at least couple of months testing.

Note that debate is still needed in order to properly setup A/B test.


While I agree with what your saying in regards to not reasoning about the larger situation. Initial A/B testing should just be to get a sense of the magnitude of increase (if any) in conversion rates when you do the discount.

Only then can you reasonably discuss the issues presented. If your results say 'this is definitely a good idea for increasing purchases', then rather than do long term A/B tests it would be better to just monitor overall trends in potential abuse.

So there are really two separate issues: Do discount follow ups to abandoned carts create a large increase in purchases. This is easily answered with an A/B test

Are people likely to abuse this discount system? And how do we stop it if they do? This is hard to test with a simple A/B test and is much better answered just by monitoring the purchases and looking at the extreme cases. Also this is pretty easily solved by just adding limits to when the system grants discounts.


> True, but they would have gotten more money had they held their ground. I was still going to buy the item, sometimes I abandon the cart accidentally because I got distracted.

This is one of the very things they are trying to fight.


It's a numbers game, and the money form extra sales might very well make up for a few sneaky users abusing it.


Just a bit of anecdata: I believe in Live Help. (And Harvey Dent, but that's not important right now.)

I can think of at least two occasions where having a Live Help function available on a site made the difference between me buying something and not buying it. One of those things (a sit-stand desk) was quite expensive.


> This means that their credit card details never hit your server.

One thing I've been seeing recently is that some implementations using Stripe DO have the CC details hitting their server. The most common case being when Javascript is disabled the form posts to the website because the developer didn't design with graceful degradation, a dangerous mistake when mixed with credit card numbers.

It doesn't appear to be a problem for you (your payment page for CC info doesn't gracefully degrade with JS disabled and is impassible - you might want to fix that!) but I've seen it on other sites, and it's especially a problem when other sites don't use SSL as a fail safe for this sort of case which I have also seen. For Stripe it might perhaps be worth considering denying all payments from non HTTPS pages for this reason. It forces the merchants to have an SSL failsafe.

Also with CC info being entered on your site, it's presumably trivial for the site itself to record the CC numbers. Trust is the issue here, I'm not going to be entering my CC number on a site I've never heard of, with no reputation. Stripe doesn't solve this issue, Paypal does. Stripe looks wonderful, but it's not going to be suitable for everyone.


> One thing I've been seeing recently is that some implementations using Stripe DO have the CC details hitting their server. The most common case being when Javascript is disabled the form posts to the website because the developer didn't design with graceful degradation, a dangerous mistake when mixed with credit card numbers.

Only if you do it wrong. From the Stripe docs: "The only thing to note is how input fields representing sensitive card data (number, CVC, expiration month and year) do not have a 'name' attribute. This prevents them from hitting your server when the form is submitted."

> It doesn't appear to be a problem for you (your payment page for CC info doesn't gracefully degrade with JS disabled and is impassible - you might want to fix that!) but I've seen it on other sites, and it's especially a problem when other sites don't use SSL as a fail safe for this sort of case which I have also seen.

Again, SSL is covered by the docs. Stripe says you need it. Not that you should consider it, or that it's a bonus, but that you need it. https://stripe.com/help/ssl


Can't they deny all requests from non HTTPS pages then?


No, I think there is no way to detect if the HTTP-request to the server which makes the API call is made via HTTPS or not. Except if their libraries detect that on your side and block the API call there, but of course that can be easily circumvented. They can only enforce that HTTPS requests are made to their API.


Detecting it on your side and blocking the call there would still be really useful. Most people who use HTTP instead of HTTPS probably do so by accident or out of ignorance, and detecting that during development and telling them to fix it would be useful.


Yeah you are right here that it is still possible for our users to mess things up. We do things to try to keep merchants from accidentally sending card numbers to their server (e.g. the default example form makes this hard to do, and most people simply copy and paste this form). It's an explicit decision we've made, though, to leave control in our users' hands as many people seem to like the flexibility to have their checkout experience stay on their site and be designed by them. But we think about where to draw the lines here a decent amount.


I worked on something with credit card processing a few years ago. As I remember, it doesn't really matter if the details hit your server, but the point is you absolutely can not save them.

No putting them in a DB, no putting the in a log file (not even the last four or something like that), nothing. So if your form takes the numbers in, you make an API call, and then you blank them in memory you were OK.

If you put them in the user's session, you were in trouble.

It's all insanely complicated, and the only good solution is "don't do it." There's a good reason people use things like Stripe, PayPal, Authorize.net's CIM (where they store it and certify that they are PCI compliant).


To make sure there isn't confusion here, having card details go through your server, even if you aren't saving them, still can lead to certain PCI compliance burdens (e.g. you may need to get an audit from a PCI auditor verifying this).

Having the card never go to your server is the best way to make sure you are PCI compliant, as you mention.


One component is the transit security -is the data safe from interception in transit (on the network). The other component it security of the data at rest - is the data safe from interception if it comes to rest on your server (sessions, databases, etc.).

From data security standpoint is is easier to let somebody else do it, but end users tend to have a less satisfying checkout experience.


Ah, thanks. Like I said, I wasn't sure. We made sure we were PCI compliant, but I wasn't in charge of that by any means.


This is wrong. You still need to be PCI compliant even if you don't persist the CC data. There are a few bullet points you don't need to worry about in that case, but the vast majority still apply if the system has anything to do with credit cards (such as the details hitting your server).


Please read stripe's TOS - your application is REQUIRED to be PCI compliant.


I think I know why I got this wrong. There are multiple levels of PCI compliance, right? I think we used services that allowed us to not have to be compliant with data at rest (since we didn't store it), but only the data in transit (or whatever the equivalent term is).

This is by no means my area of expertise (as I have accidentally proven).


Absolutely, there are different levels. However, for all levels you have to do some work to achieve PCI compliance (and overall security of your system). There is no magic in this world :)


True, and the thing about PCI is that many apps probably could benefit from being forced to do this type of work.


It's worth noting that we're talking about "degrees" of PCI compliance vs "I'm on the hook or I'm not on the hook" Implementing Stripe so that the data never touches your servers still requires you to complete a SAQ-A. That's just a LOT easier than if you are handling the data and have to complete a different SAQ.


there is no magic in this world (even if stripe's marketing team wants you to believe that there is)


God I hate posts about Stripe with a passion. It's like saying "You've had this pain in your back for the last five years? Well, I've got this miracle pill here that will not only make it go away, but it will also taste great. Oh, you're not in the US? Too bad then."

Stop reminding me I can't use Stripe all the time.


Stripe is beta testing internationally. I got an account in Canada about 2 weeks ago.

http://www.businessinsider.com/stripe-square-international-e...


Great to hear, I'm just praying they remove the need for a social security number in the US.

One of the main reasons we chose the US to incorporate in was for access to business tools like this. But with neither founder having a SS number we can't use the service.


If you're signing up as a business, can't you provide an EIN instead of a SSN? I see the box for it in their account settings page, but since I'm using it as an individual, I haven't been able to test whether that works without an SSN.



I don't want to speak in Stripe's name but I suggest emailing Stripe and asking for an account based on EIN.


SSN shouldn't be published around since it is a key information to ones digital identity. I guess they do this for clients which are not companies.


The SSN requirement confuses me, especially as a US citizen with a US company. Whose SSN is the right one to use? Are they legally liable for events? Why require a single person's SSN when in reality it's the corporation's account, goes to the corporation's bank account, which the corporation gets charged corporation taxes.


Fantastic, how do I go about applying, do you know?



Done, thank you.


This is major. So big, I almost have tears running down my face.


That's lovely, and I wish them luck, but having some sort of closed beta is about a million miles away from having a service I can check out to make sure that it works. And by works, I don't just mean payment mechanics and security, I also mean PCI/DSS compliance, EU data protection compliance, VAT handling, financial reporting, and all those other little details that are often completely different here from the US.

So as StavrosK said, can we please lay off the Stripe hype for a while? It's not a viable service for use outside the US, and it's not going to be (at least for any responsible business that isn't willing to bet the company on not getting into tax/regulatory trouble) for a long time.


I don't understand why we should avoid talking about services that produce significant, easily measured uplifts for US companies just because those services aren't available in Europe.

I absolutely understand the frustration being expressed and am not suggesting that these threads are the wrong place to express it. But the idea that we should "lay off the Stripe hype" sounds wrong. It's entirely possible that we're not hyping Stripe enough. Startups need all the help they can get.


To clarify, I don't agree with Silhouette that we should "lay off the hype". If anything, Stripe deserves it. I just hate it because it always reminds me that I can't even try it out.


Apparently I misunderstood what you meant earlier. Apologies if I misrepresented your view.


Oh, that's quite all right, I was just clarifying.


I don't understand why we should avoid talking about services that produce significant, easily measured uplifts for US companies just because those services aren't available in Europe.

Because at this point, it isn't newsworthy, it's really just noise/advertising. It's not as if anyone reading HN who can use Stripe hasn't heard about them many times already. If they launch an actual service that anyone outside the US can sign up for, then great, let's shout from the rooftops. If there is something constructive that the rest of us can do to help them achieve that goal, by all means, let's talk about it. Otherwise, with due respect to Patrick, there isn't really very much new and interesting to discuss in this area and I would prefer that HN concentrate on things that are new and/or interesting (such as the other parts of Patrick's post).

Startups need all the help they can get.

Yes, we do. And if and when a service like Stripe starts to offer it, I'll be all for having the news on HN. But until then, yet another group hug about how wonderful Stripe is followed by yet another round of moaning that it's not available anywhere outside the US and yet another apologetic post from one of the developers saying they're working on it is a bit like reading about every new Firefox release on Slashdot.


"It's not as if anyone reading HN who can use Stripe hasn't heard about them many times already"

I'd heard of them, but I didn't know that their co-founder would run git bisect if you reported a bug. Plus, 350 up votes on this story suggest that it was worth posting on Hacker News.


Sounds like an opportunity to me.


I don't know why this is getting down voted. Stripe is close to my most hated company right now because they're not available in the UK :) It's really annoying.


"Hated", really?


I think he's being ironic. They're "hated" because they're so awesome, yet so very unavailable.


Stripe the service is fantastic. I just hope they can get the financial side together soon. They sent me a 1099 on April 14 this year (you know, one day before taxes are due). Fortunately I hadn't filed yet (I was literally typing everything in TurboTax as the postman came). Not only was that usually illegal (at least for traditional 1099's; I don't know if the same rules apply to 1099-K's...haven't looked), it was highly annoying as it was also the second one they sent me (each with a different amount). Turns out they'd switched payment processors or something at one point and didn't bother to tell their customers to expect two 1099's.

Still using it. Great product. But I had to file an extension and crap to get it all sorted out, which was highly annoying.


Yeah, we just messed this up. I'm very sorry. I'm literally walking to a meeting with a user, but I'll follow up and edit this comment with details and what we're doing to prevent it within the next three hours.

[Update:] So, the background here is that 1099 reporting rules changed last year. A lot of companies—including some of our partners—didn't yet have their infrastructure in place to properly handle them. A lot has been written about the change in the law (search "2011 1099 confusion" for a small sample), and there's been a fair amount of ambiguity and confusion overall (Citibank issued 1099s for frequent flyer miles; whether this was necessary isn't yet clear). Due to this confusion, the IRS actually backed off plans to require the reconciliation of Form 1099K in tax returns filed for 2011.

In Stripe's case, one of our banking partners responsible for the filings was unable to meet the original filing date for all 1099s. While they filed a proper extension with the IRS, this meant that receipt of your 1099 was delayed.

As you point out, we should have done a much better job communicating this at each step -- and, obviously, receiving tax forms in mid-April is not an acceptable outcome regardless. We are working on controlling the process much more closely ourselves next year so that this does not happen again.

But the bottom line is: sorry. We built Stripe to make this kind of hassle go away, and we're doing everything we can to make sure that this was a one-off blip.


Do payment processors even have to send you 1099?

If I'm not mistaken, Google Checkout and PayPal did not send me 1099 - I just had to report all the revenue received from them myself.


This is a good question and I would really like to see it answered.


They have to send you a 1099-K like all other payment processors... if you made over $20,000 in gross sales in the year. I got one from PayPal in 2011.

https://cms.paypal.com/us/cgi-bin/marketingweb?cmd=_render-c...


I see, but I thought corporate tax was based off profit, not revenue?


How would PayPal know what your profit is? 1099s are informational forms. They inform you and the IRS how much someone else paid you. They are not directly used in computing your taxes. The purpose of the new 1099-K is to prevent you from receiving $x in credit card sales, then claiming you only had ($x / 2) in gross sales on your tax return.


Ah I see. Thanks!


I work in the same co-working facility as an education-based startup that switched from using PayPal(where user gets redirected to PayPal) to Stripe (completely branded checkout) and their conversion rates increased 40% overnight and have stayed at those levels. After digging into their API, we're actually building our new company, MoonClerk, on top of Stripe's API. We'll basically be an abstraction layer on top of Stripe so that non-developers can use it and implement it on their site, with a focus on recurring payments (even though we do one-time payments). We really want to allow non-developers the ability to use Stripe.


How is this possible? Through Paypal customers can also pay with credit cards, and even more. They can use checks, or bank transfers (very important in Europe where credit cards are not as popular), etc. Why would usage of Paypal decrease conversion compared to pure credit cards?

My guess is that a lot of customers don't know what Paypal is and don't realize they can just use their credit card.


And the PayPal flow is godawful - direct to a new page, get prompted to: 1. Log in. 2. Create Account. 3. Enter payment deets. (Small text near bottom of page, not always available, depending on the merchant).

Even if you have an account, they don't consistently keep my default payment method - often switching back to my bank account even when I've made a CC my default.

This all adds up to a level of friction that I hate, hate, hate, hate as a user. I can understand people abandoning a purchase at that point.


In my experience with a nonprofit, on whose board I serve, this is exactly the case with PayPal. Even if you're very upfront before you send people to PayPal that yes, they can pay with a credit card, once they arrive at PayPal they get confused. I've even had PayPal show me a popup ad for a PayPal branded Mastercard when I was trying to checkout somewhere. Their UI isn't "branded" like the site that the customer was just on so that's confusing in and of itself. In addition, paying with credit card on a PayPal checkout page isn't the main action - you have to search for it. Combine all of those elements and you get a much lower conversion rate.


Why build it on top of Stripe's API and lock you into a single (relatively expensive) vendor? You could build on top of something like SpreedlyCore and simultaneously support Stripe, PayPal Pro, and 30+ different payment gateways for hundreds of merchant account providers.


Stripe.js is a very well-implemented “or something”, where JavaScript that they’ll provide for you hooks into your credit card form with trivial work. (About ~6 lines for me.)

If, like me, you don't like the idea of loading someone else's javascript into your own domain, the "web page" side of things can also be done by dropping a single <iframe> tag into your HTML.


In case anyone is curious, here's Patrick's sales graph: http://www.bingocardcreator.com/stats/sales-by-month

You can see the big jump in May-July (although the jump for July is 32%, not 53%)


Oopsie. Thanks for the correction.


Patrick, just noticed your Adwords spend went from $1000's to $0 suddenly. Looks like a disaster. What happened? Is Adwords no longer viable?


I got married. Lots of balls to juggle. "Send credit card statements to VA for entry into the bookkeeping software which automatically populates a few stats on the BCC website" wasn't very high on the list. My actual spend is probably as high as ever, but "Log into AdWords to check" also hasn't been high on the list.


VA?


Virtual assistant. Cheap off-shore outsourcing via the internet, a staple of lean startup.


...I am not easily emotionally moved by git command lines...

This is going on my "best of" list of HN-related excerpts


My feelings exactly. That line literally made me feel warm inside for a second.

I am not easily emotionally moved by git command lines, but this is clearly somebody who understands me and what I need in life


"(A customer had — I kid you not — a lightning strike hit her computer during checkout, and as a consequence the JS callback fired 36 times. This resulted in 36 transactions, which Stripe processed without complaint. Oops."

I can't believe the good old 'computer was hit by a lightning bolt' wasn't in one of your test cases, Patrick! I mean it's so obvious :P

More seriously, that is one of the wildest reasons for a bug I think I've ever heard.


@patio11 Thanks a lot for mentioning me in your blog again. I was wondering why there was a spike in my visitor log.

I would love to do a redesign for Appointment Reminder if you're interested :)


Patrick, I'm curious how you have been using Stripe as you are in Japan and it seems they only recently began expanding out of America. Is the business entity behind BCC registered in the US?


I signed up with my US address and banking information. "By registering for a Stripe Service Account, you are confirming to be either a legal resident of the United States, a United States citizen or a business entity authorized to conduct business by the state in which it operates." (Though I finally got a DBA from Illinois, um, yesterday. Not related to Stripe -- a hospital wasn't thrilled with the notion of writing a particular flavor of check to a natural person.)


Could you elaborate more on this? What's a US address, and how did you get a bank account?


So let me answer the question behind the question first, which I take to be "I don't live in the US, but would like a US bank account":

http://www.kalzumeus.com/2007/08/15/banking-for-the-uisv/

Now to answer the question you asked: I have lived in Japan for my entire adult life, but prior to that I grew up in the United States. I routinely use my former address, which my parents still live at, for business purposes. Even if it weren't trivial for me to open accounts online, I would still have accounts in good standing from e.g. my college student days, which are sufficient to bootstrap me into a customer relationship at any US bank.


have to admit, that one of the reasons patio11 got Patrick (cofounder of Stripe) to help with customer support is because he's *the patio11

but great customer service is still great, no matter what.


Patrick is in the support rotation like most of us at Stripe. He'll answer your email too if you send it on the right day.


I would be very interested in how do you do ticket handoffs/tracking across multiple non-dedicated support people in your rotation.


thanks for the clarification


How do you know this for a fact?


(More anecdotal evidence) Patrick Collison also helped me out when I was implementing Stripe on my site, and I am just a regular joe.


I currently use FastSpring to handle purchases of my software. What's the advantage to using Stripe instead of FastSpring?


Dan, FastSpring’s CEO, here. That’s a good question. With FastSpring, you don’t lose track of your site visitors because we support cross-domain tracking. When a purchase doesn’t complete, you can see the order issues and resolve them as appropriate. You can experiment with various designs and flows because FastSpring order pages are highly flexible and customizable in terms of how the order flow can look, placement of various elements on the order page, etc. and A/B testing is supported. FastSpring all-inclusive, turnkey functionality is mainly UI based. Little coding is needed, it’s all there – functionality you need to launch and functionality you need to grow and maximize the business and its revenue. FastSpring pricing of its all-inclusive service includes the higher processing costs inherent in international transactions, Amex transactions, and certain alternative payment methods.

Here are some advantages to FastSpring: FastSpring works with developers and companies located anywhere US companies are authorized to do business, handles global tax compliance and tax payment management including for VAT, enables end users to pay using their localized currency to avoid bank/exchange fees and a poor US/USD-centric user experience, provides an order page localized in 20+ languages, has PayPal integrated, lets you skip the PCI Assessment Questionnaire, offers fraud prevention, a built-in shopping cart, Google Analytics and marketing ad campaign tracking integration, an unlimited number of easy to setup post-order notifications, designs an order page to match the look and feel of the other pages of the developer’s website, offers merchandising features for cross and upselling to maximize the average order size and optimizer order conversion, built-in notifications, a future bill testing GUI, pre-bill notifications for annual subscriptions, reseller and affiliate management, user role mgmt. & change tracking, consulting for SEO/PPC/Affiliate marketing/Online marketing/order page optimization, one-time purchases in addition to recurring billing, among other advantages. Hope that's helpful with your comparison.


Stripe allows you to charge customer on your site instead of redirecting her to other domain to fill out the purchase form. So, you lose track of your website visitor in a very important moment. If purchase never occurs, you have no idea why. On the other hand, with Stripe you have full control of complete purchasing experience, can experiment with various designs and flows - and measure everything. That enables huge gains with rigorous A/B testing, as Patrick explained.


Depending on your volume a lot of cash.

Fast Spring is 5.9% plus $.95 or 8.9% flat per order.

Stripe 2.9% + 30 cents.


Chase Paymentech - ~1.9% + $0.15 <---- WINNER!


Stripe would end up costing an additional $20,000 a year or thereabouts for us.

Due to their instant sign-up and almost instant approval however, they were the only option for a quickfix while we await chase or braintree to approve our applications. :)

Love their UI & easy integration though.


Just curious: are there any good options outside the US?


At Spreedly Core we see a lot of European and Asia Pacific customers sign up due to our API and flexibility to change gateways. However, no one outside of Stripe (and so far Stripe is the only one in the US) who has nailed the instant sign up piece.


2checkout is an option for payments outside the US. They are a bit pricey, but they're one of the few international payment processors around, and have very good customer support, both for buyers and sellers.

[I used to work for 2co. I don't any more.]


In Australia, Pin (https://pin.net.au) is very similar service: no merchant account required, nice API.


Basically, no. (I'm in the UK and am poised to jump to Stripe as soon as it becomes available).


There is the option of GoCardless (https://gocardless.com/) in the UK, however they use the Direct Debit system rather than card processing which does somewhat limit you geographically.


Aren't they really the "Anti-Stripe" more akin to Dwolla? Banish Credit Cards altogether? Also, I heard there were changes in European direct deposit/ACH laws (the approach Gocardless takes) that will allow them to be European, not just UK, very soon.


> "All three of these tests were null results. (i.e. No significant difference in aggregate purchases between either of the two options" (for goog&payp vs stripe, and several other combos)

This is a very interesting result. I would have thought that additional payment options would boost sales on the margin i.e. increase conversion by a couple of percent (not percentage points ;) for e.g. international customers, or people who already have accounts with GG/PP.

Patrick: Any chance you could elaborate a little more here? Would be very interesting to see some more detailed stats on this aspect.


Thanks for asking. So it turns out that two of them weren't null results, they were results against the change significant at 90% confidence. (Important difference for A/B testing practitioners, of only mild interest in context of the post.) I updated the post with the correction.

If you really like stats, well, here you go: http://www.bingocardcreator.com/abingo/results Rollover any conversion rate for raw stats.

"Offer Credit Cards As Sole Checkout Option" tested Stripe vs. the three checkout methods.

"Purchasing Page To Send People To"'s "Classic" is http://www.bingocardcreator.com/purchasing.htm, "Cc Checkout" was the hacky Boostrap CC form. (Not currently available online.)

"Offer Credit Cards As Checkout Option" was GC/PP/Stripe vs. GC/PP.


I can't wait to sign up for Stripe, as soon as they accept currencies besides the USD!

My bank account is in the states, but I need to be able to charge Europeans in euros, Brazilians in reais, Japanese in yen, etc...


"Suffice it to say there is a) a customer group which needs between 8 and 15 cards and b) they really, really like pretty checkouts."

I think this is more "people who are on the margin where they MIGHT be interested in paying for more cards can be convinced when they hit the pretty checkout page". If you don't need more than 15 cards, you probably don't have a burning need for the paid version.


"Is Stripe available outside of the US?"

"Currently Stripe is US only..."


that's nice but you arn't US based because you live in japan so how did stripe let you in?


could it just be his audience, I'm incredibly against adding my credit card on any site.


You are different from most of users buying on Internet. Most prefer entering credit card directly.


i find that really hard to believe in this day and age of cyber criminal and so much activity in terms of stolen identities.


Credit card fraud doesn't really affect the end user, except in time lost disputing fraudulent charged. Mostly the cost of fraud is born by the retailer who receives no money even though they have already shipped the goods.

That said, in 13 years of credit card use, I have been defrauded 0 times.


its still a huge pain in the a$$ , cancelling credit cards, changing any account associated with credit card, waiting for new one in mail, etc. Just the avoiding the potential headaches, is enough reason for me not to enter my credit card in sites. I really can't believe the sentiment of the avg user is that much different from mine


Try to run your own web sites that has these options.

On my web site PostJobFree.com there are 3 payment options: Direct (backed by Stripe), PayPal, and Google Checkout. Stripe covers ~85% of new transactions. Paypal ~10%. Google Checkout ~5%.


Or spend a few hours, get a merchant account through a bank and authorize.net with much lower fees and a pretty standard API. Tons of classes to use authorize.net with and super simple... no point of adding ANOTHER layer... charging with a merchant account is trivial.


That's certainly not been my experience with setting up online billing through authorize.net (or braintree for that matter). Integration is easy enough, it's the screwing around with getting a merchant account that's a pita.

Plus, if you're a startup, you don't really know how much you're going to be selling (or not selling). It's a good idea to keep associated costs variable until you have some better benchmarks.

Stripe is unquestionably the fastest, easiest way to be able to accept credit card payments online without making yourself look like an amateur by having google checkout or the like. Not having to go through the process of getting a merchant account--and the way their fees are structured--has been a huge time and sanity saver for me, both for myself and for projects I've worked on.


This is how it goes... you call Chase Paymentech and sign an app and 24 hours later you have an account. WOW, tough!


The light gray color of your comments should give you a hint as to how welcome they are in this community.


This community can't handle the truth. Instead it idolizes dumbass ideas.


Wow dude, you are ANGRY about something... that's fine, I get it, but you might consider looking into what that's about. It can't be much fun going through life pretending you want to fight everyone. To each their own I suppose.


More like, this community doesn't appreciate sarcastic jerks who make assertions without backing them up.


By hours, I assume you mean months. It took me just shy of two months to get my merchant account set up a couple years back.

In theory, you could do it in less time, but only if you already have your business licensed, registered and a business bank account set up in exactly the right way.

But since that's part of the list of things you need to do to get a traditional payment provider set up that Stripe doesn't require, it's a little disingenuous to pretend that setup times are in any way comparable.

I set up Stripe for two of my products recently. In both cases, it was a matter of minutes to get the account verified and processing real charges from real credit cards and having them sent to my bank account.


I think it's fair to say Stripe solved 4 problems. i) The time it takes to get a merchant account. It is only 24 - 72 hours unless something really goes wrong through other channels but with Stripe it's immediate. ii) The probability you'll get a merchant account (not a slam dunk for startups but 100% with Stripe?) Many developers hate dealing with financial institutions and then getting turned down is a bit humiliating. All of that's removed and iii) A great API/documentation that people love (although a few others have that) and iv) Pricing that is very simple and straight forward.

In return for doing all that work for you their fees aren't as competitive as other alternatives. That's fair given the work they do.


I'm going to add a 5th: Being really simple. The first time I tried to figure out what a merchant account was, and a payment gateway, and all the associated fees, etc, was just exhausting.


That seems a little exaggerated... most merchant account providers get applications through underwriting in 2-3 business days. I'm not sure what "set up in exactly the right way" is since my merchant account applications only asked for the bank account # and routing #, and the first one I opened 8 years ago was tied to a consumer checking account. Opening a business bank account once I registered an LLC took less than 30 minutes at the local branch.


It may be worth noting (though you perhaps already know this) that our fees are all-inclusive. We don't charge extra for amex cards, international cards, qualified vs. non-qualified transactions, etc. These things often add up to make other gateways' fees higher than they seem.

Also, we have volume discounts for people processing more than a million dollars a year, so this may be something you'd be interested in.


That's what a company I worked with did, and I thought it was a bad decision.

The per-transaction fees are lower, but there is a monthly (or yearly) cost. The API is big because it covers so many cases that you probably won't use.

Plus there are fees. Sure, they'll let you do e-checks (every customer wants those, right?), but that's a fee. Return? That's a fee. Chargeback? Fee. Process transactions in real-time instead of a batch at the end of the day? Fee. Log into the web interface? It's free, but it kinda slow and hard to use so you'll waste far more time that you would expect.

If you've got a business that does a lot of sales, or sales of very hight dollar items, that kind of thing can really add up. But if your sales are smaller or much more sporadic then the time investment and all the little fees may end up making Stripe cheaper. Sometime an extra 1% more than pays you back in lack of stress.

Also, for what it's worth, I remember PayPal, Google Checkout, and Amazon all being roughly the same as Stripe.


I would use stripe for my products store but with authorize.net we are on 1 day delay deposits. Stripe is 7 days. With seasonal sales and inventory/advertising costs 7 business days is a long time.

We use stripe for everything else we build for clients though, and it's awesome.


You can negotiate all those BS fees to $0. For example.. I pay 0.1% + interchange. $0.05 per transaction gateway fee and $0.10 cc trans fee (includes AVS). $5/mo base fee. NOTHING ELSE (well chargeback fees, everywhere has that).

You have no clue what you're talking about. I guarantee Stripe will charge you CB fees too.

Only way Stripe is worth the time and % they jack it up is if you do LOW volume.

edit: 5 seconds in google and Stripe charges $15 for a chargeback, same as Chase. Basically paying Stripe 1% + another $0.15 or so per transaction. NO THANKS! No one doing any type of CC volume would be dumb enough to give that $ away.


You have it right, the key for stripe is LOW volume.


It might be trivial to charge, but storing credit card details and remaining PCI compliant is a nightmare for businesses, especially at scale. Trust me -- getting audited and fined because you're not PCI complaint is much more expensive than giving the burden to another company like Stripe. Plus, Stripe is great because they don't hold your customers' data hostage.


But using a service like authorize.net usually means using their PCI-compliant storage in turn with their e-commerce service. How it works is basically the data does not have to pass through your servers exactly like stripe works. They store the data in their servers and you use a key to pass that data to the e-commerce mechanism, never seeing the actual data yourself.

If you're interested the service is called the Customer Information Manager. You can use it to store any secure data that you'd rather not be responsible for. I've used it to great success.

My main reason for my love affair with authorize.net? Recurring billing. They nailed it.


If 1% of your revenue is worth not spending a few hours to figure out BS PCI stuff I suggest you rethink your priorities or you're doing really low volume where 1% is like $5.


It's not about figuring it out, the key thing here is transfer of risk. Its certainly won't be "bs" if you get a fine due to a breech.


There's about 5 million tutorials online how to do everything properly. < 1 day work for 1% of sales... HMMMMMMMMM. tough decision, not.


This kind of tone is generally looked down on here at HN. I think there's an argument to be made on your side, but you're doing an exceptionally poor job at making it in a civil and friendly way. I'm genuinely interested in the other side of the story, but you have to have the discussion in good faith.


There is a good argument to be made on his side. But it's a business decision on what adds the most value for people.

For most people, they aren't (and don't want to be) experts in payment processing. Improving their product moves the needle by more than 1% for the same (or less) effort than spending time on payment processing.


Sorry for being honest. Would you prefer:

Stripe is an amazing service and their founders are amazing people. I wish I could blow them, but they probably wouldn't even let me b/c the VCs are already all over that. On the other hand, for people who enjoy saving money, becoming PCI compliant and saving 1% + trans fees is another alternative and there are numerous tutorials available to help anyone do that within a few hours even if you are severely autistic.


No need to be an ass. Also, it's business 101 to focus on your core and outsource the rest: so yes, it absolutely is worth using stripe rather than building payment architecture yourself. You are probably the only person on Hacker News that thinks building all this yourself makes sense.


It's business 100 to not waste money. If 1% is not a lot to save you have a hobby, not a business. I do see you enjoy using every service imaginable. I imagine you are building your dumb idea on top of Amazon SES or sendgrid. And you even used some other dumbass start up to make an email submit form for new startups. You're a pro.


We (userfox.com) rely on mailgun.com for email delivery since it is a 'distraction' from our core: helping companies send interesting and relevant messages to their customers.


Doesn't that cost way, way too much as a one-off fee? I'd rather pay a small percentage more on each sale, as I don't have that many sales. Also, getting a merchant account appears to be too much of a hassle.


Uhhh, what do you mean? Go through Chase paymentech is like 1.9% or so for card not present.


I mean to set up. Also, I'm not in the US, does that work in the UK?


No clue about UK


I've never heard of this service before but it looks quite interesting. I wonder though, how feasible is something like this for paying membership dues in a small club, for example? Is there some other service does this a lot better?


WePay makes that particular use-case very convenient IME.


Stripe is a great service, but I get the feeling their PR company or marketing department promotes extensively here (Makes sense since its the target audience).


Dang, sinister plan revealed: I am in fact a sleeper agent sent back from 2016 to 2006 with the instructions to build the most unlikely business possible, gather 75k karma, and then pave the way for my shadowy masters to get on HN.

Seriously: they're on my blog because of the reasons in the post. My blog's on HN because, well, that's a complicated topic but suffice it to say that it happens with a fair degree of regularity.


For what it's worth, we don't have a PR company or marketing department currently =).

We try not to post on HN unless we actually think people on HN will like the content (and we've argued internally before and decided not to post stuff to HN because it didn't seem useful enough).


Eh, I wasn't meant to be so cynical (It just came across that way because I suppose I am!)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: