Many Stripe users send email receipts for payments, and we’ve received a lot of requests to support sending receipts directly from Stripe. While our webhooks are powerful and can be used to build events for things like account creation and customer cancellation, we want to make common cases—like sending receipts—easy.

Starting today, you can enable email receipts for your users in a single click. Just head to the emails section of your dashboard settings to enable them. Along with specifying basic business details, you can upload a custom logo, from which we’ll automatically detect the optimal header color for the email.

Using our friends at Dribbble as an example, the receipts look like this:

Once enabled, we’ll send an email receipt every time you charge a customer that has an email address configured, for both recurring subscriptions and single time purchases. The emails will only be sent for payments in the live environment.

As always, we’d love to hear your thoughts on this feature and any other ones that would improve Stripe—drop us a line!

Stripe is now in beta in the UK, and to celebrate we're throwing a hackathon in London. Come hack on a project, meet other coders, hang out, or just work on eating the food. Feel free to bring your own project or start one on the fly.

This hackathon will be very informal. Stripe (in conjunction with Level 39) provides the space and the food. You provide the project, or start one with other coders who are attending. Your goal for the day should be to walk away having built something cool. Past Stripe hackathon projects have ranged from building a simple PHP website to adding a new feature to Git to assembling a 3-D printer.

All are welcome (no ghostly hounds allowed, though)!

RSVP via our London Meetup group. Hope to see you there!

Stripe makes it easy to accept payments on any platform: web, mobile, desktop, or tablet. Many companies, like Lyft, Exec, Postmates, SideCar, Sesame, and OrderAhead, use Stripe to make paying on your iPhone or Android a snap.

These libraries make it easy to accept payments in any iPhone, iPad, and Android application. Our mobile guides walk you through collecting credit card information, tokenizing cards, and storing payment credentials for billing later.

Today, we’re also partnering with Parse. Parse helps developers create mobile applications by eliminating a lot of the server-side boilerplate and providing pre-built libraries for common tasks.

If you're building an app on Parse and want to accept payments, you don't need to write any server-side code. Just create a Stripe token within your mobile app, and then pass the token to a Parse Cloud Code function to create a charge. There’s more in Parse’s documentation.

Both the Parse platform and Stripe’s mobile libraries help with building native mobile apps, but the mobile web is growing rapidly too. We released Checkout a few weeks ago to help create better payment flows. (Head over to The Magazine and subscribe from your phone if you’d like to see it in action.) If you’re building for the web, Checkout delivers an optimized flow for all devices, including smartphone and tablet browsers.

We have many more improvements planned, and we’d love to hear your feedback on what we’ve built to date.

We wanted to share some quick news of a few ways the Stripe dashboard has gotten even better:

New Two-step Overview in Team Settings

A few months ago we added two-step verification to Stripe. Now, you can see which members of your team have enabled this additional protection in your team settings.

New API Errors Overview

Though we hope it happens rarely, your API requests will sometimes return an error. If you’ve set up careful monitoring on your servers, you might get e-mailed about these errors. And if you’re vigilant, you might actually investigate them. We thought we could make this process a bit easier, and take some of the burden off your own monitoring in the process.

Now, when you visit your dashboard logs, you'll be greeted with an overview that includes any recent errors returned by our API. You can review details about the cause of each error, and suggestions actions we think you may want to take as a result.

New Retry Test Webhooks

Integrating webhooks can get a bit complicated, given the wide range of scenarios you may want to test, and the natural process of working out the bugs in your webhook endpoints. To help, we've added a quick retry button on every event page.

New Friendlier Events List

We think our event system is great because it’s so powerful and flexible. And yet, when reviewing events on your dashboard, the interesting things that are happening your account can be a bit hard to see. So we’ve redesigned the event list to make it easier to read and understand.

Instead of just listing IDs and types, we show you a short sentence describing what happened in each event. It’s something like a news feed for everything happening in your account, with pictures of your customers right next to each story (based on their email addresses, and powered by Gravatar).

UPDATE: in December 2014 (about a year and half after this post), we blogged about our experiences scaling email transparency.

A few months ago, Alex blogged about how we work at Stripe. In the post, he described how almost all of Stripe’s email is public inside the company. Since then, many people have asked about how this email openness actually works. Is it really the case all our mail is copied to a list? If so, how do we avoid drowning in email?

This post is an attempt to describe a little more about why we do this and how we stay afloat.

Background

Initially, the motivation for having all email be internally public and searchable was simply to make us more efficient. If everyone automatically knew what was happening, we needed fewer meetings, and our coordination was more fluid and more painless if we could all keep up with the stream.

As we’ve grown, the experiment has become about both efficiency and philosophy. We don’t just want Stripe to be a successful product and company. We also want to try to optimize the experience of working here. As as we’ve grown, we’ve come to realize that open email can help.

We value autonomy, rigorous debate, and avoiding hierarchy to the extent that we can. Startups often pride themselves on having a flat management structure but are eventually forced to put a formal coordination infrastructure in place as the number of actors grows. So far, our experience has been that an ambiently open flow of information helps to provide people with the context they need to choose useful things to work on. It doesn’t eliminate the need for other kinds of structure, but it does make emergent coordination much easier and more likely.

It also makes it more likely that controversial issues are addressed as they arise, counteracting inevitable conflict-avoidance tendencies. The open flow obviates a lot of internal politics and avoids the sort of accidental surprises that sometimes crop up in organizations. It also makes everyone happier. Most people at Stripe are information junkies, and are naturally curious about how other parts of the organization work. We want to encourage that.

Tools

While the principles might seem worthwhile, the obvious question is how it can actually work in practice. The amount of email we generate increases at least linearly with number of people. How do we avoid being overwhelmed?

Over the last two years, we’ve gradually added structure as necessary in order to keep things under control. What we have today works pretty well for our current size—around 45 people.

We use Gmail for email and Google Groups for lists. We’ve been able to scale our particular usage with a custom list management interface built on the Google Groups API. The interface makes it easy to manage list subscriptions, get notified of new lists being created, and so on. (We plan to open-source it at some point.)

Once people are subscribed to the right lists, dealing with the large volume of email efficiently is the next step. We use a number of filters to ensure that the traffic gets sensibly handled and categorized. The vast majority of our email is automatically labeled, archived, and then skimmed occasionally. The semantics can get pretty subtle, and Andreas wrote a filter manager that many of us use.

List structure

We have 119 lists as I write this post. Most of the lists are specific to a particular project, but some (such as 311@, if you have an issue you’re otherwise not sure where to send, or shipped@, where you announce something you’ve launched or completed) are company-wide.

In order to make this work, strong and clear defaults are important. Here’s how the structure is described on our wiki:

Stripe lists follow one of these forms:

foo-announce@: Email from the foo project to the company at large. These lists are generally low-traffic, have self-contained postings, and are intended for people who aren’t keeping up with the project in real time. For example, recruiting-announce@ is where we post notifications of job offers and outcomes thereof.

foo@: Email that would be on a traditional discussion list goes here. In other words, pretend that foo-archive@ did not exist. In that universe, would you send you mail on-list or off-list? If on-list, send to foo@.

foo-archive@: Email that you want to grant other people read access to, but don’t have any real expectation of them reading. Use this for email that would traditionally be off-list, whether due to volume or being targeted to a particular recipient or just being generally uninteresting.

foo-bots@: Automated mail for the foo project goes here. Depending on the project, it may be important for you to read this email. (For example, all breakages go to breakage-bots@, and so people who are triaging breakages should watch that list.)

In general, if you’re debating including an archive list, you should probably just include it. This includes internal P2P email which you would normally leave off a list, emails to vendors, and scheduling email. (If the email is sensitive in some way, though, it’s fine to leave it off-list.)

What you should read

• You should definitely read any email sent directly to you.
• You should at least skim (or skim the subject lines of) all emails to the foo@ list for the project you’re currently working on (e.g. product@, ops@, etc.).
• You should feel no obligation to read any foo-archive@ lists. If you find yourself having to trawl through those lists in order to get things done, that means that foo-archive@ is getting traffic it shouldn’t.

You should also keep these conventions in mind when assessing what mail you expect other people to see. In particular:

• You should expect mail sent to a person to be read by that person.
• You should expect mail sent to a project list to be read by most people working on that project.
• You should not expect mail anywhere else to be read by a human.

Email Use Cases

We support the following use-cases. Details about which list to send to in each case is shown below. If you ever find yourself thinking hard about which list to CC, just pick one—it’s not a big deal to have email go to the wrong list.

• human → external human (e.g. Darragh → banking partner):
  • CC a project list (project@): when you want the outside human to know they’re on-list, and respond including the list.
  • BCC a project list (project@): when this is something you’d like others on your project to be aware of.
  • BCC a project archive list (project-archive@): when this is something no one else needs to care about at the moment (e.g. scheduling a meeting time with someone).
  • Leave off list: if there’s personal content that you’re not comfortable with others seeing (this case should be pretty rare, and tends mostly to come up when recruiting friends).
• human → Stripe human (e.g. Andy → Sheena):
  • CC a project list (project@): when this is something that you’d like other Stripes to be aware of or feel invited to participate in.
  • CC a project archive list (project-archive@): when no one else needs to be thinking about this problem and you’re having a direct conversation.
  • Leave off list: when you have constructive criticism relevant only to that person. You should always feel free to point out problems and places for improvement (trying to maximize quality is pretty core to Stripe), but this is one case that’s generally better to handle in private. (Still, broader questions like “should we even be working on this product” are usually best handled on-list.)
• human → project (e.g. Greg → people working on systems):
  • CC project list (project@): always.
• human → company (e.g. Amber announcing the attendance numbers from a hackathon):
  • CC a project announce list (project-announce@): if there is a relevant announce list.
  • CC all@: otherwise (you should feel welcome to post stuff to all@—current traffic is about 10 messages a day).
• robot → project (e.g. PagerDuty to developers):
  • CC a project-bots list (project-bots@): always (note that bots lists all have a Reply-To set to the corresponding project list).
• robot → company (e.g. hourly stats report):
  • CC all-bots@: always

One important property of this setup is that it’s opt-in: no email is automatically made public, and what lists to copy (or not) is a decision that’s taken on a per-email basis.

As with much of what we do, we’re not sure yet how this will scale. Still, most of the experience of a startup is doing things that work well at some size, and then figuring out how to make them continue to work as you grow. The email transparency is something that people consistently identify as one of the best parts of Stripe’s structure, and we plan to work hard to retain its core properties as we grow. If you end up implementing any of these practices in your workplace, I’d be very curious to hear how it goes.

A rising tide lifts all boats, and we’d like to help improve payment experiences for consumers everywhere, whether or not they use Stripe. Today, we’re releasing jQuery.payment, a general purpose library for building credit card forms, validating input, and formatting numbers. This library is behind a lot of the functionality in Checkout.

Read more

Today, we are releasing MoSQL, a tool Stripe developed for live-replicating data from a MongoDB database into a PostgreSQL database. With MoSQL, you can run applications against a MongoDB database, but also maintain a live-updated mirror of your data in PostgreSQL, ready for querying with the full power of SQL.

Read more

From talking to our users, it’s clear to us that building great payments forms is hard, and that small details can have a big impact on the user experience. Even minor tweaks regularly drive substantial swings in conversion rates. Creating a great payment flow is a design problem faced by almost everyone running an online business.

And so we started trying to figure out how we can help. We see millions of transactions, and have access to a lot of data about what works well and what doesn’t. We wondered whether we could create something that looks great, makes Stripe easier to integrate, improves with time, and results in a better payment experience for users.

We’ve been experimenting over the past few months, and we’re ready to release our first version today.

Even simpler integration

It’s unfortunate that everyone has to reinvent the wheel when the time comes to implement a payments UI. We decided to build something that you can just drop in as a single tag:

<script src="https://checkout.stripe.com/checkout.js"
    class="stripe-button"
    data-key="pk_Fhlzwtm9SCx6Uxww5fNXX8CUbwwAc"
    data-amount="2000"
    data-name="Demo Site"
    data-description="2 widgets ($20.00)"
    data-image="/128x128.png">
</script>

Rather than show the payment form directly on the page, we decided to have it appear as an overlay. This, combined with the dimmed background, helps to provide a little separation from the enclosing page while still making it clear to users that they haven’t left the site. We’ve worked hard to make sure that it fits well with almost any design. Try out the demo above with our test card number 4242 4242 4242 4242.

Though you’re welcome to use the button we show here, you can trigger the Checkout’s overlay with any HTML element or JavaScript event—the blue button is just a default. There’s a full JavaScript API and a bunch of configuration options. We do all the validation, input formatting, and error handling for you, as well as taking care of securely transferring your customer’s payment information to Stripe.

Built-in mobile support

Despite the explosion of smartphones and tablets, a web site’s mobile payment flows are often neglected. Developers are confronted with a plethora of devices, screen sizes, and browser-specific challenges. We wanted the form to automatically adapt to mobile devices, and it includes a dedicated mobile flow, optimized for iOS and Android.

Of course, it’s not just about supporting recent devices. This also works on all major browsers, including IE 7 and above.

Optimized, tested, and always improving

Over the last few months, we’ve been field-testing on a variety of sites, collecting data and incorporating feedback. The early results are promising—for example, App.net increased their conversion rate by 10%—but we don’t yet have enough data to make any conclusive claims.

Ultimately, we think the structural shift is most important. Normally, you build a payment form and move on. Maybe you eventually get time to revisit it a year later. By integrating Stripe’s payment form, your checkout is continually improving. As we refine and iterate over time, we’ll be able to immediately pass enhancements on to anyone who uses it. We’re looking forward to seeing what you build, and to doing our part to help improve commerce on the web.

Start accepting payments today. View Checkout documentation

Come say hi to Evan, Nelson, and me at the Cambridge Brewing Company on Thursday night. We would love to chat with you and buy you a beer!

RSVP via our Meetup event.

In an effort to make sure you get paid with as few hitches as possible, we've made some improvements to how we expose information about transfers to you. Happy new year!