Stripe And A/B Testing Made Me A Small Fortune

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.

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).

> 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

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.

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.

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

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

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.

Sounds like an opportunity to me.

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.

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.

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.

Oopsie. Thanks for the correction.

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

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.)

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.

How do you know this for a fact?

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.

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.

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.

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

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.]

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.

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

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.

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

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.

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.

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.

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.

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.

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.

WePay makes that particular use-case very convenient IME.

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).