Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe And A/B Testing Made Me A Small Fortune

kalzumeus.com

Post reply on HN
Print view View original

31–40 of 164 posts

Re: Stripe And A/B Testing Made Me A Small Fortune

#31

Post by patio11 »

Irishsteve wrote: post #24

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.

Re: Stripe And A/B Testing Made Me A Small Fortune

#32

Post by saikat »

Irishsteve wrote: post #24

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

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

Re: Stripe And A/B Testing Made Me A Small Fortune

#33

Post by saikat »

MBCook wrote: post #30
TomGullen wrote: post #7

> 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…

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…

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.

Re: Stripe And A/B Testing Made Me A Small Fortune

#34

Post by ceejayoz »

TomGullen wrote: post #7

> 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…

> 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

Re: Stripe And A/B Testing Made Me A Small Fortune

#35

Post by modoc »

MBCook wrote: post #30
TomGullen wrote: post #7

> 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…

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…

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

Re: Stripe And A/B Testing Made Me A Small Fortune

#36

Post by MBCook »

sulife wrote: post #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 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.

Re: Stripe And A/B Testing Made Me A Small Fortune

#38

Post by [deleted] »

MBCook wrote: post #30
TomGullen wrote: post #7

> 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…

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…

[deleted]

Re: Stripe And A/B Testing Made Me A Small Fortune

#39

Post by TomGullen »

ceejayoz wrote: post #34
TomGullen wrote: post #7

> 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…

> 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…

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

Re: Stripe And A/B Testing Made Me A Small Fortune

#40

Post by dcaldwell »

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.
Post reply on HN