Monthly Archives: September 2013

If your web app uses Stripe for online payments, you should test Stripe thoroughly. For growing apps, you need both manual and automated tests. I first learned about automated tests in an awesome EdX course about Ruby on Rails, and the concept was mind-blowing for me. Your app can tell you when the code you are adding to it is having unanticipated consequences, so you can feel secure that you are not breaking your app by adding new features.

Anyway, Stripe is a developer-focused payment processing service. It’s become a popular way to process online payments, particularly for subscription-based sites.

I’ve recently had the pleasure to work on Cook Smarts, a site that I originally featured in this blog and now have actually started helping with directly.

Cook Smarts uses Stripe to process payments. Cook Smarts’ meal plan service is subscription-based, and it is essential that Stripe function as expected, so we knew we’d have to test it well.

Here are some strategies that helped. This is written from a Ruby on Rails perspective, but the concepts would apply to any language.

Separate your API keys

Stripe provides two API keys for your site – a production key that can charge people real money, and a test key that cannot. When you are developing your app, you need to be careful not to accidentally use your production key, or you could do some real damage to your customers’ accounts.

In Rails, wherever an API key is used, I put in place logic to choose the production or test key based on the current environment, like so:

Update 2/17/2015: It’s advisable to keep API keys out of your code. Use environment variables instead. dotenv is a great way to specify environment variables on development.

Test manually

Once your API keys are separated, you can jump into your app on your development environment, and start playing with Stripe. Stripe offers test credit card numbers that you can plug into your dev environment to simulate successful transactions. You can play the role of a customer that is actually buying something, and then look at what happens on your Stripe test dashboard as a result.

Test operations and webhooks with RSpec

With RSpec, a popular testing tool that plays well with Rails, and another gem called stripe-ruby-mock, you can create a fake Stripe that your app interacts with in your tests. This way, your tests do not have to call out to Stripe at all, and run much faster.

You could then perform operations on the fake Stripe customer in your test, and it would never have to call out to the real Stripe site.

We handle various webhooks from Stripe, which is just a way for Stripe to tell Cook Smarts that something happened with a customer’s account. It is important to test these. One change I’ve made is placing more of the webhook response logic in the app’s models, where they are easier to test. I have not yet figured out how to simulate a webhook with RSpec in the development environment, but thoroughly testing the steps after the webhook is initiated gets us close to full coverage. After that, keep an eye on your production Stripe event log (which shows which webhooks your app received and when), and confirm that your app is doing what it should in response to webhooks.