We’re excited to share a couple of improvements to our email receipts! We’ve learned a lot since launching the feature over a year ago.

As before, our receipts work across all popular mail clients. (Yes, they even look fine on Lotus Notes 8.) We’re always looking to make receipts more useful for you—do let us know if you have any feedback.

Since Stripe's earliest days, we've believed the world needs simpler and more open protocols for moving money. We launched our Bitcoin beta four months ago, and we recently published some of our thoughts around cryptocurrencies. Today, we're excited to see the launch of Stellar, a new open-source project and nonprofit organization to which we've provided seed funding.

Stellar is (like Bitcoin) a decentralized payment network; unlike Bitcoin, it supports transactions in arbitrary currencies—you can use dollars, Euros, bitcoins, or anything else. Stellar implements something very close to the idealized "IP layer for money" idea that we described last week. You can find more details (and obtain your first "stellars", the network's native currency) by reading their launch post.

Development is led by Jed McCaleb and Professor David Mazières in collaboration with a small team of others. (The technology is based on the open-source Ripple project, originally created by Jed a few years ago.)

Stripe's role

Stellar's goal is to build a great transport layer for transmitting monetary value. Figuring out how to efficiently move money is something we support very strongly: Stripe spends a lot of effort integrating different banking and finance protocols in various countries (17 at last count). We've always considered it unlikely that these systems would be just as fragmented in twenty years. Bitcoin has already changed the world by drawing attention to the value of open, distributed protocols that enable the transmission and storage of money. Stellar aims to advance this success by providing a way to transact in one's currency of choice, whether that currency is fiat or digital.

We're very bullish on the cryptocurrency space in general, and expect that multiple systems will prosper. When the opportunity arose to help Stellar, we enthusiastically agreed. A couple of months ago, Stripe contributed $3M to help get the project going. In return, we received 2% of the stellars. However, the project is not run by Stripe. We just believe that a system with properties like Stellar's should exist in the world, and we heartily encourage anyone interested to participate in its development. We're going to auction a majority of our stellars to other interested companies, with any net profits being returned to the Stellar Foundation—please get in touch if your company might be interested.

Stellar is highly experimental, but we think it's important to invest effort in basic infrastructure when the opportunity arises. Jed and David are the perfect people to tackle something like this. If they and their team pull it off, Stellar could become a much better substrate for a lot of the world's financial systems.

Read more at Stellar.org

We want to make it easy to accept payments no matter where you are. Today, we’re launching in Australia—our first country in the Asia-Pacific region.

When I moved to Australia a couple of years ago, I quickly noticed that online payments were unnecessarily awkward for businesses here—protracted setup, stacks of paperwork, and convoluted approval processes. We’d like to fix this.

Starting today, Australian businesses can instantly start accepting payments from anyone, anywhere in the world. All you need to bring is your bank account number.

Pricing is simple and predictable: 1.75% + 30c for Australian cards and 2.9% + 30c for international and American Express cards. We’re also bringing our full international currency support with us, allowing Aussie users to charge in 100+ currencies. We’ll sort out conversions for you, and transfer funds to your bank account in AUD.

Volume pricing is available for businesses at scale—please get in touch if you expect to process more than $40,000 a month.

We’re also hiring in Melbourne and Sydney. We already have a contingent of six Australians working at Stripe, hailing from all parts of the country, including Perth, Hobart, Sydney, Melbourne, and country Victoria.

During our beta, we have been delighted to watch Australian businesses build world-class products, including Canva, LIFX, Sitepoint, BlueChilli, and Flightfox. Now that we’ve launched, we look forward to working with many more.

Start accepting payments instantly. Get Started with Stripe

Many people have remarked that Bitcoin resembles the internet in the early 90s: we haven’t yet built the Googles that will make it accessible or the Facebooks and Netflixes that will make it broadly useful. So it’s an open question: what might a Bitcoin that’s useful for the mainstream look like?

Money

Money has three functions: it’s a store of value (that is, somewhere you can put your life savings), a unit of account (that is, a measure of value), and a medium of exchange (a way to transport value). On the first two fronts, Bitcoin has shown promise in high-inflation economies, but it’s a much tougher sell for mainstream consumers in stable countries. There, consumers mostly want a safe place to hold their savings, and the existing bank account insurances and consumer protections have set a high bar.

However, Bitcoin has huge potential as a way to transport value. It’s surprisingly difficult to move money today, and the experience of paying for something online is just about the only part of the internet that hasn’t changed dramatically in the past twenty years. There are a few walled gardens with great payment experiences (the App Store, Amazon), but otherwise it’s still a wild west of punching in your card details. (We’re working on it, though.)

Compounding the issue, value transport becomes especially challenging as soon as there’s a regional border involved. This is in stark contrast to the transmission of information: if you’re using the internet in Honduras, you don’t need to figure out how to hook up your local ISP to send packets to Kenya. But traditional payment systems look a lot like computer networks before the internet.

Cryptocurrencies have given us a real opportunity to solve these problems.

Gateways

If we want to make Bitcoin useful but still allow consumers to think in their local currencies, the place to start is likely by building a series of “gateways”. These gateways should allow people to transparently get into and out of the network, while always thinking in terms of their normal currency.

A consumer could go and sign up for a gateway in their country, link their local bank account, and then specify all their actions in currencies they understand: “send £10 to this destination; send $20 to that destination”.

Behind the scenes, the sender’s gateway would convert the specified amount to Bitcoin and send those bitcoins to the recipient’s gateway. The recipient’s gateway would then translate the received amount back into the recipient’s preferred currency.

If this became widely adopted, we’d suddenly have proper connectivity between the world’s financial systems. Today, each of those systems does a reasonable job of moving money around within one country or market, but there’s no great way to move money between systems. If every system backends to Bitcoin (or another cryptocurrency), suddenly the world starts to look a lot like this:

You could imagine the gateway ecosystem choosing a traditional financial system as their backend in place of Bitcoin. However, doing so would require each to navigate the regulatory and partnership landscape in two countries: their local country, which they likely understand well, and the country in which the backing system is based, which they likely do not. For example, if American ACH were the chosen backing system, an entrepreneur building an Australian direct debit gateway would need a relationship with both an Australian bank and an American one.

Bitcoin as the IP layer

One exciting consequence of having a network of gateways built on top of Bitcoin is that they’ll all be technology-driven companies in an open ecosystem. They’ll be willing to adopt new open protocols that deliver additional value. For example, you can imagine a protocol to make the web payment experience look like the following:

Namely, every entity on the internet could have a payment address that feels like an email address. To pay on a site, you would just provide your payment address. The merchant’s gateway would then request funds from yours, which you could authorize via a push notification to your phone.

In this way, Bitcoin would start to become the IP layer of payments. Just as users are used to human-readable hostnames (such as stripe.com) which resolve down to an IP address, this system would result in human-readable names (alice@cad-gateway.com) being what people know and remember. Behind the scenes, systems would still use Bitcoin addresses to speak to one another. (Mike Hearn has some ideas here.)

And in the end, we’d have a globally-connected network. It wouldn’t replace the existing financial systems—consumers would still be able to use all the infrastructure they use today. But it would make the existing system incredibly more valuable, in the same way that connecting everyone’s local networks via the internet multiplied the value of what was already there.

Contrast with other global networks

This would not, of course, be the first global payments network. One obvious comparison is with PayPal. The fundamental advantage a Bitcoin gateway ecosystem has over PayPal is that it’s open. Any closed network will, by nature, be deprived of structural pressures that force it to improve. A third-party can’t improve a closed network; if they really want to, they first have to try to replicate the network itself from scratch. In contrast, the Bitcoin space is already seeing rapid iteration and compounding improvements.

Swift is another global network. When sending money with Swift, one bank says to another “I’m going to send you 100 euros”, and then finds a path of peered banks to actually move the money. Fees and currency conversion are handled in an ad hoc (and often surprising) fashion. The more you can bake “what will happen” into the network protocol, the more understandable and usable the resulting system will be. Bitcoin does better than Swift by including money movement and transaction fees in the protocol, though it similarly lacks native currency conversion.

There are a number of cryptocurrencies which already have gateways baked in at a protocol level (such as Open Transactions and Ripple). However, there are huge network effects in any financial system, and to date these other systems have failed to win the necessary user support.

Comparison to the card networks

If we really want to make a Bitcoin-backed global network useful to consumers, it’s worth comparing it against a system that is already quite useful to them: namely, Visa. Visa has a number of functions, which can be roughly bucketed into three categories:

1. Network for initiating transactions and moving funds.
2. Setting rules and regulations.
3. Consumer trust and protection (chargebacks, stolen cards).

(Other functions such as consumer credit are provided by the banks rather than Visa itself.)

Of these, the Bitcoin gateway network described above provides 1 and the technical aspects of 2 (“this is how the protocol works” is covered, while “every online merchant needs a privacy policy” is not). But the other functions are very important. Ultimately, the message Visa delivers to consumers is that if they see the Visa logo, they are safe. If something goes wrong (such as the merchant delivering a bad product), the consumer will be made whole. This results in many transactions happening that otherwise would not, and makes the whole ecosystem more valuable.

And so, unless we solve decentralized reputation (which people are starting to think about), the Bitcoin ecosystem will see the emergence of a few centralized consumer “trust providers”.

You can already start to see the need for this with the emergence of Bitcoin escrow services. However, escrow isn’t actually a solution to trust—it’s a way not to trust. It makes sense only for a certain segment of purchases, and requires you to jump through stressful hoops like completing an inspection of the goods before irrevocably releasing the funds.

The winners in this space will instead be companies which inspire consumers to trust those they endorse. They’ll provide consumer protection services like chargeback mediation (and have a direct relationship with the merchant to actually recoup funds for those chargebacks). They’ll gain acceptance among Bitcoin-accepting merchants if they can boost sales:

Because the trust providers’ main assets are their brands, and those brands benefit from network effects, it’ll generally make sense for these companies to consolidate. Ultimately there will be one or a few major players, just like there are in the credit card world.

Other participants in the ecosystem will want to display the brand too. You’ll see gateways cobranding with the trust providers, just like today you see cards cobranded with Visa and their issuing bank.

As a result, the trust providers will be building a network of vetted merchants and gateways. To make sure only good actors are in the system, they’ll need to set and enforce rules and regulations for acceptable behavior—otherwise their brand will become less meaningful. This brings us back to a world of a few entities who get to set the rules.

Conclusion

So what would all of this buy us? There would be three major improvements to the existing financial system.

First, the resulting ecosystem is technologically open. Open ecosystems have a way of getting better much faster than their closed counterpart. Anyone can enter, connect to the network, and start building good tools and applications on top of it. The emerging regulatory landscape may change some of the constants, but this fundamental advantage will remain.

Second, this model unbundles the existing financial system into layers run by independent companies. To see the value of this, contrast with the US mobile carriers, who used to own the entire stack. They owned the handsets, the operating systems, the applications running on the phone, and the service. This meant that most of the stack never had anything pushing it to get very good, and there were even incentives to hold it back in order to preserve legacy revenue-generating facilities like SMS. By enabling competition at individual layers of the financial system, each one should improve.

And third, this would be the first truly global payments network: anyone would be empowered to start a gateway in their country, rather than relying on it eventually making sense for some centralized actor. This is especially powerful for people in countries with underdeveloped banking systems, which many traditional payment systems never reach.

So what role will Stripe play here? We already provide Bitcoin acceptance, and we’re actively investigating other functionality. We’ll have other updates on this front before too long.

We’re still in the very early days, but we can already start to see the shape of the potential impact of Bitcoin and other cryptocurrencies. If we get things right, life is going to be much better for billions of people.

We’ve heard from a lot you that you’d like to learn more about some of the trickier parts of working with the Stripe API. So, we’re hosting our first Stripe Office Hours.

In this session, we’ll be discussing and demoing some topics related specifically to changing subscriptions: working with trials, changing billing dates, and handling prorations.

Joining us are a few of our favorite users—Sunil Sadasivan (Buffer), Josh Pigford (Baremetrics), Rafik Salama (Oyster), and Joel Augé (Fan.si)–to share how they use subscriptions on Stripe along with a few tips they’ve picked up along the way.

We’ll be live on YouTube and also record it for later. If you have any questions about the topic or demo, just tweet with #stripeOH and we’ll answer them during the session.

Also, if you’ve got suggestions for future topics, I’d love to hear from you. Hope to see you there!

As we've grown Stripe, we've constantly lamented about how hard it is to get actionable advice on the specific issues we're dealing with. As an experiment, we've decided to try out a startup advice column to share what we've learned along the way.

For this first advice post, I'll respond to an email one of my (apparently prescient) friends recently sent me.

Hey Greg,

We're spinning up our recruitment engine and are working on our cold reach out email copy.

Do you have any examples of successful emails you've used in the past that you'd be willing to share or any advice on the process?

I've actually sent quite a lot of outbound cold emails and A/B tested until I found a formula that works for me. Cold outreach is inherently hard because the people you most want to reach will already receive many of these sollicitations, and you correspondingly need to differentiate. Here are the main lessons that I've taken away from my cold pings:

• Include a proof-of-work. Most cold emails are mechanically assembled: either they're totally copy-paste, or they substitute in strings (such as your language of choice) that could be pulled from the Github API. Instead, make sure your emails include something that proves you've done some work investigating the person and understanding them. Make an intelligent comment about one of their talks, or include a suggestion for one of their projects. (Unfortunately, this doesn't mean you should send people a crafted hash.)
• Don't explain what your company does. Either they've heard of you, in which case the explanation isn't very useful, or they haven't, in which case the explanation isn't going to read any different from the various other emails they get. It also makes you sound small-time: Google would never send someone an email saying "I work at Google, a search company in Mountain View which is organizing the world's information".
• Always have the ping come from a non-recruiter. There's actually nothing wrong with contacts from recruiters generally: good ones know how to make a candidate feel at ease. In the specific case of cold pings, you need to make sure that it comes from someone for whom that email isn't a normal part of their job. It's much better as a recipient to realize that someone has taken time out of their day just to contact you, rather than someone simply fulfilling their quota.
• Say the bare minimum required to get a face-to-face chat. No matter what great information you include in your email, any selling you do verbally (if they're local, get coffee; otherwise video chat tends to be way better than phone) will be astronomically more effective and convincing. So any non-vital detail can really only serve to shoot you in the foot.
• Track response rates. Ultimately these contacts are about personal style, and it's important to find something that works with you. I have a Hackpad I use to record every cold ping I sent, and go back and update it if I get a reply.

That's a lot of principle, but it compiles down to a very short email template. Here's a concrete example of one I've used in the past:

Hey XX,

I'm an engineer at Stripe. I came across your XX post, and it reminded me of the time that XX. I wanted to see if you'd be interested in working with us at Stripe — if you're up for it, I'd love to grab coffee next week to chat.

- gdb

Good luck with the recruiting. Let me know how it turns out!

Have something we can help with? Just send me an email at gdb@stripe.com with a concrete question you're facing at your company. It can be related to anything startup related (technical, managerial, etc). If there's enough demand, someone from Stripe will regularly (starting out with every two weeks) respond to a selected email with a post here.

Though we’re constantly working on ways to get you your money faster, many of you have asked for a way to keep things simple and to group transfers together. We thought that was a good idea, and so you can now choose to receive your funds in weekly or monthly batches:

Unless you switch your transfer schedule in your dashboard, you’ll continue to get daily transfers as usual. Our transfers documentation includes a bit more about how transfers work if you’re curious.

We hope these options help keep your accountant happy. As ever, we’d love to hear your feedback—please get in touch!

A month ago, we announced our Open-Source Retreat, where we'll be giving grants to a few open-source developers to work on their projects full-time. We were hoping to find projects where our grant could make a large difference: rapidly-growing projects where the maintainer can't currently find the time to give it the attention it needs, risky ideas that have a lot of upside but need support to be tried at all, and the like.

We received about 120 applications in total. Since we only had a few slots (we in fact were originally going to do two, but we had so much trouble choosing we ended up creating another slot), there were a large number of really awesome projects we had to turn away. Our main consolation is the number of declined applicants who responded saying the retreat had renewed their enthusiasm for their project.

The grantees we chose are the following:

• A clean-room implementation of TLS v1.2 by Ashwini Oruganti (an especially timely project given recent events). It's an ambituous undertaking, but she's narrowing scope by focusing on designing and implementing a "TLS API for humans" and building on top of existing lower level primitives. The project will be written as part of Python's cryptography library.
• An improved dependency resolver with automatic conflict resolution for CocoaPods, written as a standalone library to be shared with Bundler, by Samuel Giddins. Samuel's plan is also to produce a language-agnostic acceptance test, which should help guide future package manager and dependency resolver implementations.
• Two libraries for "Minority Report-style UIs" in HTML5 by Julian Shapiro. Julian is trying to give web animation the workflow and performance boosts it needs to be a realistic platform for the UIs of the future (e.g. Oculus Rift, wearables). He's designed three libraries for this, and already implemented one of them (Velocity.js, which has attracted a great deal of attention since its launch three weeks ago).

We're treating this iteration of the retreat as an experiment, but the overwhelming response we saw makes it likely we'll do something like it again. In any case, we expect we'll learn a lot from this run and hopefully have lessons to share back with the community.

Lastly, we've heard from a number of other companies that they're interested in running similar programs (which we wholeheartedly encourage!), so hopefully there will be other opportunities like this soon. Please get in touch if you have any questions about our retreat, running your own, have feedback for us, or just want to chat.

Stripe Engineers (and former Cambridge residents) Nelson, Steve, Kiran, and Andy will be visiting Cambridge this week; Come hang out with us and let us buy you a beer and chat about Stripe.

We'll be at John Harvard's in Harvard Square this Thursday night, and we'd love to see you there.

RSVP via our event page.