Sure, but other companies, e.g., Spreedly, let you outsource PCI compliance as well. This is the first I've seen that let's you get away without having a merchant account.
Braintree also acts as your merchant account though, right?
I'm really excited to learn more about Stripe, but I have Braintree implemented in one application and have had a good experience. For future apps, why choose Stripe over Braintree?
Yeah, I was referred to Braintree when I was building http://limelightapp.com/ and I really liked them. However, using them required getting a merchant account, and getting a merchant account required getting a business license, and getting a business license cost $60 and a few hours going on a trip to City Hall and the Court House. Once I had that, Braintree still had to take a couple days to get the underwriting approved for my merchant account. To their credit, the crazy thing is that this is actually an awesome experience compared to working with other payment gateways.
If I could have, I definitely would have done this instead. This is like Square for web apps.
Definitely agree. Braintree is by far the best of a very, very bad lot of merchant account providers. Try getting an account with Authorize.net...I nearly killed myself when I tried that. Braintree was a breath of fresh air after I went the 'traditional' way.
But, even then...as you said, I still had to jump through tons of hoops and even though they were very, very helpful and super attentive - they even bent over backwards for me by going to multiple underwriting banks to increase the likelihood that my business would be underwritten. When one of the banks rejected my application, their decision to go to multiple ones definitely seemed prescient.
But even then, the entire process still took at least a week - with LOTS of paperwork back and forth being printed out, scanned, emailed, etc.
Little did I know...I didn't NEED a merchant account. I just want to accept credit cards securely and not be gauged by the fees.
Stripe does both perfectly...the fees are pretty competitive - no monthly and no merchant account headache.
Avoid it if you can, at all costs, and just go straight to Stripe.
Stripe pretty much takes payment processing kicking and screaming into 2011. Merchant accounts are a serious drag. I've opened a few and they've been nothing but headaches (especially if you're young—nobody trusts you.) Couple that with getting a gateway account, dealing with credit checks, monthly fees, monthly minimums, slow people in the payments industry, PCI compliance...
Stripe takes payments and put them behind a simple API. No crappiness and 1099 rules of PayPal. No more reconsidering the meaning of life like back when I had a merchant account. The only downside I see is the 7-day rolling batch (deposit to bank), versus the nightly batch from the merchant account, though I assume that is for fraud protection.
Maybe if you're charging millions of dollars, you should use a regular merchant account. If you aren't, I'm telling you now: don't even bother with a merchant account. Just use Stripe.
I'm a college student, and pay cash for nearly everything, so I have very little credit history. After trying 3 or 4 merchants earlier this year, I still couldn't find one that would accept me, even with my father co-signing. Stripe is good news for young businesses.
Get a credit card and start using it -- paying it off 100% every month. I was in your shoes only a few years ago and it is worth starting to build your good credit early on. Even if you can only get a $300 limit.
Variation: you can get a secured credit card. Give them money, and that's your limit. But it's a credit card nonetheless. After some period of time, you get the money back, and a better card. Talk to your bank.
When I set mine up I didn't have any of the problems you describe. I had a business checking account with my local bank, and got set up with usaepay. Now, of course there is verification of who you are and what kind of business you run, but it was hardly a "hassle". I was only 26 and had no previous business "history" or anything like that, heck I'm set up as a sole proprietor. I don't have a monthly statement fee, no minimums. I pay a very low rate... so low that I'm dumb founded by half the rates I see ADVERTISED as low.
Anyway, just thought I'd offer a good experience to the mix.
> Maybe if you're charging millions of dollars, you should use a regular merchant account.
You should probably still use Stripe in this case. (Some people already are.) We scale up pretty well. Everything that you get with a merchant account (correct statement text, money held in your name), you get with Stripe.
Additionally, there are some advantages for large businesses that would make Stripe more attractive than a merchant account: transfer reporting and detailed reconciliation tools make a big difference to people doing high throughput.
How do you handle situations in which you can't tell if someone is legitimately undergoing hyper-growth or committing fraud? In a prior startup, I had my funds held indefinitely by PayPal and 3 separate merchant banks because our rapid growth made them suspect us of fraud or perhaps that our business was just too risky because our numbers were changing so rapidly. Our ultimate solution was to engage a merchant bank that specialized in sight-unseen, no swipe/no sig transactions that we could meet with face-to-face.
There's no simple thing I can say here. There are situations where withholding funds might be required, but they should be exceedingly rare. In other words, we're hoping to eliminate false positives.
In general, we're a tech company and we're looking for technical solutions to problems. We're also just culturally familiar with startups that explode in popularity, so we aren't worried about that kind of behavior.
You may want to seriously consider working on fleshing out this plan now. Paypal supposedly has thousands of people working in fraud control.
When word gets out that Stripe makes it "dead simple" to process credit cards without a merchant account, the vampires will come out to play. And I'm truly excited for a service like yours. We need this. But be prepared.
PayPal isn't just a payments processor, so they have many more fraud scenarios to worry about than Stripe.
You can't use Stripe unless you have a bank account set up to receive funds, and you can't use Stripe to pay for things -- i.e., you can't launder fraudulent money by buying a ton of stuff online and having it shipped to an abandoned house.
In Stripe there's a very simple money trail, plus there's a week's delay before your charges are transferred into your account... which makes it tricky if you're hoping to run up lots of fraudulent charges then disappear with the cash before anyone notices. With PayPal the money trail could be very complicated indeed.
If you're laundering money, you might want to consider in-house legal expertise, as well as in-house payments processing expertise.
If you're not laundering money, then (all other things being the same), you should prefer Stripe over PayPal, since it would be quite hard for someone to use Stripe for this purpose, hence they will have fewer money-launderers to deal with, hence you have less risk that you'll set off some obscure alarm and they'll lock up your account for months.
In any case, if you sell anything (online or off) you may want to learn a bit about the various risks and liabilities. Fraud does happen, and some businesses are at far higher risk.
I'm not sure the average lawyer will help much, though. They can tell you "yup, if someone buys a diamond from you with a stolen credit card and you ship it, you will not get to keep that money even if the diamond isn't recovered" (but don't you know that already?).
The more important advice is technical, and it's about all of the things you can do to reduce the risk of that ever happening to you.
If you are looking for a technical solution you might want to check out..ahem... my company ThreatMetrix.
As ex paypal Im guessing you have invested a lot in risk management, ML and automation etc as its really technically difficult to make such a broken process like online payments this simple so you may have it all covered.
What we can bring to the table is a (300ms) https name value pair API that delivers aggregated intelligence in real-time based on transactions, identities, devices and behavior across 6000 sites that represent over 1MM individual CNP txns on a daily basis (only 1/5 of Paypals txns but hey we are a startup!) which you can ingest into your rules engine or risk models during, before or after the payments authorization/capture.
We dont just provide a score which can be impossible to integrate with other ML engines we also provide customizable (by you) reason codes/triggers that can be used to characterize behavior e.g. customer's computer associated with 3 difference identities and 4 different proxy ip addresses across global network in last hour....Data Geeks geek out on it as we also provide full attribute data back in the API response so provides a good way to do feature extractions for SVMs etc. We have been proven to reduce FP and increase TP.
We currently process peak 700 tps with about 20% degradation in performance at load. We suck at batch processing cause its just not our thing. I head up products and one of the founders so not selling just helping as I think you have a solid offering that should do very well.
Paypal bought Fraud Sciences for 170M but you can rent ThreatMetrix ;-)
Seriously, I really need to know something about this. It's driving me mad to keep seeing promising payment services only to find out they won't deal with me.
One major barrier is that in many countries it's difficult to set up a service like this in a way that doesn't require it to be a bona-fide "bank", and setting up a bona-fide bank is often not low-overhead.
As you can see if you want to provide this service to a foreigner then you need to do checks on this person and his bank. This costs such much that most will decide that it is not cost effective to do so.
Presumably they will set up a company in Europe instead of handling it from the US company, but this takes extra time and effort so most companies start in the US (and empirically they stay that way until they become very big).
Most merchant acquirers, as well as the US Government, will interpret sections 312 and 326 of the US Patriot Act to require a Social Security Number to positively identify a merchant application and to check the applicant against various financial crimes and terrorist lists. This essentially prohibits non-US companies. There are some exceptions, but this is generally the rule.
Many of the card acceptance solutions that do not require this information are not actually issuing merchant accounts or are otherwise performing what is known as aggregration or is opening a merchant account on your behalf that they own. Some are also issuing merchant accounts in non-US banks. Others are in violation of US law.
So Stripe is in fact opening a merchant account fir each user that signs up?
I am curious that a social security number is all that is required...why is it such a pain to get a merchant account with a bank or other acquirer? I am curious how Stripe can make it so simple.
There are two big reasons as to why it's so painful elsewhere. One is underwriting: people want to know a lot about your business so they can figure out if you're likely to be fraudulent (or expensively incompetent). They typically do this by taking a shotgun approach to information requirements.
The second reason is that it's "standard", and everybody copies the "standard" without much consideration. The companies providing merchant accounts are usually not technology companies, and historically haven't had thought much about product.
We like to think that we can do much better than traditional companies on both counts.
I am curious as I am in fact an Australian citizen and know that a lot of people have a hard time here when trying to open a merchant account. From what I've read and heard it's traditionally a similar in the US and it is obviously one of the killer features of Stripe.
Was it hard for you to work with a bank (Wells Fargo) on this? From what I've heard banks are the main driver behind the 'shotgun' approach to information collection, at least here in Australia. I could well be wrong on this, hence I ask the question.
You are already doing a much better job than traditional companies on both accounts, it's great to watch and I'm sure you guys will continue to do great work.
Note: I just realised my spelling error in my previous post...iPhone autocorrect got the better of me!a
We scale up pretty well. Everything that you get with a merchant account (correct statement text, money held in your name), you get with Stripe.
Key scaling issue is pricing. 2.9% is fine for low volumes and no risk validation, but once you're turning over large volumes and have a track record of no chargebacks etc the comparison looks much worse. If you can offer businesses a pricing that 'scales' with substantial reductions in transaction fee by volume then there is a growth path, otherwise any business would be crazy to stick with you no matter how good your service and APIs, etc because 2.9% could be half their gross margin and they can get 1% by dealing with the bank direct.
I really like your idea of "pricing that scales." However, I feel the need to point out that no one can get a 1% rate on eCommerce transactions from their bank or anyone else. Interchange rates (cost) from Visa and MasterCard range from 1.71% + $.15 all the way up to 3.06% + $.10. Having said that, you're right about larger businesses finding Stripe's rates unpalatable. Maybe they're just trying to become the Square of eCommerce - which might not be a bad idea.
However, I feel the need to point out that no one can get a 1% rate on eCommerce transactions from their bank or anyone else.
I didn't mention 1% as idle guesswork, I have direct knowledge of several businesses paying close to 1% on online (card not present, no signature) transactions. I'm not saying its easy to negotiate good rates, but its possible, even for fairly early stage startups. I got 1.6% for a startup turning over only about $20k per month, no track record and 'non standard' business model.
So feel free to push your bank, get quotes from their competitors, they can almost certainly do better for you.
EDIT: I just notice that stripe is planning to introduce volume discounts - that would make a very nice product!
I'm not sure how to say this politely, but I think that you are mistaken. Perhaps you are not including some relatively high monthly fees? Perhaps you are not accepting all major cards? Maybe you are including a large percentage of debit cards? Maybe all your transactions qualify for some particular promotional rate?
I do about that volume, mostly card present, and think I have decent rates. I think I'm at Interchange plus .2% plus 1 cent per transaction plus $20 per month, and end up around 2.7% for total fees. I'm sure one can do better, but not by a lot. I'm willing to bet a considerable sum that you are not actually paying 1.6 percent once it's all added up. But if somehow you are, the loss of the bet would pay back quickly if I could get those rates myself!
Too hard or not - it's a critical feature. They can lure me with the most advanced APIs and super low fees. If they can't treat international customers (on the consumer side at least) like domestic ones then it's a deal breaker.
There are enough alternatives that have support for things like the Euro. They maybe don't have a fancy API but they work well enough and I can accept credit card payments from Uzbekistan in their local currency.
Then there's the part where they only accept US developers. While I can understand that again there's enough alternatives (FastSpring for example) who don't mistrust me because I'm living in the EU and will do payment processing for me.
I understand they wanted to launch ASAP with a MVP but maybe they cut down the wrong features. For me they are now another lazy payment processor who won't accept international customers and they will have to do some work to get rid of that stigma.
It would be great as a starting point to be able to charge in currency other than USD, I suppose that should be easier to set-up than accepting non-US based merchants. There are a lot of non-US people like me that have a SSN and US bank account from past US experiences that can already use Stripe in their home countries. But marketing a product in Italy with a price in USD won't cut it!
I would have to agree; a plethora of headaches are to be expected when dealing with merchant accounts. Monthly fees coupled with compliance issues and constant intervention make for extra work. Relying on merchants is like relying on your local broker. Nonetheless, certain merchant accounts will allow you to escape with fees almost a full point less than Stripe. Not to mention, the 7-day rolling period can seriously impact operations pending your specific business structure. I for one am curious to learn more about how Stripe can customize payment flows...
Well... yes and no. It's great to see more payment options. But segregated merchant accounts are there for a reason, pretty much every company that is in the payment processing world that does not use segregated merchant accounts sooner or later goes bust. See DMR and ibill for some nice examples of what happens when you multiplex a merchant account across more than one customer.
By making sure everybody has their own merchant account you may not make as much money on the transactions but you stay in business long term. And if there is one thing that really sucks it is to have to start all over again because your payment processor goes under, taking all your customers with it.
Stuff like that can kill you. If your transaction volume is serious enough to warrant your own merchant account then you should probably get one.
Stripe is a game changer. I've been using it for a few months and honestly its the best API I've ever used. The documentation is clear and concise. Its customized to your account so you can literally copy and paste and see the result. Just like it says, it gets out of your way. I was up and running and accepting recurring payments in less than an hour or so. I actually began to think of larger "swing for the fence" type of ideas that I would have never considered if I were stuck to using Paypal because it was so painless. Looking forward to them eating every other payment processor's lunch.
It's so funny, how APIs are supposed to be written by developers for developers - but you don't realize how crappy most are until you come across a good one.
The first time that happened to me, was when I wanted to run my first test transaction at the command-line, and Stripe had generated the customized console commands for my specific app (with my specific API keys, etc.) and literally allowed me to copy and paste from their secure site to my command-line without having to do any thinking.
That was my first 'aha! OMG...this API is awesome' moment. There were many others, and the truth is I forgot until you mentioned it.
Now that you mentioned it, it reminded me how blindingly simple that is to implement - but SOOO many developers (I am guilty as charged too) overlook those little details that make SUCH a difference.
Not only that but their docs include sample responses. I'm amazed at how many folks document their APIs but leave out this simple step. It can be a huge help when shopping around between providers, both just to see the quality of their docs, but also to see if their API does what I need. Since I usually have some pseudo code in my head already, being able to see sample responses and see how they fit with my code or schema, etc can make the difference between your API product and a competitor.
Anyone know whether they used a documentation tool to generate the 'example on right' style pages? E.g. https://stripe.com/api/docs?lang=python#delete_customer. It's very clean. The general layout and feel of the API doco is great.
I really don't get or see how Stripe is different?
Why would I use it instead of PayPal, 2CheckOut, e-junkie, etc?
As a seller of software myself (http://www.devside.net/server/webdeveloper), I can tell you that "API is cleaner" and "lower fees than 2CO" don't do anything for me at all.
Huh. If you don't care about bad APIs or high fees, what do you care about? You don't give any clues.
I sell software and subscriptions online; I'm working on the switch over the Stripe because I really appreciated their cleaner API and low fees.
I've been using PayPal because it's cheap and easy, but they screw up many foreign payments (that have worked fine when run through Stripe), the whole "eCheck" thing confuses the hell out of people, and that whole "no, you don't have to create a PayPal account" thing. It's just unprofessional.
I can set up Stripe to handle processing for me completely transparently, and still without passing credit card data through my servers.
My point is that to switch from PayPal and 2CO (which is what I use now + as is working just fine for me) I need more benefits then..
1) Getting to set up and manage another new account.
2) The pleasure of getting to rewrite (and test + debug) my backend payment process.
3) Getting a slightly cleaner API (that I'm never going to see after I implement it).
4) Saving an extra dollar on every transaction (of a $125 sale).
5) Working with a relatively new, and in that effect, inexperienced payment processor.
1 and 2 are not benefits to me at all.
3 and 4 I don't care about because they are marginal at best.
5 is a killer.
So why would I use Stripe?
> I can set up Stripe to handle processing for me completely transparently, and still without passing credit card data through my servers.
Same as it is now.
> I've been using PayPal because it's cheap and easy, but they screw up many foreign payments (that have worked fine when run through Stripe), the whole "eCheck" thing confuses the hell out of people, and that whole "no, you don't have to create a PayPal account" thing. It's just unprofessional.
Without experience, Stripe will screw up even more. If not on this part, then definitely on other parts. It's just the way it works.
Nothing differentiates Stripe for me from the rest of the bunch and I'm not going to fall over backwards putting in more work to switch to Stripe just because someone says the API is cleaner.
Though it's hard to tell if this is just part of the sarcasm, or a legitimate concern, let me clear it up: you can sell things anywhere in the world with Stripe, you simply need to sell them from a US business entity.
Been a beta user for a while, and I love their Ruby API. I used to use Braintree...while they were a good merchant account provider - it was overkill for what I needed.
I much prefer only paying when I make money. I don't NEED a merchant account. I just need to be able to collect money from my customers in an automated way. Stripe makes that relatively easy.
Their API has a quick feedback loop, where you can execute a transaction from the command-line very quickly (for Ruby anyway...I imagine it would be the same for other languages).
Their support is also awesome - could be because they only had beta users. But either way, awesome service so far and much better to deal with than a 'traditional' payment solution for those webappers out there (in my experience).
Not affiliated with the company in anyway, other than a customer.
I've held off developing / launching a few small biz ideas because of the state of payment providers in the UK - ready and waiting to help you test when you're over here :)
I concur entirely (and have spoken with my MP about it).
However, as far as I can tell, anyone using any of the more established "big name" billing services to collect payments for a UK company is almost certainly breaking at least one law on a "your business is at risk" scale. Stripe would have to be very special to do better.
The usual culprits are VAT (I have yet to find a billing service that would actually allow a UK business to comply with its basic statutory requirements on this count, including several that claim to support VAT) and privacy (exporting personal data, such as names and credit card details, outside of Europe requires certain guarantees, which again I don't think would be met by any of the services I've looked into so far). I imagine quite a few businesses are getting away with using these services and not meeting their obligations, but personally I wouldn't want to operate with that sort of risk, particularly now Business Record Checks are becoming big news.
Stripe does seem to have a fairly clean API, but on the flip side, it also seems very limited in features next to some of the more established competition, so maybe it's just horses for courses. Again, I know that none of the other billing services we've considered this year even got close to supporting the basic charging model we wanted, never mind all the bells and whistles we've been considering, and if you wind up having to do a bunch of financial legwork yourself, these services start to look like very poor value for money pretty quickly.
IMHO, what small businesses in the UK really need is for the government to stop hassling banks about lending lots of money (sometimes useful, but not to many of us) and just get them to provide basic services like card payments in a sane manner: no multi-month waits to get up and running, directly comparable charging structures on some standard basis, transparent migration of customer card data between all the vault services without causing a PCI nightmare so there is genuine competition in the market, and so on.
I don't see the problem with VAT. Just keep rack of where your customers are and pay the VAT on those in Europe. Where does the payment processor come into it? If you owe VAT then pay it.
It is not as simple as that, at least in the UK, and the fact that so many payment services seem to think it is explains why any UK business relying on them for payment processing is probably breaking the law.
There are all kinds of rules on disclosure of VAT registration details on invoices, sequential numbering of VAT invoices (across an entire company) for audit purposes, etc. Any payment system that doesn't integrate with other company procedures to meet these basic statutory obligations can't be sufficient.
I have an online business selling globally operating out of the EU and I now know more about VAT than I care too. I agree that the rules can get quite complex but as far as I can tell the payment processor does not need to be able to do anything special other than the ability to store/display the required information with each transaction (date, sequential invoice number, and VAT number in the case of a B2B transaction). You can just put that in a free format field (in PayPal for example), that's all they would need to add I think.
Sure it would be nice if they stored tax (multiple rates possible on one invoice!) and VAT numbers in a separate field, it would be even nicer if they validated the VAT numbers for you, or the buyers location, but it can all be done outside the payment processor.
Indeed, but you do need to be able to store and display that information in the right places.
As you say, technically invoices are supposed to record the VAT against each line item, because the rates can be different for different types of product/service.
Regarding the serialised invoice numbers, if you as the merchant are having to keep track of such things then you're still doing some of the tedious work so the value of outsourcing the billing process is lessened. I agree that it might be viable to record the extra information in a separate field for one-off transactions, if the billing service allows that kind of annotation on transactions and your systems can generate the appropriate number taking into account any other sales channels you're also using.
Even then, for subscription services that renew automatically, there would need to be some robust mechanism for the billing service to "claim" the next invoice number when they collect a scheduled payment. Perhaps some of these services could cope with this, but I have yet to see one personally whose documentation explains how to set it up using their APIs and callbacks. And if you get to the point where you have to handle scheduling regular subscription payments on your in-house system to account for this, again you're defeating the point of outsourcing the billing in the first place.
IME, it doesn't take long before you have to do so much in-house anyway that you might as well do the lot and save yourself a signficant overhead and the additional risk/dependency of involving another organisation in your billing process. This sort of processing is tedious but not rocket science, so if you can't just wrap everything up and shove it out to a specialist service, avoiding having to go near that sort of stuff in-house at all, I just don't see how the cost/benefit of these services is going to make them attractive to a business here in the UK. YMMV, of course.
Agreed, there are no services offering recurring payments (in Europe anyway) that do the whole thing, and I would love to outsource more if I could since billing is a nuisance that just detracts so much from the actual business. We currently use PayPal but that doesn't even allow you to pro-rate subscriptions when up- or downgrading. I noticed in the API docs that stripe.com at least has that one covered already.
In Patrick Collison's presentation at Startup Bootcamp last weekend, he really brought home the social impact that a payment processing company can have in the third world. Even though it's US only for now, this team has huge goals and the experience and vision to back it up.
Their goal is to abstract away the complexity of payments, especially internationally. I wish them luck, and can't wait to use it.
We're working on international support right now -- though we don't have an ETA, launching in the US was definitely the first part of getting there (and we care a lot about going international -- about half our team is from other countries).
You don't need to make your own merchant account or payment gateway because we abstract over those details. We'll make whatever accounts are necessary and
we work directly with the banks to make sure that your money is held in your name, what you want appears on your customers' credit card statements, etc.
Is there any chance you guys could set up a mailing list for people to be notified when there is more international support? Merchant services in Australia suck.
Amazing product. We're building an eCommerce platform (http://www.kout.me) and have been building our payments on top of stripe.
Very amazing concept and something that we've needed for a long time. The best thing is the developer focus behind it; it's clear from the beginning that this came to fruition with fellow developers in mind.
This looks really, really nice. Support for Canada would be wonderful and pretty much essential for me to be able to use it. The other thing I'm wondering about is ACH payments - will Stripe handle those; if not, is it planned? Also, would Stripe be suitable for a card-holder present situation, e.g. if you wanted to use it for web-based point of sale software?
Heh, indeed it is. This is part of a web framework we're using right now that lets us push code updates to the page, but it just appends content. We're reworking how a lot of this works right now.
This is an amazing service. I've been researching all of this for a project I am advising on. Merchant Accounts, gateways, fee here,fee there, PCI - it can make your head explode.
It looks like these guys have done it right, and finally hidden the layers friction, banking (and open palms) for us.
Nice Work!
One Nit if anyone from Stripe is reading - it was a bit hard to find the answer to "How & When do I get paid". There is a small blurp on the pricing page (still doesn't say how), but nothing in the FAQ or Docs. Please spell this out a bit more.
There are probably better specifics in the TOS or elsewhere, I guess I was looking for something spelled out better in the docs. (Ex: "Use any standard US Business or Personal checking account")
Having looked into a lot of payment services recently, including scanning Stripe's terms at the link above, I'm genuinely curious about something.
What kind of management trusts a new start-up with such a fundamental part of their business, inevitably including a certain amount of opportunity cost and risk of delay if moving to another service is necessary, based only on a contract of adhesion that allows for the service to be terminated at any time with negligible notice and without any sort of compensation or guaranteed handover arrangements?
I've been watching Stripe for a future project that is looking more and more likely ... but this looks so good, I might do the project just to have a reason to use Stripe! (j/k)
Can't wait to see how the international version works.
Been playing with the API as a beta tester and the docs truly were written by devs. Clean, concise, and gets straight to the point, and they have example code in multiple languages. Plus some really awesome customer support - overall Stripe really rocks.
Sounds nice, but the bottom line for me is that a typical $47 credit card sale, which always costs me $1.33 at PayPal, would cost me $1.66 at Stripe. Not much difference, true, but discouraging. I have no need of a fancy API, either--PayPal lets me specify the basics and fire off a simple Post from my PHP code. PayPal takes care of receiving financial information so I remain clean. Just my experience; yours may vary.
That's much how I feel as well. I accept credit cards and PayPal, and pay 2.2% as well. Stripe gets added to the bookmark collection for "services to use should I ever have a problem with PayPal" (which, knock on wood, won't ever happen -- my account is 11 years old now).
Wow. Excited. After watching PintPay toy with my emotions, I'm glad someone did it up right. I hope they've got a viable model. The market is positively starving for something like this.
As regards merchant accounts - what country & typical size/age of business do you tend to work with? Appreciate you've not posted anonymously so might not want to go into things much.
US/Canada, startups and non-startups. 2/3rds of our businesses are online (mostly startups), 1/3rd brick and mortar. I don't have a better breakdown than that at my fingertips.
Average size of our customer is fairly large, skewed by several large customers. We have a lot of startup customers. The ones that are a challenge to get underwritten are typically marketplace businesses of some kind (you sell something, a third party gets paid for it and you take your cut). We have a bunch of them as customers but some are a challenge to get underwritten (fraud reasons/banks are stupid about it).
We are totally upfront and transparent and never post anonymously btw. Our business name is actually Transparent Financial Services!
Do you do recurring billing? It's not clear with a quick view of the documentation. Or do you expect that individuals are provided sufficient information to build their own (easy?) recurring systems? If you do, we'll look at moving immediately. We'd not only be saving money but your API doesn't confuse the hell out of my like what we're currently using.
You got it. We don't handle the recurring stuff for you, but
we give you back a token that lets you bill your customer cards on a recurring basis. We have other customers who are doing this on their own.
We do give you basic information, like whether or not the CVC code and billing address match the credit card. We'll consider adding more information over time.
Interesting. Is there an end-to-end demo from the user's perspective? Do the users know they are storing the CC info on Stripe? Or they think my site handles everything and is responsible for everything (privacy, etc)?
We are completely transparent to your users - it's a conscious design choice. You can always choose to tell them about Stripe and link to our security page if it makes sense. https://stripe.com/security
I'm guessing that the target audience is solo developers that don't qualify for the volume discounts that every other payments vendor/gateway offers.
As lovely as this API looks, not offering a volume discount is a complete dealbreaker for my business. There's no way I could justify eating an extra ~1% per transaction just so my API integration goes more smoothly and I don't have to deal with the headaches of a merchant account (and while I would call that process anything but smooth, I don't seem to have the awful experiences of some of the commenters here -- just chance, I guess).
The cost/benefit to a business that does any significant volume online just isn't there for this.
Volume pricing is something we'll think about in the future, but you're right -- right now we're trying to focus on building the simplest possible payments system on the web, even at the expense of maybe being less attractive to the biggest merchants for a while.
I'm comparing payment processing options for a very straightforward SaaS app. I was heavily leaning toward Braintree, but Stripe and Samurai seem easier/cheaper. Is there a strong reason to go with Braintree? I'm not sure if having my own merchant account makes a big difference.
The pricing for 1,000 monthly users looks (roughly) like:
We work directly with Wells Fargo on our backend to make sure you end up with all the normal benefits of a merchant account (the money will be held in your name, you will be able to put whatever you want on your customers' credit card statements, etc.). We just want to abstract the whole process here -- basically, putting you on the account or accounts that makes the most amount of sense so you can start processing immediately and then continue processing at high volume.
Their signup process threw me for a loop. You just click into the dashboard, then fill in a name and password later. It looks like just visiting the front page gives you an account, because the sample code is already using some generated API tokens.
I've considered doing something similar for my own side project, but went with the more standard sign up because I was worried it would be confusing (as it was to me, for a few minutes). Do you guys think this is becoming more mainstream, at least amongst developers and the tech-savvy, that other projects could get away with this? I'm curious how many support requests Stripe gets because of this.
Edited to add: How does this work for the non-logged-in state? I already have an account, and the browser cookie expires (or manually delete the cookies). I'll go to the dashboard, and be logged in as "anonymous", and have to sign out and sign in again as the right user. Seems like an extra incongruous step.
Yeah, it does sometimes confuse people. This is something we're considering about changing (the flow worked differently when we were invite only), but we thought it was worth experimenting with a little longer.
Mostly, I think it depends on the type of app you have. For something like 280 Slides (a previous project I worked on), it makes a lot of sense to get started right away without having to sign up. We'll see how things go for Stripe.
Agreed. I figured out that setting my username and password and clicking saved seemed to work. Even if I'm not going to add all my info now, I like creating my account to come back to. It felt like I could do everything but that.
368 comments
[ 3.0 ms ] story [ 263 ms ] threadThat's a killer feature right there. I've been considering using Braintree for a project, but seeing this is really making me reconsider.
I'm really excited to learn more about Stripe, but I have Braintree implemented in one application and have had a good experience. For future apps, why choose Stripe over Braintree?
Shoot to hear you're having trouble sorting it out. Please feel free to reach out to Erin@braintreepayments.com . She'll help you out.
If I could have, I definitely would have done this instead. This is like Square for web apps.
But, even then...as you said, I still had to jump through tons of hoops and even though they were very, very helpful and super attentive - they even bent over backwards for me by going to multiple underwriting banks to increase the likelihood that my business would be underwritten. When one of the banks rejected my application, their decision to go to multiple ones definitely seemed prescient.
But even then, the entire process still took at least a week - with LOTS of paperwork back and forth being printed out, scanned, emailed, etc.
Little did I know...I didn't NEED a merchant account. I just want to accept credit cards securely and not be gauged by the fees.
Stripe does both perfectly...the fees are pretty competitive - no monthly and no merchant account headache.
Avoid it if you can, at all costs, and just go straight to Stripe.
Stripe takes payments and put them behind a simple API. No crappiness and 1099 rules of PayPal. No more reconsidering the meaning of life like back when I had a merchant account. The only downside I see is the 7-day rolling batch (deposit to bank), versus the nightly batch from the merchant account, though I assume that is for fraud protection.
Maybe if you're charging millions of dollars, you should use a regular merchant account. If you aren't, I'm telling you now: don't even bother with a merchant account. Just use Stripe.
Ah, things must have changed from early 2000s. I had no problems getting (pretty high risk) merchant accounts back in high school.
That said, Stripe looks pretty cool. No more authorize.net mess=)
Anyway, just thought I'd offer a good experience to the mix.
You should probably still use Stripe in this case. (Some people already are.) We scale up pretty well. Everything that you get with a merchant account (correct statement text, money held in your name), you get with Stripe.
Additionally, there are some advantages for large businesses that would make Stripe more attractive than a merchant account: transfer reporting and detailed reconciliation tools make a big difference to people doing high throughput.
In general, we're a tech company and we're looking for technical solutions to problems. We're also just culturally familiar with startups that explode in popularity, so we aren't worried about that kind of behavior.
When word gets out that Stripe makes it "dead simple" to process credit cards without a merchant account, the vampires will come out to play. And I'm truly excited for a service like yours. We need this. But be prepared.
You can't use Stripe unless you have a bank account set up to receive funds, and you can't use Stripe to pay for things -- i.e., you can't launder fraudulent money by buying a ton of stuff online and having it shipped to an abandoned house.
In Stripe there's a very simple money trail, plus there's a week's delay before your charges are transferred into your account... which makes it tricky if you're hoping to run up lots of fraudulent charges then disappear with the cash before anyone notices. With PayPal the money trail could be very complicated indeed.
If you're not laundering money, then (all other things being the same), you should prefer Stripe over PayPal, since it would be quite hard for someone to use Stripe for this purpose, hence they will have fewer money-launderers to deal with, hence you have less risk that you'll set off some obscure alarm and they'll lock up your account for months.
In any case, if you sell anything (online or off) you may want to learn a bit about the various risks and liabilities. Fraud does happen, and some businesses are at far higher risk.
I'm not sure the average lawyer will help much, though. They can tell you "yup, if someone buys a diamond from you with a stolen credit card and you ship it, you will not get to keep that money even if the diamond isn't recovered" (but don't you know that already?).
The more important advice is technical, and it's about all of the things you can do to reduce the risk of that ever happening to you.
As ex paypal Im guessing you have invested a lot in risk management, ML and automation etc as its really technically difficult to make such a broken process like online payments this simple so you may have it all covered.
What we can bring to the table is a (300ms) https name value pair API that delivers aggregated intelligence in real-time based on transactions, identities, devices and behavior across 6000 sites that represent over 1MM individual CNP txns on a daily basis (only 1/5 of Paypals txns but hey we are a startup!) which you can ingest into your rules engine or risk models during, before or after the payments authorization/capture.
We dont just provide a score which can be impossible to integrate with other ML engines we also provide customizable (by you) reason codes/triggers that can be used to characterize behavior e.g. customer's computer associated with 3 difference identities and 4 different proxy ip addresses across global network in last hour....Data Geeks geek out on it as we also provide full attribute data back in the API response so provides a good way to do feature extractions for SVMs etc. We have been proven to reduce FP and increase TP.
We currently process peak 700 tps with about 20% degradation in performance at load. We suck at batch processing cause its just not our thing. I head up products and one of the founders so not selling just helping as I think you have a solid offering that should do very well.
Paypal bought Fraud Sciences for 170M but you can rent ThreatMetrix ;-)
(I have no idea whether you have a good product, but I'm hoping you do, because the problem you're trying to solve is an annoying one.)
Would you finally be the one to tell us what the hell is the problem with non-US customers?
Yours is the most compelling one I've seen.
As you can see if you want to provide this service to a foreigner then you need to do checks on this person and his bank. This costs such much that most will decide that it is not cost effective to do so.
Well, why do their representatives insist it's a "top priority" then?
FastSpring, which is a US company, can actually work with non-US companies just fine. Why is that?
Also, at some point I asked them why they could, and BrainTree couldn't, and they said they can't really think of a reason why.
So.. What exactly is the deal? I'm dying to know.
Many of the card acceptance solutions that do not require this information are not actually issuing merchant accounts or are otherwise performing what is known as aggregration or is opening a merchant account on your behalf that they own. Some are also issuing merchant accounts in non-US banks. Others are in violation of US law.
I am curious that a social security number is all that is required...why is it such a pain to get a merchant account with a bank or other acquirer? I am curious how Stripe can make it so simple.
The second reason is that it's "standard", and everybody copies the "standard" without much consideration. The companies providing merchant accounts are usually not technology companies, and historically haven't had thought much about product.
We like to think that we can do much better than traditional companies on both counts.
I am curious as I am in fact an Australian citizen and know that a lot of people have a hard time here when trying to open a merchant account. From what I've read and heard it's traditionally a similar in the US and it is obviously one of the killer features of Stripe.
Was it hard for you to work with a bank (Wells Fargo) on this? From what I've heard banks are the main driver behind the 'shotgun' approach to information collection, at least here in Australia. I could well be wrong on this, hence I ask the question.
You are already doing a much better job than traditional companies on both accounts, it's great to watch and I'm sure you guys will continue to do great work.
Note: I just realised my spelling error in my previous post...iPhone autocorrect got the better of me!a
A lot of these services are not available outside the US. Last time I checked Google Checkout was limited to the US as well.
It is really annoying as I live in Canada and I cannot use many of these services.
Most of the fraud happens with accounts outside the US. New payment processors always start with the US and slowly expand outward.
Being able to deal with fraud is how PayPal made itself when everyone that came before it failed.
That's true, but too broad a brush. There's a difference between your average European country and China/Russia.
Key scaling issue is pricing. 2.9% is fine for low volumes and no risk validation, but once you're turning over large volumes and have a track record of no chargebacks etc the comparison looks much worse. If you can offer businesses a pricing that 'scales' with substantial reductions in transaction fee by volume then there is a growth path, otherwise any business would be crazy to stick with you no matter how good your service and APIs, etc because 2.9% could be half their gross margin and they can get 1% by dealing with the bank direct.
I didn't mention 1% as idle guesswork, I have direct knowledge of several businesses paying close to 1% on online (card not present, no signature) transactions. I'm not saying its easy to negotiate good rates, but its possible, even for fairly early stage startups. I got 1.6% for a startup turning over only about $20k per month, no track record and 'non standard' business model.
So feel free to push your bank, get quotes from their competitors, they can almost certainly do better for you.
EDIT: I just notice that stripe is planning to introduce volume discounts - that would make a very nice product!
I do about that volume, mostly card present, and think I have decent rates. I think I'm at Interchange plus .2% plus 1 cent per transaction plus $20 per month, and end up around 2.7% for total fees. I'm sure one can do better, but not by a lot. I'm willing to bet a considerable sum that you are not actually paying 1.6 percent once it's all added up. But if somehow you are, the loss of the bet would pay back quickly if I could get those rates myself!
http://twitter.com/#!/stripe
There are enough alternatives that have support for things like the Euro. They maybe don't have a fancy API but they work well enough and I can accept credit card payments from Uzbekistan in their local currency.
Then there's the part where they only accept US developers. While I can understand that again there's enough alternatives (FastSpring for example) who don't mistrust me because I'm living in the EU and will do payment processing for me.
I understand they wanted to launch ASAP with a MVP but maybe they cut down the wrong features. For me they are now another lazy payment processor who won't accept international customers and they will have to do some work to get rid of that stigma.
By making sure everybody has their own merchant account you may not make as much money on the transactions but you stay in business long term. And if there is one thing that really sucks it is to have to start all over again because your payment processor goes under, taking all your customers with it.
Stuff like that can kill you. If your transaction volume is serious enough to warrant your own merchant account then you should probably get one.
The first time that happened to me, was when I wanted to run my first test transaction at the command-line, and Stripe had generated the customized console commands for my specific app (with my specific API keys, etc.) and literally allowed me to copy and paste from their secure site to my command-line without having to do any thinking.
That was my first 'aha! OMG...this API is awesome' moment. There were many others, and the truth is I forgot until you mentioned it.
Now that you mentioned it, it reminded me how blindingly simple that is to implement - but SOOO many developers (I am guilty as charged too) overlook those little details that make SUCH a difference.
https://github.com/jashkenas/docco
Why would I use it instead of PayPal, 2CheckOut, e-junkie, etc?
As a seller of software myself (http://www.devside.net/server/webdeveloper), I can tell you that "API is cleaner" and "lower fees than 2CO" don't do anything for me at all.
I sell software and subscriptions online; I'm working on the switch over the Stripe because I really appreciated their cleaner API and low fees.
I've been using PayPal because it's cheap and easy, but they screw up many foreign payments (that have worked fine when run through Stripe), the whole "eCheck" thing confuses the hell out of people, and that whole "no, you don't have to create a PayPal account" thing. It's just unprofessional.
I can set up Stripe to handle processing for me completely transparently, and still without passing credit card data through my servers.
1) Getting to set up and manage another new account.
2) The pleasure of getting to rewrite (and test + debug) my backend payment process.
3) Getting a slightly cleaner API (that I'm never going to see after I implement it).
4) Saving an extra dollar on every transaction (of a $125 sale).
5) Working with a relatively new, and in that effect, inexperienced payment processor.
1 and 2 are not benefits to me at all. 3 and 4 I don't care about because they are marginal at best. 5 is a killer.
So why would I use Stripe?
> I can set up Stripe to handle processing for me completely transparently, and still without passing credit card data through my servers.
Same as it is now.
> I've been using PayPal because it's cheap and easy, but they screw up many foreign payments (that have worked fine when run through Stripe), the whole "eCheck" thing confuses the hell out of people, and that whole "no, you don't have to create a PayPal account" thing. It's just unprofessional.
Without experience, Stripe will screw up even more. If not on this part, then definitely on other parts. It's just the way it works.
Nothing differentiates Stripe for me from the rest of the bunch and I'm not going to fall over backwards putting in more work to switch to Stripe just because someone says the API is cleaner.
Give me an actual benefit and I'll consider.
I much prefer only paying when I make money. I don't NEED a merchant account. I just need to be able to collect money from my customers in an automated way. Stripe makes that relatively easy.
Their API has a quick feedback loop, where you can execute a transaction from the command-line very quickly (for Ruby anyway...I imagine it would be the same for other languages).
Their support is also awesome - could be because they only had beta users. But either way, awesome service so far and much better to deal with than a 'traditional' payment solution for those webappers out there (in my experience).
Not affiliated with the company in anyway, other than a customer.
However, as far as I can tell, anyone using any of the more established "big name" billing services to collect payments for a UK company is almost certainly breaking at least one law on a "your business is at risk" scale. Stripe would have to be very special to do better.
The usual culprits are VAT (I have yet to find a billing service that would actually allow a UK business to comply with its basic statutory requirements on this count, including several that claim to support VAT) and privacy (exporting personal data, such as names and credit card details, outside of Europe requires certain guarantees, which again I don't think would be met by any of the services I've looked into so far). I imagine quite a few businesses are getting away with using these services and not meeting their obligations, but personally I wouldn't want to operate with that sort of risk, particularly now Business Record Checks are becoming big news.
Stripe does seem to have a fairly clean API, but on the flip side, it also seems very limited in features next to some of the more established competition, so maybe it's just horses for courses. Again, I know that none of the other billing services we've considered this year even got close to supporting the basic charging model we wanted, never mind all the bells and whistles we've been considering, and if you wind up having to do a bunch of financial legwork yourself, these services start to look like very poor value for money pretty quickly.
IMHO, what small businesses in the UK really need is for the government to stop hassling banks about lending lots of money (sometimes useful, but not to many of us) and just get them to provide basic services like card payments in a sane manner: no multi-month waits to get up and running, directly comparable charging structures on some standard basis, transparent migration of customer card data between all the vault services without causing a PCI nightmare so there is genuine competition in the market, and so on.
And then I woke up. :-)
As I said in the live chat to them tonight - please guys, get to the UK soon :-)
There are all kinds of rules on disclosure of VAT registration details on invoices, sequential numbering of VAT invoices (across an entire company) for audit purposes, etc. Any payment system that doesn't integrate with other company procedures to meet these basic statutory obligations can't be sufficient.
Sure it would be nice if they stored tax (multiple rates possible on one invoice!) and VAT numbers in a separate field, it would be even nicer if they validated the VAT numbers for you, or the buyers location, but it can all be done outside the payment processor.
As you say, technically invoices are supposed to record the VAT against each line item, because the rates can be different for different types of product/service.
Regarding the serialised invoice numbers, if you as the merchant are having to keep track of such things then you're still doing some of the tedious work so the value of outsourcing the billing process is lessened. I agree that it might be viable to record the extra information in a separate field for one-off transactions, if the billing service allows that kind of annotation on transactions and your systems can generate the appropriate number taking into account any other sales channels you're also using.
Even then, for subscription services that renew automatically, there would need to be some robust mechanism for the billing service to "claim" the next invoice number when they collect a scheduled payment. Perhaps some of these services could cope with this, but I have yet to see one personally whose documentation explains how to set it up using their APIs and callbacks. And if you get to the point where you have to handle scheduling regular subscription payments on your in-house system to account for this, again you're defeating the point of outsourcing the billing in the first place.
IME, it doesn't take long before you have to do so much in-house anyway that you might as well do the lot and save yourself a signficant overhead and the additional risk/dependency of involving another organisation in your billing process. This sort of processing is tedious but not rocket science, so if you can't just wrap everything up and shove it out to a specialist service, avoiding having to go near that sort of stuff in-house at all, I just don't see how the cost/benefit of these services is going to make them attractive to a business here in the UK. YMMV, of course.
payment is a real pain in the neck and a rip-off in europe.
Their goal is to abstract away the complexity of payments, especially internationally. I wish them luck, and can't wait to use it.
You don't need to make your own merchant account or payment gateway because we abstract over those details. We'll make whatever accounts are necessary and we work directly with the banks to make sure that your money is held in your name, what you want appears on your customers' credit card statements, etc.
Very amazing concept and something that we've needed for a long time. The best thing is the developer focus behind it; it's clear from the beginning that this came to fruition with fellow developers in mind.
As for point of sale applications, Stripe isn't really optimized for that. Have you checked out Square?
On another note, your markup is doing some strange things:
;var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});;var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});;var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});
It looks like these guys have done it right, and finally hidden the layers friction, banking (and open palms) for us.
Nice Work!
One Nit if anyone from Stripe is reading - it was a bit hard to find the answer to "How & When do I get paid". There is a small blurp on the pricing page (still doesn't say how), but nothing in the FAQ or Docs. Please spell this out a bit more.
There are probably better specifics in the TOS or elsewhere, I guess I was looking for something spelled out better in the docs. (Ex: "Use any standard US Business or Personal checking account")
It's probably just me though :-)
https://manage.stripe.com/tos
What kind of management trusts a new start-up with such a fundamental part of their business, inevitably including a certain amount of opportunity cost and risk of delay if moving to another service is necessary, based only on a contract of adhesion that allows for the service to be terminated at any time with negligible notice and without any sort of compensation or guaranteed handover arrangements?
Can't wait to see how the international version works.
Average size of our customer is fairly large, skewed by several large customers. We have a lot of startup customers. The ones that are a challenge to get underwritten are typically marketplace businesses of some kind (you sell something, a third party gets paid for it and you take your cut). We have a bunch of them as customers but some are a challenge to get underwritten (fraud reasons/banks are stupid about it).
We are totally upfront and transparent and never post anonymously btw. Our business name is actually Transparent Financial Services!
AFAIK PayPal claims to be Credit Card Fraud Protection service that happens to process credit cards.
Does Stripe focus on fraud prevention?
If yes - I could have used that rating to decide whether to approve the purchase automatically or give it a manual review.
As lovely as this API looks, not offering a volume discount is a complete dealbreaker for my business. There's no way I could justify eating an extra ~1% per transaction just so my API integration goes more smoothly and I don't have to deal with the headaches of a merchant account (and while I would call that process anything but smooth, I don't seem to have the awful experiences of some of the commenters here -- just chance, I guess).
The cost/benefit to a business that does any significant volume online just isn't there for this.
Can't wait to see you guys expand internationally. Best of luck.
The pricing for 1,000 monthly users looks (roughly) like:
(edit: I did the % based on $9/transaction)
Stripe: $329/mo @ $3,948/yr
Samurai: $358/mo @ $4,296/yr
Braintree: $487.90/mo @ $5,854.80/yr
I've considered doing something similar for my own side project, but went with the more standard sign up because I was worried it would be confusing (as it was to me, for a few minutes). Do you guys think this is becoming more mainstream, at least amongst developers and the tech-savvy, that other projects could get away with this? I'm curious how many support requests Stripe gets because of this.
Edited to add: How does this work for the non-logged-in state? I already have an account, and the browser cookie expires (or manually delete the cookies). I'll go to the dashboard, and be logged in as "anonymous", and have to sign out and sign in again as the right user. Seems like an extra incongruous step.
Mostly, I think it depends on the type of app you have. For something like 280 Slides (a previous project I worked on), it makes a lot of sense to get started right away without having to sign up. We'll see how things go for Stripe.