Changing Your Stripes

Recently we made good on a long-held idea that there should be a weekend for finishing things. Enter Finish Weekend.

We knew we’d need registration to tell us how many people would be coming. Obviously this plays a part in the size of our space, the food we provide, and the number of T-Shirts. To keep the registration honest, we decided to charge a small fee to each registrant. That’s where Stripe comes in.

Stripe uses a two part approach. First, using their Stripe.js library, you send the credit card information to their secure servers and they send back a single use token. (We’re using coffeescript here)

  number: $('.card-number').val(),
  cvc: $('.card-cvc').val(),
  exp_month: $('.card-expiry-month').val(),
  exp_year: $('.card-expiry-year').val()
  }, amount, (status, response)->
    if status == 200
      $form = $("#registration-form")
      if $(".alert-message").length

This token is then submitted with in a form to your servers where you can make use of one of Stripe’s libraries to actually charge the card. We use Ruby on Rails, so our code looked something like this:

Stripe.api_key = Rails.env.production? ? "LIVE_PRIVATE_KEY : "TEST_PRIVATE_KEY"
charge = Stripe::Charge.create(
  :amount => 1000,
  :currency => "usd",
  :card => token,
  :description => "Finish Weekend Registration (#{params[:person][:name]})"

Part of the magic of the token passing process is having a public/private key set to be able to pass around. Since these are different for the test and live environments, we do a little magic of our own. We’re using Rails 3.1 for Finish Weekend, so we can just tack on .erb to the end of our script file which allows us to do this:

Stripe.setPublishableKey('<%= Rails.env.production? ? 'LIVE_PK' : 'TEST_PK' %>')

Overall Stripe has been awesome to work with. We got this up and running in less than an hour.


    November 01, 2011 at 9:54 AM

    Stripe is very expensive. I guess they don’t claim to have good rates, just be programmer friendly, but it’s a pretty big tax on revenue collected through them. Other methods may not be as easy to setup initially, but most rates are better.

  2. November 01, 2011 at 10:00 AM

    Getting up and running quick is worth a lot, and you don’t have to pay for a merchant account. Cheaper in the short-term, and if your volume is low, it is going to be cheaper in the long-term too.

    You can always launch an idea and start collecting money quickly, then move to a “better deal” later. 

    November 01, 2011 at 11:14 AM

    Question: From your description it sounds like the javascript in the client passes the card data directly to Stripe, not through your server. Is that true?

    If so, it’s a pretty tidy way to avoid PCI issues on your server.

  4. November 01, 2011 at 11:20 AM


    Yep, that’s exactly how it works and why we’re fans.

  5. November 01, 2011 at 11:22 AM

    wrote a .net library here if anyone is interested :)

  6. November 01, 2011 at 12:01 PM


    We recently switched from Braintree and the rates at Stripe are actually cheaper overall. And Braintree was a pretty good rate when we were with them - check out this post they did which brings up a lot of good points:

    Additionally, the rates from Stripe have no other fees… for instance no rate difference for business cards vs personal cards. Even better, there is no “monthly minimum” so you won’t be out of pocket $130+ every month like you are with Braintree. So in the end you’ll probably save or break even with Stripe.

  7. November 01, 2011 at 20:24 PM

    Couldn’t agree with you more. Stripe is fantastic. 

    Still, why not just determine rails environment when you set your private key constant rather than when you’re creating a charge?  This way you don’t have to evaluate  your current environment every time you need your API key.  I think I actually just set the api globally via an intializer.

    I do wish they had a bulk means of deleting test data.  I have loads of test records now.