Dan Wood: The Eponymous Blog

(OK, hope you can see those Emoji characters in the title!)

We recently started using Stripe as our main payment processor on our Karelia Software Web Store. I thought I'd sing its praises here.

For the past five years or so, we had been mostly using PayPal to collect payments from our customers. But I was never really happy with it being our primary way of processing credit cards. Yes, I've heard some horror stories about merchants' accounts being frozen, but my main issue was that it just felt slightly second-class. If I see a website that only accepts PayPal, it doesn't feel as much like a "real business" as one that processes the credit card themselves. Plus, I know there are a lot of potential customers who hate PayPal, or maybe it just doesn't work in the country where they live.

A couple of years ago, I looked into getting a full-fledged merchant account and setting up a shopping cart gateway, but it was absolutely daunting. Just understanding all of the pieces we'd have to get working, and the compliance hoops we would have to jump through was overwhelming, so I didn't make it far into my research.

I'd heard great things about FastSpring from fellow indie Mac developers, and we did actually use them as an alternate processor for a while, but I just wasn't that thrilled. They didn't integrate into our customer database system very well, and, like other similar processors, they function by taking users away from your site and onto their site. I don't like the idea of not having control over customers' experience or not being able to even measure how successful the interaction is, because buyers would be going off-site. Plus, it's hard to make the payment processor's site appear seamless to the user — it's usually obvious that they are going to another website.

So when I heard about Stripe, I was thrilled. Finally, a way to process credit cards that lets us control the experience on our own site, but also easy to implement.

Here are some aspects of Stripe that I like:

• It feels "native" to the customer. They stay on our website.
• It's much easier to implement than PayPal (with its crazy IPN and PDT notifications) or full-fledged payment gateways.
• The company and their website are very developer-centric. The documentation has examples in PHP, Curl, Ruby, Python, and Java! In fact, the documentation is "live," so that if you are logged in, the example code is hooked up to your test-data API keys, so you can just try it out right away.
• Technical support is just amazing. I had a bunch of newbie questions that were answered quickly and helpfully.
• Reasonable fees, close to PayPal, and way less than the full-service providers like FastSpring and eSellerate. (Here's a great argument against obsessing over a couple of percentage points).
• Extremely easy to try things out in a test mode before switching to live data. Much easier than PayPal's "sandbox" system.
• Web Hooks: Our server can get pinged when something happens. We have a script send us an email at the end of each business day when the day's charges have been calculated and a transfer to our bank account is queued up; the script also gets pinged if there is a chargeback on somebody's card — very rarely since we've switched to Stripe, BTW — so our system can automatically send the person an email to try and resolve the issue.
• Refunds can be done with an API, so we've hooked that up to our back-end application we use for looking up licenses.  It's much easier than looking up somebody's transaction in our system, and then logging into PayPal to process the refund!

Don't get me wrong; Stripe isn't perfect (yet). Here are a few drawbacks:

• Stripe is only set up for US- and Canada-based businesses. They are slowly expanding into other countries, however. This isn't a big deal since we're US-based, but it might not be an option if your business is set up elsewhere in the world.
• They only accept US (and maybe now Canadian?) dollars. We would prefer to offer our product in the customer's native currency so they don't have to think about currency exchange.
• Funds collected are held, and not deposited into your bank account, for 7 days. With PayPal, theoretically you could get your money out of PayPal and into your bank in just a few business days.  (Then again, some processors make you wait a whole month to get your money. So seven days isn't really a big deal.)
• JavaScript is required for the processing to work. Then again, so what. PayPal requires JavaScript too.
• Credit Card Security Codes (that three- or four-digit code you have to enter in a lot of forms) aren't really checked adequately using the current APIs. Hopefully they'll improve the APIs so we can require the code to match before letting a charge through.

These are not major issues, though — at least for us. So we're using Stripe now.

We are also continuing to use PayPal, in parallel, as an alternate method of payment. What have we got to lose by continuing to support PayPal? It seems that a decent chunk of our customers prefer to use PayPal. I can see how people who know and like PayPal would choose to pay that way.  If you were familiar with PayPal, and you were buying something from a company you've just learned about, would you trust your credit card to them, or use PayPal for the 20th time?

How Stripe Payment Processing Works

For those who are technically inclined, here is how Stripe manages to function while the visitor stays on your website.

You build a web form with regular <input> elements, but you don't give the elements name attributes, which would normally cause the credit card information to be sent to your server — something you don't want to happen. Instead, you hook up your submit button to a bit of JavaScript. This script grabs the credit card information, and sends that over to Stripe's secure servers. Stripe returns a string token, which your script inserts into your form as a hidden element.

Then, the form — without any credit card number, but with the hidden Stripe token, gets submitted to your server. Your back-end script then asks Stripe to charge the card represented by that token; then it does whatever it needs to process your payment. (In our case, it generates a license to Sandvox.)

Control over User Experience

When I started this project, I realized that for the first time, I could control what the payment form looked like and how it behaved! I spent a lot of time working on what I felt would be a great experience. But that's a topic for another post.

Is Stripe for you?

I think that there are a few different kinds of Mac indie developers. Those who don't want to have to deal with customer databases and payment processing might as well just use the Mac App Store as the distribution mechanism. Then there are the people who want to be able to sell directly to customers, but want a full-service company to handle the processing issues. FastSpring is great for that. But if you want more control over your purchasing experience, and you can set up some scripts on your server to manage license generation and charge cards, then Stripe is a great way to go. (And also, possibly, PayPal for those prefer that option.)

Have any of you tried out Stripe?