Stripe’s batch data infrastructure is built largely on top of Apache Hadoop. We use these systems for everything from fraud modeling to business analytics, and we’re open-sourcing a few pieces today:

Read more

Earlier this year, after raising $1M in May, Lawrence Lessig’s Mayday PAC announced an ambitious goal to raise $5M by the 4th of July—a goal which they met mere hours before the deadline.

One of the remarkable things about this campaign is how transparent they’ve been through the whole process. In August, they released anonymized records of all contributions from the prior three months to “enable researchers to study the pattern and nature of the contributions” they received.

Stripe helps Mayday to accept credit card payments, and with Mayday’s blessing, we did some digging of our own into the data relating to their $5M campaign. While we couldn’t look at every contribution (only those made using credit cards), we were able to discover certain patterns that wouldn’t necessarily show up in the published data set. We’d like to share here some of the interesting things we discovered.

Meeting a deadline

It shouldn’t be too surprising that the volume of donations went up as the July 4th deadline approached. By our count, over half of the donations were made in the last 48 hours of the campaign. We also saw some subtler changes in the final days:

• Overall, a healthy 17% of donations came in via mobile devices. But on the last day of the campaign, mobile use doubled: 32% of donors donated from their phones or tablets instead of waiting to get to their laptops.
• Repeat donations were three times as common in the final week. Between June 25th and July 4th, 14% of donations were from email addresses that had contributed at least once already. Although it’s true that repeat donations are more likely the longer a campaign goes on, it’s notable that in the previous week, repeat donations only made up 4% of the total—and only 1% the week before that.

Deadlines can be incredibly effective in fundraising: Mayday’s supporters were motivated to donate both immediately and repeatedly.

Checking out

Mayday’s donation page uses Stripe Checkout to collect payment information. Checkout optionally allows customers to store their payment info with Stripe, making future purchases easier. Since this works across all sites that use Checkout, Stripe already remembered the payment info for a portion of the people visiting Mayday for the first time. We were very curious to see how this would perform. Here’s what we found:

• The overall conversion rate, once a visitor got to Checkout on Mayday for the first time, was 78%.
• For users already logged in to a Stripe account, the rate shot up to 90%.

To put it another way, the chance that a visitor would abandon their donation at the Checkout step halved from 22% to 10%.

It’s worth repeating that these users weren’t on the Mayday site when they stored their details, and there’s no reason to expect they were any more likely to donate than anyone else—they just happened to have already used Stripe to buy something online in the past.

Even for repeat visitors to Mayday, who are more likely to donate than anyone else, having a Stripe account made a substantial difference. In general, visitors who had donated before had a healthy 87% conversion rate, but for those who were already logged in to Stripe, it was 94%.

Coming back for more

Looking at repeat donations prompted us to ask: do people donate more or less their second time? On average, the answer is roughly 50% more. While first donations had a mean of $88 and a median of $30, repeat donations had a mean of $114 and a median of $50.

Average doesn’t mean typical, however. If you look at each repeat donor one by one, it turns out they’re split almost exactly into thirds: 33% donate less the second time (most commonly half), 35% donate more (most commonly double), and 32% donate exactly the same. The averages get pushed up because doubling (and the occasional tripling or even quadrupling) makes a bigger difference overall than halving does.

Supporting your supporters

Supporting repeat donors was critical to the campaign’s success. When donors return to your site (probably at the last minute), make it easy for them: don’t make them find their laptop, and don’t make them enter their credit card again. Encourage them to increase their donation, but don’t expect it. When you make it easy enough, they’ll almost certainly help you out—94% of the time, anyway.

Come join us and our friends from Intercom for a meetup in Dublin on Thursday night. A handful of Stripes will be around, and we’d love to see you all at Intercom’s new offices for a chat and a pint.

RSVP via our event page.

We’ve started running game day exercises at Stripe. During a recent game day, we tested failing over a Redis cluster by running kill -9 on its primary node [0], and ended up losing all data in the cluster. We were very surprised by this, but grateful to have found the problem in testing. This result and others from this exercise convinced us that game days like these are quite valuable, and we would highly recommend them for others.

Read more

Starting today, any Stripe user can begin accepting Apple Pay in their iOS apps. Apple Pay lets your customers frictionlessly pay with one touch using a stored credit card. We think Apple Pay will make starting a mobile business easier than ever.

Apple Pay doesn’t replace In-App Purchases. You should use Apple Pay when charging for physical goods (such as groceries, clothing, and appliances) or for services (such as club memberships, hotel reservations, and tickets for events). You should continue to use In-App Purchases to charge for virtual goods such as premium content in your app.

When your customer is ready to pay, they’ll authorize a payment using Touch ID. Then, Stripe generates a card token, which you can use to create charges as you normally would through the Stripe API. It just takes a few lines of code to set up and display the Apple Pay UI:

- (void)paymentAuthorizationViewController:(PKPaymentAuthorizationViewController *)controller
                       didAuthorizePayment:(PKPayment *)payment
                                completion:(void (^)(PKPaymentAuthorizationStatus))completion {

    [Stripe createTokenWithPayment:payment
                        completion:^(STPToken *token, NSError *error) {
        // charge your Stripe token as normal
    }];
}

The following Stripe-powered apps already have Apple Pay enabled. You can try it out as soon as their updates hit the App Store. We owe them special thanks for all their feedback and bugsquashing over the past few weeks.

If you’ve got any questions, or need help getting started, please get in touch.

Get started with Apple Pay View documentation

A few months ago, we announced our Open-Source Retreat. Though we’d originally expected to sponsor two grantees, we ended up giving out three full grants (and then an additional shorter grant).

Here’s what happened with those grants:

• Julian Shapiro launched 1.0s of Velocity.js (an animation engine focused on performance) and Blast (a library that makes text manipulable).
• Ashwini Oruganti will soon be releasing a pure-Python TLS 1.2 implementation.
• Samuel Giddins pushed out two major releases for CocoaPods and the Molinillo dependency resolution gem.
• For his two-week grant, Andrey Petrov shipped a major urllib3 release, including upgraded security defaults and finer-grained retry configuration.

If you’d like more details, we’ll be hosting a meetup at Stripe on Tuesday, October 21st. The grantees will talk about their projects and where they plan to go next. RSVP on our event page if you’d like to attend in person, or view our livestream.

If you have any questions about the retreat, the projects, or anything else, please get in touch!

As you’ve likely seen, a design flaw in SSL 3.0 was announced to the internet yesterday, nicknamed POODLE. Unfortunately, it’s not just an implementation flaw—the only way to disable the attack is to turn off the affected ciphers altogether. Fortunately, the only common browser which still relies on SSL 3.0 is Internet Explorer 6 on Windows XP, which is a small fraction of internet traffic.

We’ve deployed changes to ensure Stripe traffic remains secure.

Our response

We’ve taken an approach similar to Google’s: We’ve disabled the now easily-exploited CBC-mode SSL 3.0 ciphers. We’ve also deployed OpenSSL with support for TLS_FALLBACK_SCSV, which prevents newer browsers from being tricked into using SSL 3.0 at all. This means that IE6 customers will (for now) continue to be able to purchase from Stripe users, and there will be no immediate user-facing impact.

Ending support for SSL 3.0

While there do exist some mitigations, there is no configuration under which SSL 3.0 is totally secure. As well, with so many websites responding to POODLE by dropping SSL 3.0 support entirely, we expect that IE6 on XP will soon stop working on most of the web.

Our plan going forward:

• Starting today, new Stripe users will not be able to send API requests or receive webhooks using SSL 3.0.
• On November 15, 2014, we will drop SSL 3.0 support entirely (including for Stripe.js and Checkout).

In the meantime, we’ll notify any of our users who we expect to be affected by this change. If you have any questions, please don’t hesitate to get in touch.

We’re open-sourcing Pagerbot, a tool we developed to make it easy to interact with PagerDuty through your internal chat system. (At the very least, we hope it'll help other companies respond to incidents like Shellshock or the ongoing AWS reboot cycle.)

Background

Like many tech companies, Stripe uses PagerDuty to help coordinate on-call schedules and incident response. The service is super reliable, does a great job of handling our normal rotations, and we appreciate being able to individually set preferences for how we want to get notified.

Fairly frequently, though, people will trade on-call shifts, whether because of travel, vacation, or even just making sure someone is keeping an eye on things while they’re out watching a movie. The communication about the trades mainly happens in one of our Slack channels.

Inspired by GitHub’s idea of chat-driven ops, we wanted PagerDuty schedule changes to happen in the same place as the rest of our communication.

We’ve tried to make Pagerbot easily handle our previous scheduling woes. For instance, with Stripes scattered all around the world, juggling timezones is very confusing, but if you don’t specify a timezone in your queries, Pagerbot automatically uses the timezone you configured in your PagerDuty profile.

Over time, we’ve added more commands to Pagerbot. For instance, based on Heroku’s incident response blog post, we added support for explicitly paging an individual:

Deploying to Heroku

Pagerbot supports both Slack and IRC and although you can always run Pagerbot on your own infrastructure, we’ve also made Pagerbot compatible with the new Heroku Button:

(Note: Heroku requires you to provide a credit card to enable the Heroku MongoDB addon, though you won’t actually be charged anything).

Once you’ve deployed Pagerbot to Heroku, there’s a built-in admin panel you can use to get things set up. You’ll need to tell Pagerbot about your PagerDuty subdomain, your chat credentials, and any aliases you want for either people or schedules.

We’ve also tried to make it easy to add new commands to Pagerbot by building a simple plugin architecture. Feel free to fork Pagerbot and add your own plugins.

We’ve been using Pagerbot as our main interface to PagerDuty for over two years now. If you use PagerDuty and either Slack or IRC, we hope you’ll find it useful — check it out, and let us know what you think!

We’re fans of Go (both the language and the game) here at Stripe, and it seems we’re not the only ones. In recent months, we’ve seen Go’s popularity rise amongst our users and more generally in the open-source community, so we decided to add an official Stripe library for Go.

Requests made to Stripe using Go in 2014

We’ve also started using more Go at Stripe internally. For example, parts of the system that power Checkout are built in Go (and use this library). When porting some existing services to Go, we’ve noticed 2-4x increases in throughput (and our engineers were pretty happy with the development process).

To get started with our Go library, go get github.com/stripe/stripe-go and then import it in your code. Here’s how you’d create a charge:

import (
  "github.com/stripe/stripe-go"
  "github.com/stripe/stripe-go/currency"
)

params := &stripe.ChargeParams {
    Amount:   1000,
    Currency: currency.USD,
    Card:     &stripe.CardParams{Token:"tok_mastercard"},
    Desc:     "Gopher t-shirt",
}

There are two ways to make calls with the library, based on your needs. The simplest way is to use the global implicit client and invoke the APIs:

import (
  "github.com/stripe/stripe-go/charge"
)

stripe.Key = "tGN0bIwXnHdwOa85VABjPdSn8nWY7G7I"
ch, err := charge.New(params)

If your scenario involves concurrent calls or you’re dealing with multiple API keys, you can use an explicit client:

import (
  "github.com/stripe/stripe-go/client"
)

sc := &client.Api{}
sc.Init("tGN0bIwXnHdwOa85VABjPdSn8nWY7G7I", nil)

ch, err := sc.Charges.New(params)

Given Go’s lack of built-in versioning, we highly recommend you use a package management tool to avoid any unforeseen upgrades.

The library features iterator-based listing, which handles pagination for you automatically. We’ve also added support for injecting mocks to make testing easier. And if you need more control, the library allows you to inject your ownhttpClient for transport-level customizations.

Check out the docs (or the GoDoc) for more details and examples. Let me know if you have any feedback, or send a pull request my way!

We have a few events in Canada in the upcoming months—hope you can join us!