Stripe: instant payment processing for developers(stripe.com)
stripe.com
Stripe: instant payment processing for developers
https://stripe.com
368 comments
I would love to see someone drag it kicking and screaming outside of the US.
:(
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!
Would it be much extra effort to bring to Canada? I'd use this today if I could.
Providing international support is probably in the 'too hard' basket.
Not too hard! We're working on it right now and hope to have international support soon.
Maybe you could set up a mailing list that notifies international users when your service expands internationally?
They have a Twitter feed:
http://twitter.com/#!/stripe
http://twitter.com/#!/stripe
I wish there were a trustworthy global payment operator a la Stripe.
[deleted]
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.
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.
> 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.
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.
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.
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 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!
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!
We do plan on doing volume discounts eventually.
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.
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.
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.
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.
I became concerned with reading this statement. We need a lawyer to understand liability for laundering with regard to systems like Stripe
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'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 ;-)
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 ;-)
Also selling! Don't be ashamed of it. If you have a good product, sell it!
(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.)
(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.)
He means the fees. You can pay significantly less than 2.9% + 30¢ with a merchant account.
Q: Do I need to be in the United States to use Stripe?
A: Yes.
Would you finally be the one to tell us what the hell is the problem with non-US customers?
Not being able to cope with the fraud is the #1 reason why payment processors fail.
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.
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.
Most of the fraud happens with accounts outside the US.
That's true, but too broad a brush. There's a difference between your average European country and China/Russia.
That's true, but too broad a brush. There's a difference between your average European country and China/Russia.
Unfortunately, there are just a lot of regulations when dealing with payments across international borders.
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.
Yours is the most compelling one I've seen.
Yours is the most compelling one I've seen.
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.
Do they even need a presence in other countries to be able to work with companies in them?
The Patriot Act.
While this reply is short it is right. The Patriot Act is the reason why these nice things generally aren't available to non US citizens. Patriot Act Section 312: http://ithandbook.ffiec.gov/media/resources/3356/con-usa_pat...
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.
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.
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?
Well, why do their representatives insist it's a "top priority" then?
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).
Something just occurred to me.
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.
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.
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.
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.
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.
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.
Thanks Patrick.
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
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
I don't think it is easy to expand to many countries with products that are sensitive to regulations, e.g. payment, and music streaming.
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.
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.
google checkout works in the uk
they've been nothing but headaches (especially if you're young—nobody trusts you.)
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=)
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=)
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.
I've been turned down a few times for merchant accounts. The company I started in college got turned down, and we ended up using paypal.
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.
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.
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...
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.
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.
It's mostly just a custom thing I wrote. The CSS is mostly taken (with permission) from Jeremy Ashkenas' sites (see Backbone, CoffeeScript, etc.)
Thanks! Nice work; looks tidy. I'll take a hunt around.
Navigation menu doesn't work in IPad.
I think it's fixed in iOS 5, but yeah not an ideal answer.
Looks like Docco by Jeremy Ashkenas (CoffeeScript/BackBone.js fame) with some extra styling and a navigation bar up top.
https://github.com/jashkenas/docco
https://github.com/jashkenas/docco
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.
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.
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.
Give me an actual benefit and I'll consider.
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.
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.
Misunderstanding on my part. Fixed.
"You don't need a merchant account or gateway."
That's a killer feature right there. I've been considering using Braintree for a project, but seeing this is really making me reconsider.
That's a killer feature right there. I've been considering using Braintree for a project, but seeing this is really making me reconsider.
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.
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.
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.
As a beta customer, not having to deal with 95% of PCI and merchant accounts etc. really made a huge difference to how fast we got going.
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.
[deleted]
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?
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?
They do, but you have to pay extra for all that. Stripe's pricing is simple enough for my small mind to comprehend without needing a spreadsheet.
That's a strong sell even after sign-up actually. We're trying to sort through Braintree charges right now and it is pretty painful...
Hey edash,
Shoot to hear you're having trouble sorting it out. Please feel free to reach out to [email protected] . She'll help you out.
Shoot to hear you're having trouble sorting it out. Please feel free to reach out to [email protected] . She'll help you out.
Thanks so much, we'll do that!
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 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.
US only. Well, I kind of knew it before even hitting FAQ.
A bit of a rant here, but it's crazily difficult to do so many interesting things when you don't live in top-20 country (Lithuania here)
Stripe? Nope.
BrainTree? Nope.
Recurly? Nope.
Something else... Likely, Nope.
And so, the only way to get paid is to deal with some of the most expensive and oldest gateways and merchant accounts.
Oh, and:
Hulu? Nope.
iTunes? Nope, but we do have App Store.
Netflix? Nope.
Spotify? Nope.
Pandora, Rdio, ... Nope.
...Amazon? Mostly nope.
And so, the only way to buy or stream media is to buy CDs and DVDs for crazy prices.
Sigh. Rant is over.
Stripe, I know that may take years, but please, don't forget the little guys.
A bit of a rant here, but it's crazily difficult to do so many interesting things when you don't live in top-20 country (Lithuania here)
Stripe? Nope.
BrainTree? Nope.
Recurly? Nope.
Something else... Likely, Nope.
And so, the only way to get paid is to deal with some of the most expensive and oldest gateways and merchant accounts.
Oh, and:
Hulu? Nope.
iTunes? Nope, but we do have App Store.
Netflix? Nope.
Spotify? Nope.
Pandora, Rdio, ... Nope.
...Amazon? Mostly nope.
And so, the only way to buy or stream media is to buy CDs and DVDs for crazy prices.
Sigh. Rant is over.
Stripe, I know that may take years, but please, don't forget the little guys.
We totally get it. We're working on expanding to other countries right now, it's one of our top priorities.
Please think of India when you do. Paypal recently botched big-time in India (search paypal pan card) and there is a big hole that needs to be filled.
We have a volume of about $500k and with Paypal failing us big time, we've ourselves been searching like crazy for the past one week for a good payment processor. Alertpay was looking most promising until I came across this post. Unfortunately, since stripe is US only, so as soon as you start support more countries, we're definitely add you guys to our site too!
We have a volume of about $500k and with Paypal failing us big time, we've ourselves been searching like crazy for the past one week for a good payment processor. Alertpay was looking most promising until I came across this post. Unfortunately, since stripe is US only, so as soon as you start support more countries, we're definitely add you guys to our site too!
Just curious -- why is PAN a problem? Is it hard to get a PAN for your business?
Have you looked into incorporating in the UK? It's probably quite a bit of hassle up-front but should solve this type of problem. Unlike in many (most?) European countries, incorporating a limited company in the UK is pretty cheap and straightforward in itself.
[deleted]
I don't see what incorporating in the UK would buy you. Payment processing here is a total clusterfuck.
Does this mean you have a huge opportunity to be the Stripe (or Braintree/Recurly/Hulu etc) of Lithuania?
That's the problem with tiny countries:
- Global market players don't come because they don't think the effort would pay for itself.
- The country is too tiny to make cloning business models feasible.
In Europe, there are a lot of tiny countries: 3 baltic states, 3 transcaucasian states, moldavia, some former yugoslavian states. And then you have countries that are just small and not very rich, so they are always late to any party: most of western europe, greece perhaps. Even some core european countries might see this effect (for example, where does Amazon work?)
And trying to bootstrap in ten mostly unrelated countries at once would lead to failure. And if you succeed, global players might come and eat your lunch.
It's an interesting effect where a small country suffers a noticeable drop in quality of online life due to many services being unavailable.
- Global market players don't come because they don't think the effort would pay for itself.
- The country is too tiny to make cloning business models feasible.
In Europe, there are a lot of tiny countries: 3 baltic states, 3 transcaucasian states, moldavia, some former yugoslavian states. And then you have countries that are just small and not very rich, so they are always late to any party: most of western europe, greece perhaps. Even some core european countries might see this effect (for example, where does Amazon work?)
And trying to bootstrap in ten mostly unrelated countries at once would lead to failure. And if you succeed, global players might come and eat your lunch.
It's an interesting effect where a small country suffers a noticeable drop in quality of online life due to many services being unavailable.
You're overstating the issue. There's only one thing that keeps most services from being available: the insane antiquated and utterly corrupt copyright laws. Without that, there would be no issue.
Specific stuff like online payments very much depend on local context, and in many countries they barely even have the problem Stripe is trying to solve for the US market.
Specific stuff like online payments very much depend on local context, and in many countries they barely even have the problem Stripe is trying to solve for the US market.
The copyright thing is real, and it does prevent access to those services. Ask anyone from a small country how it affects them.
It's also payments, logistics sometimes. You can't open in a part of country and leave other part behind, but you can do that with a mosaic of countries.
It's also payments, logistics sometimes. You can't open in a part of country and leave other part behind, but you can do that with a mosaic of countries.
Even living in the UK is frustrating some times. I wish more businesses advertise their operating limits on the home page. I got quite excited when looking at stripe, but only after looking half-way down their help & support page does it mention they are US only.
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.
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.
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.
This is extremely confusing. Thought it was just a test account. Left depressed because I couldn't sign up.
yep, i thought the same.
fwiw, that design pattern is called lazy registration.
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.
US only at the moment. Anyone know if they have plans for the UK? I would dearly love to say goodbye to PayPal forever.
We're definitely working on expanding to other countries. There's no definite timeline just yet, but it's one of our top priorities.
Another UK LTD company here wanting to use your service the minute its available, so many headaches to be avoided.
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.
And then I woke up. :-)
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. :-)
[deleted]
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.
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.
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.
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.
+1, well said.
As I said in the live chat to them tonight - please guys, get to the UK soon :-)
As I said in the live chat to them tonight - please guys, get to the UK soon :-)
the day its possible to use your service in europe/austria, i sign up.
payment is a real pain in the neck and a rip-off in europe.
payment is a real pain in the neck and a rip-off in europe.
Australia. ;)
Well if you ever need a UK based (UK Limited Company) beta tester let me know! :)
+1 from Norway. The local payment providers are terrible.
I would LOVE to have something like that in Brazil...
Another one here from Denmark, but Spain will make the deal as well.
Don't forget "third world" countries like South Africa :)
i am your customer as soon as you do this :)
I'll start using it as soon as you do...
+2 for UK
Germany please!
+3 for the UK.
Netherlands +1
+1 for France
+1 for the UK
[deleted]
I too vote for this.
Stripe, recently saved me. I am still fighting with my merchant processor *First Data who is awful. I talked to Stripe via Sean Harper with FeeFighters and I was up and rolling in 20 minutes. Yes, Jaw drop fast. Most payment processors require at least two weeks to be setup. Their UI/UX is beautiful and simple. When I need help I get it immediately. I love this company. :)
I'm not sure about avoiding PCI compliance so easily. You're embedding their JS library on your page. That page has to be secure, otherwise if someone can inject malicious Javascript they can sniff the CC data as soon as they are entered.
You might not be storing the data on your servers, or transmitting the data directly, but security failures in your setup can cause the data to be leaked.
Compare this to sending the user to an external website via a redirect that lets the user at least verify that they're really talking to PayPal or whoever.
You might not be storing the data on your servers, or transmitting the data directly, but security failures in your setup can cause the data to be leaked.
Compare this to sending the user to an external website via a redirect that lets the user at least verify that they're really talking to PayPal or whoever.
You're right, you should be using SSL on your payment pages. It's required for our users (see https://stripe.com/help/ssl).
PCI, however, doesn't actually have requirements around SSL, so it's not technically related to PCI compliance.
PCI, however, doesn't actually have requirements around SSL, so it's not technically related to PCI compliance.
PCI is absolutely schizophrenic about this point, and right now embedding your provider's form within your own same origin domain is kosher with them.
You're right if you're thinking it shouldn't be.
You're right if you're thinking it shouldn't be.
You're right if you're thinking it shouldn't be.
Nonsense. That would only be true if PCI was somehow related to security. ;-)
Nonsense. That would only be true if PCI was somehow related to security. ;-)
> You're right if you're thinking it shouldn't be.
Why do you think it should not? AFAIK, doing so exempts you (legitimately) from much of PCI DSS that applies if sensitive data hits your network, but does not automatically exempt you from the rest.
Are you concerned that someone will be able to compromise the page on your own server so it no longer embeds the payment service's form correctly, and then capture card data that way?
Why do you think it should not? AFAIK, doing so exempts you (legitimately) from much of PCI DSS that applies if sensitive data hits your network, but does not automatically exempt you from the rest.
Are you concerned that someone will be able to compromise the page on your own server so it no longer embeds the payment service's form correctly, and then capture card data that way?
The exemption you are talking about is not legitimate, because of the way browser security works.
Perhaps you could elaborate, rather than posting vague innuendo about "how browser security works"?
What specific danger do you see in the embedding scenario that could not arise anyway if the host system were compromised sufficiently to interfere with the embedded material?
What specific danger do you see in the embedding scenario that could not arise anyway if the host system were compromised sufficiently to interfere with the embedded material?
I'm obviously not tptacek, but I take his statement to mean that currently, PCI finds the following scenario acceptable:
You have a site that takes payment info. Rather than process that information directly and store it you decide to use a service like this to silo out payment processing. This keeps your main environment outside of the scope of a PCI audit (as the only systems in scope for PCI are systems which either process or store payment card information).
You are now not under any obligation to ensure that your application isn't riddled with security vulnerabilities, including vulnerabilities like cross-site scripting which would completely undermine the security of using a third-party javascript library to handle payment processing. This isn't some sci-fi scenario either, I see this every day in the applications I test (mostly e-commerce and online banking applications).
Using the library hasn't introduced any "new" vulnerabilities into your environment, but it has given you an opt-out to actually trying to have a secure system.
He seems to take exception to the fact that PCI doesn't see any problem with this. It's basically a loophole to continue to deploy hole-riddled applications that once hacked, you can say "We are PCI compliant, what are you gonna do."
This gives credence to the people who argue that PCI isn't really a security standard, but just a way to shift blame after a breach.
You have a site that takes payment info. Rather than process that information directly and store it you decide to use a service like this to silo out payment processing. This keeps your main environment outside of the scope of a PCI audit (as the only systems in scope for PCI are systems which either process or store payment card information).
You are now not under any obligation to ensure that your application isn't riddled with security vulnerabilities, including vulnerabilities like cross-site scripting which would completely undermine the security of using a third-party javascript library to handle payment processing. This isn't some sci-fi scenario either, I see this every day in the applications I test (mostly e-commerce and online banking applications).
Using the library hasn't introduced any "new" vulnerabilities into your environment, but it has given you an opt-out to actually trying to have a secure system.
He seems to take exception to the fact that PCI doesn't see any problem with this. It's basically a loophole to continue to deploy hole-riddled applications that once hacked, you can say "We are PCI compliant, what are you gonna do."
This gives credence to the people who argue that PCI isn't really a security standard, but just a way to shift blame after a breach.
I'm not disagreeing with your example, but isn't that a much wider problem? After all, any business or individual can set up a web site, stick an official-looking form on it, and harvest card details. They don't need any sort of payment processing infrastructure to do that, and clearly nothing PCI DSS says can protect against all malicious strategies for compromising card details.
My understanding was that the parts of PCI DSS we're considering were intended to cover carelessness where a legitimate business collects customer details but then leaves them vulnerable due to internal security failings. If the details don't hit the internal network, those failings can't happen, so it is reasonable to exclude them from the scope of the corresponding parts of PCI DSS.
Beyond that, I'm not sure I see any difference between the embedding scenario and the common practice of redirecting to a payment service's own web pages when a customer reaches a certain point in the order process. If you're exposing a vulnerability that lets an attacker compromise the embedding, they can almost certainly compromise the redirect in the equivalent case as well, and in reality it is unlikely that most customers would notice even if there were clues to give away the attack in some cases.
I'm also not sure what you mean by keeping your main environment outside the scope of a PCI audit. For the payment gateways we've been looking at that offer both hosted and embedded integrations, it is common that the hosted one has minimal audit requirements but the embedded one comes with certain audit obligations for your web site even if you're relying entirely on their system to handle the card details.
Now, if this isn't a mandated practice in PCI DSS, then I do see your point; I've always assumed it is, since everyone we've looked into seems to do it, but in fairness I haven't just looked it up today. However, if that is part of PCI DSS then in fact sites using the embedding strategy are subject to more rigorous scrutiny than those that simply redirect, even though essentially the same attack vectors are probably available for both.
My understanding was that the parts of PCI DSS we're considering were intended to cover carelessness where a legitimate business collects customer details but then leaves them vulnerable due to internal security failings. If the details don't hit the internal network, those failings can't happen, so it is reasonable to exclude them from the scope of the corresponding parts of PCI DSS.
Beyond that, I'm not sure I see any difference between the embedding scenario and the common practice of redirecting to a payment service's own web pages when a customer reaches a certain point in the order process. If you're exposing a vulnerability that lets an attacker compromise the embedding, they can almost certainly compromise the redirect in the equivalent case as well, and in reality it is unlikely that most customers would notice even if there were clues to give away the attack in some cases.
I'm also not sure what you mean by keeping your main environment outside the scope of a PCI audit. For the payment gateways we've been looking at that offer both hosted and embedded integrations, it is common that the hosted one has minimal audit requirements but the embedded one comes with certain audit obligations for your web site even if you're relying entirely on their system to handle the card details.
Now, if this isn't a mandated practice in PCI DSS, then I do see your point; I've always assumed it is, since everyone we've looked into seems to do it, but in fairness I haven't just looked it up today. However, if that is part of PCI DSS then in fact sites using the embedding strategy are subject to more rigorous scrutiny than those that simply redirect, even though essentially the same attack vectors are probably available for both.
If you're a single XSS vulnerability away from transparently capturing credit card vulnerabilities, but there is no requirement anywhere in PCI DSS that your application be in any way hardened against XSS vulnerabilities, all PCI DSS has done is move the target slightly.
I completely agree, I'm just wondering how that's any different to any other hosted integration.
Perhaps I misunderstood your original point as being too specific to the embedding situation. Would you apply the same criticisms to the other common integration strategy based on redirects?
If your intended point was that any legitimate business taking credit card details via their web site should be subject to at least some basic level of audit, then I think we are probably in agreement (though I do have a thing about card companies imposing security rules on merchants but then trying to leave merchants with all responsibility for any fraud anyway, which is a totally one-sided deal).
[Edit: As an aside, I'm not sure how this would work in a case where the merchant is using an end-to-end solution, which Stripe seems to be, and has no direct relationship with any other financial services. Presumably the responsibility then has to fall on the payment service, which would have to impose some sort of reasonable audit procedure on all of its clients?]
Perhaps I misunderstood your original point as being too specific to the embedding situation. Would you apply the same criticisms to the other common integration strategy based on redirects?
If your intended point was that any legitimate business taking credit card details via their web site should be subject to at least some basic level of audit, then I think we are probably in agreement (though I do have a thing about card companies imposing security rules on merchants but then trying to leave merchants with all responsibility for any fraud anyway, which is a totally one-sided deal).
[Edit: As an aside, I'm not sure how this would work in a case where the merchant is using an end-to-end solution, which Stripe seems to be, and has no direct relationship with any other financial services. Presumably the responsibility then has to fall on the payment service, which would have to impose some sort of reasonable audit procedure on all of its clients?]
The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor. That would be nice, but I don't think it can be done today.
Fortunately for developers, PCI's response to this problem seems to be "LA LA LA I CAN'T HEAR YOU".
Fortunately for developers, PCI's response to this problem seems to be "LA LA LA I CAN'T HEAR YOU".
> The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor.
On the contrary, I don't believe that can be done effectively within the architecture we have today. I just don't believe it can be done effectively for hosted integrations that redirect to the service provider either, so I don't see that the embedding approach is any worse than what was already in widespread use.
Moreover, given that it is unrealistic not to provide hosted payment services (since the overheads of doing everything in-house are prohibitive for almost any small business), I think the only useful response is to impose some basic level of audit on any site that is integrating with an external card payment system. But now you're more into economic/commercial/legal arguments than technical ones, because you have to consider what level of oversight is reasonable (given that any fool can set up a fraudulent site regardless of what you do, how much extra burden is it really sensible to impose on legitimate merchants), how it can be enforced (particularly if the site visited by the end user has no direct legal/commercial relationship with the card services companies), and whether there is a sensible balance between functionality/security and actually being able to operate in the first place as a merchant (which is a balance that the UK currently gets absurdly wrong, though I don't think the scenario we're discussing is why).
On the contrary, I don't believe that can be done effectively within the architecture we have today. I just don't believe it can be done effectively for hosted integrations that redirect to the service provider either, so I don't see that the embedding approach is any worse than what was already in widespread use.
Moreover, given that it is unrealistic not to provide hosted payment services (since the overheads of doing everything in-house are prohibitive for almost any small business), I think the only useful response is to impose some basic level of audit on any site that is integrating with an external card payment system. But now you're more into economic/commercial/legal arguments than technical ones, because you have to consider what level of oversight is reasonable (given that any fool can set up a fraudulent site regardless of what you do, how much extra burden is it really sensible to impose on legitimate merchants), how it can be enforced (particularly if the site visited by the end user has no direct legal/commercial relationship with the card services companies), and whether there is a sensible balance between functionality/security and actually being able to operate in the first place as a merchant (which is a balance that the UK currently gets absurdly wrong, though I don't think the scenario we're discussing is why).
Though to be fair, if you've got an XSS vulnerability, you can also just change the URL of the off site payment page to a phishing site, which most people will probably fall for.
All of these things fall into the same boat, security-wise -- so by my interpretation, the PCI rules make sense here.
If the attacker can insert their own code that says "hi there, we may have to close the site unless we can get some donations ASAP - please help!" followed by a form for CC data, that's that. It doesn't matter if they normally accept payments by redirecting to PayPal, or if they use an iFrame, or the Stripe JavaScript approach. It's all the same at that point, security-wise.
So let this be Bucket A, for websites where CC info doesn't touch their servers -- this is their risk profile. If a site in Bucket A is compromised and it takes a month before the complaints add up and the host shuts them down, that's a month's worth of stolen credit cards (this is not "worst case", but let's assume the thieves aren't terribly patient and start selling card info soon after stealing it).
Bucket B is for sites where the CC info DOES touch their servers. For them, CC data may be recorded on the server (intentionally into a data store, or even accidentally into log files of some kind). This is a different security risk. A site in this category could be compromised, and in half an hour 10 years worth of their credit card info could be stolen.
To steal 10 years worth of CC data from a site in Bucket A is naturally much more difficult.
If you've got to draw a line somewhere, that's a reasonable one.
If the attacker can insert their own code that says "hi there, we may have to close the site unless we can get some donations ASAP - please help!" followed by a form for CC data, that's that. It doesn't matter if they normally accept payments by redirecting to PayPal, or if they use an iFrame, or the Stripe JavaScript approach. It's all the same at that point, security-wise.
So let this be Bucket A, for websites where CC info doesn't touch their servers -- this is their risk profile. If a site in Bucket A is compromised and it takes a month before the complaints add up and the host shuts them down, that's a month's worth of stolen credit cards (this is not "worst case", but let's assume the thieves aren't terribly patient and start selling card info soon after stealing it).
Bucket B is for sites where the CC info DOES touch their servers. For them, CC data may be recorded on the server (intentionally into a data store, or even accidentally into log files of some kind). This is a different security risk. A site in this category could be compromised, and in half an hour 10 years worth of their credit card info could be stolen.
To steal 10 years worth of CC data from a site in Bucket A is naturally much more difficult.
If you've got to draw a line somewhere, that's a reasonable one.
> This gives credence to the people who argue that PCI isn't really a security standard, but just a way to shift blame after a breach.
Which it is!
What is really needed isn't a better PCI, but a better credit card system - one where a breach has little impact on credit card holders.
Which it is!
What is really needed isn't a better PCI, but a better credit card system - one where a breach has little impact on credit card holders.
What he said. :)
They require that you host your payments in HTTPS.
https://stripe.com/help/ssl
They themselves are PCI Compliant. https://stripe.com/security
https://stripe.com/help/ssl
They themselves are PCI Compliant. https://stripe.com/security
> I'm not sure about avoiding PCI compliance so easily. You're embedding their JS library on your page. That page has to be secure, otherwise if someone can inject malicious Javascript they can sniff the CC data as soon as they are entered.
If their credit card info doesn't touch your server, then it is out of scope as far as PCI is concerned. Yes it's BS, since the risk is essentially the same, but that's how it's currently written.
If their credit card info doesn't touch your server, then it is out of scope as far as PCI is concerned. Yes it's BS, since the risk is essentially the same, but that's how it's currently written.
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.
Their goal is to abstract away the complexity of payments, especially internationally. I wish them luck, and can't wait to use it.
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?
We don't handle direct transfers between two ACH accounts yet, but it's something we're thinking about and planning for down the road.
As for point of sale applications, Stripe isn't really optimized for that. Have you checked out Square?
As for point of sale applications, Stripe isn't really optimized for that. Have you checked out Square?
ACH payout to multiple endpoints would be killer (think App Store type 70% payouts to users).
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({});
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({});
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.
I asked them on their live chat, and apparently at this time, they have no timeline but they're saying Canada is top on their list for expansion.
I saw this on the front page and had to upvote--
I've been using Stripe since early June and can say that it is the best payment platform to develop on, period. It's just lightyears ahead in terms of development time, PCI compliance issues, and overhead. Not only that, but the guys at Stripe are extremely responsive to customer service questions and issues.
These guys are trustworthy professionals and gentlemen.
These guys are trustworthy professionals and gentlemen.
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.
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.
I know this has already been stated and it doesn't add much to the discussion. However, I feel it's important to add my little two cents just so the Stripe team (and others in the same space) can hear it (again):
Please, please, PLEASE make a payments solution like this available outside the US. Europe, for instance, still lives in the dark ages as far as online payments are concerned and has plenty of startups who would jump at the opportunity to use Stripe.
Please, please, PLEASE make a payments solution like this available outside the US. Europe, for instance, still lives in the dark ages as far as online payments are concerned and has plenty of startups who would jump at the opportunity to use Stripe.
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).
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:
(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
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
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.
Even though the credit card details never hits the webserver of the host site, does the fact that the fields are on the site rather than in a secure iframe not mean that there's still a PCI issue? Namely that if a malicious party manages to find a way to inject javascript into the page they can read any form field they want, regardless of whether it's being submitted elsewhere.
This was true of Braintree (the form posts to a remote url rather than to a server run by the site), how does Stripe alleviate this issue?
This was true of Braintree (the form posts to a remote url rather than to a server run by the site), how does Stripe alleviate this issue?
If someone injects javascript into your page, nothing you do will matter -- you are compromised.
This is why your site has to be served over SSL (to prevent MITM attacks), and why you should be careful about what third party content you embed in your site. In particular, you should never embed a non SSL resource on an SSL page (also known as the mixed content warning in most browsers).
This is why your site has to be served over SSL (to prevent MITM attacks), and why you should be careful about what third party content you embed in your site. In particular, you should never embed a non SSL resource on an SSL page (also known as the mixed content warning in most browsers).
But say you have a untrustworthy employees (it happens), as long as they have the ability to deploy code, they can compromise your site. So my question is, to what extent can a solution like Slice (or Braintree) truly alleviate the PCI burden, surely you'd still need a record of who has the ability to deploy code, audit trail for deploys etc.
Obviously you should be doing all this stuff anyway. I guess the point I'm making is that solutions like this make great claims about their ability to solve all your PCI woes, and I'm wondering about the extent to which this is actually true. PCI compliance is (normally) quite expensive to achieve, so your solution is obviously very attractive. But is it enough?
Obviously you should be doing all this stuff anyway. I guess the point I'm making is that solutions like this make great claims about their ability to solve all your PCI woes, and I'm wondering about the extent to which this is actually true. PCI compliance is (normally) quite expensive to achieve, so your solution is obviously very attractive. But is it enough?
No third party could completely protect you from an untrustworthy employee, but that doesn't automatically subject you to every theoretical PCI requirement. If you have a malicious employee, you'll be liable for the damage that employee causes, yes. But using something like Stripe.js reduces even that risk, because it reduces the potential surface area of an internal attack as much as it reduces the possibility of external attacks.
>But say you have a untrustworthy employees (it happens),
Well that's still a PCI requirement, but many more of their requirements wouldn't apply (i.e. rendering stored PAN unreadable, etc).
When in doubt: http://www.youtube.com/watch?v=xpfCr4By71U
Well that's still a PCI requirement, but many more of their requirements wouldn't apply (i.e. rendering stored PAN unreadable, etc).
When in doubt: http://www.youtube.com/watch?v=xpfCr4By71U
Rumored cost of this video is over 1 million dollars.
My only concern is that Stripe will be such a hit that they'll be bought out by someone like Paypal. Which would suck since the point was to move away from Paypal to Stripe.
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.
Best API ever for a payments processor - period. It literally takes a couple hours to set up begin collecting payments. If I could buy some shares right now I would. I've convinced 2 people to use it and both are in love. This startup is money.
I mean this as a serious question: when Stripe has 10,000 customers next year, why will they be less capricious and infuriating than Paypal?
Is there a fundamental difference, or does Paypal just have a ~15-year history of sucking, while Stripe doesn't?
Is there a fundamental difference, or does Paypal just have a ~15-year history of sucking, while Stripe doesn't?
Good question.
A lot of PayPal's issues stem from the draconian fraud measures they need to employ to handle user-to-user payments. Our business and fraud problems are fundamentally different because we don't support this use case.
Additionally, we've been really careful to grow slowly, and to make sure the experience for our users remains great. We've been in invite-only mode for well over a year before opening up today, and intend to monitor (and, if necessary, limit) our growth so that this doesn't happen.
We'd rather be small than suck.
A lot of PayPal's issues stem from the draconian fraud measures they need to employ to handle user-to-user payments. Our business and fraud problems are fundamentally different because we don't support this use case.
Additionally, we've been really careful to grow slowly, and to make sure the experience for our users remains great. We've been in invite-only mode for well over a year before opening up today, and intend to monitor (and, if necessary, limit) our growth so that this doesn't happen.
We'd rather be small than suck.
We've been using Stripe for Picplum.com since the middle of the summer. These guys are insane -- they saw an error before we even did and emailed us saying they were working on fixing it. Top notch team.
First, I wish the folks from Stripe all the best, and the only thing I hoped was International companies support.
But as anyone tried Saasy (http://saasy.com/) ? They are the subscription service of Fastspring. They don't require a merchant account and support international vendors. While I haven't tried them yet, when I used non-subscription payments they were the best (www.fastpring.com). They are also very well regarded by indie developers so their subscription service may be quite good.
But as anyone tried Saasy (http://saasy.com/) ? They are the subscription service of Fastspring. They don't require a merchant account and support international vendors. While I haven't tried them yet, when I used non-subscription payments they were the best (www.fastpring.com). They are also very well regarded by indie developers so their subscription service may be quite good.
Does Stripe allow delayed payments? That is, people put in their credit card details, Stripe authorizes the card but doesn't capture the amount charged, then we can approve/decline the transaction, and then Stripe can capture or void the transaction?
We have a situation where we need, for legal reasons, to verify that people giving us money are allowed to do so, and we really don't want to have to reverse the charge after the fact if we find out they're not eligible to pay us.
Otherwise, the system looks great, and I want to use it right now.
We have a situation where we need, for legal reasons, to verify that people giving us money are allowed to do so, and we really don't want to have to reverse the charge after the fact if we find out they're not eligible to pay us.
Otherwise, the system looks great, and I want to use it right now.
We don't support what's typically known as separate auth and capture in the payment industry (though we may in the future).
Typically, we recommend just capturing the card information by attaching it to a customer object, and then making a charge later. If you're charging a really high amount, or for some reason need a 100% guarantee that the charge will succeed, then right now you'll have to make the charge and then issue a refund in your situation.
Typically, we recommend just capturing the card information by attaching it to a customer object, and then making a charge later. If you're charging a really high amount, or for some reason need a 100% guarantee that the charge will succeed, then right now you'll have to make the charge and then issue a refund in your situation.
Note, though: when you refund the charge, the fees you paid aren't refunded to you.
This was the one downside of Stripe for me, vs. PayPal (though it's pretty minor -- I only have a handful of refunds a year... but I offer them all the time, and I've always liked feeling free to do that).
This was the one downside of Stripe for me, vs. PayPal (though it's pretty minor -- I only have a handful of refunds a year... but I offer them all the time, and I've always liked feeling free to do that).
Sean, you should jump into our campfire (https://stripe.com/campfire) or send us an email at [email protected]. We can try to offer a few suggestions for how to do this.
What about lock-in? This is awesome for getting started fast, but what happens when you have 100,000 subscribers and you want to switch to Braintree or someone to get some better pricing?
We don't like lock in either, and we'll never use it as a business tactic. If you want to move your stored credit cards to another provider, we'll help you out in doing so.
It's a bit tough to make this obvious, because we can't automate it unfortunately. PCI requires that we work directly with the environment that we're sending your data too, to ensure the transfer is also secure.
It's a bit tough to make this obvious, because we can't automate it unfortunately. PCI requires that we work directly with the environment that we're sending your data too, to ensure the transfer is also secure.
Best answer, thank you.
This is great business, right now I have a lot of confidence in you guys.
I would also like to know about this. Their solution looks great! But I'd want to ensure that if this company goes under, or if it doesn't do what it promises, there's a way for me to get ALL of my data (subscribers, past payments, other details) and switch to another provider.
See the sibling post for more info on moving credit cards to another provider, but as for everything else (customer info, subscriptions, charges, etc.) everything is available through our API (https://stripe.com/api/docs).
Man... I literally just bit the bullet and opened a merchant account and gateway at Auth.net last week, and the second I do, FeeFighters comes out with their own superior gateway, and Stripe launches. Talk about bad timing for me :(
Makes 2 of us. Just finished integrating with Auth.Net. Yep, bad timing IF this is as easy and secure as everybody says.
Congratulations on your official launch. I've been using Stripe for a while now and have chatted with several of you in the campfire room. You have always been extremely helpful, no matter what wildass time of the night I may decide to poke my head into the room.
I have nothing but good things to say about your service.
Thank you.
I have nothing but good things to say about your service.
Thank you.
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.
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.
Been using them for a while now on Forrst and Tinyproj and they're downright awesome. Smart folks, super developer friendly product.
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.
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.
The front page says "Earnings are transferred to your bank account on a 7 day rolling basis.".
Wondering when it will work in Canada? Also, how does it work "without merchant account or gateway" ?
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.
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.
Just shoot an email to [email protected]
Will also be waiting for Canada.
Canada +1
Will be waiting for Mexico support, we need something like this now.
Canada +1
I was under the impression that if my website is asking for a credit card number that is later used for a transaction, then it needs to be PCI compliant. Perhaps, it is a Canadian specific, but this need for the PCI compliance is the major selling argument in favor of hosted payment services.
And on a related note - is Stripe available outside of the US?
(edit) Ah, found it.
And on a related note - is Stripe available outside of the US?
(edit) Ah, found it.
> Do I need to be in the United States to use Stripe?
> Yes.
The exact details of PCI are pretty complex, but, roughly the answer is that any system that touches credit card numbers has to be PCI compliant.
This means that if you take credit cards on your website, you need to be PCI compliant. But the exact requirements differ depending on your setup, and what Stripe helps you do is ensure the credit card information never hits a server owned by you. This drastically reduces the scope of your compliance to a simple questionnaire.
As for being outside the US, not quite yet. We're working hard on that front though, so stay tuned.
This means that if you take credit cards on your website, you need to be PCI compliant. But the exact requirements differ depending on your setup, and what Stripe helps you do is ensure the credit card information never hits a server owned by you. This drastically reduces the scope of your compliance to a simple questionnaire.
As for being outside the US, not quite yet. We're working hard on that front though, so stay tuned.
I was first going to say how's that the CC #s from my web form are not hitting my server, but then looked at your Docs - and what you did is ingenious - the form is mine, but it is submitted to your site.
The curl example on the front page is rather misleading. It was the only thing I actually read through on that page and I walked away with an impression that that code snippet needs to go to my server. Just the 2c worth of UX feedback :)
The curl example on the front page is rather misleading. It was the only thing I actually read through on that page and I walked away with an impression that that code snippet needs to go to my server. Just the 2c worth of UX feedback :)
Thanks for the feedback. We'll work on clearer examples.
I'm not sure I understand the PCI implications of using the API. If I use the Create a New Charge example on the homepage in my code, aren't the credit card details going through my server?
*Edit: Nevermind. After reading through the API, I learned you can use a token instead of the card details.
*Edit: Nevermind. After reading through the API, I learned you can use a token instead of the card details.
[deleted]
[deleted]
Looks like a great service. Too bad I can't use it, since I'm a Canadian.
It gets really tiring to see interesting new services launch that refuse to take my money because I live in a different country. I'm hoping that it's something non-trivial that is preventing them from operating in countries like Canada and the UK, and I look forward to using the service once they are able to offer it to me.
It gets really tiring to see interesting new services launch that refuse to take my money because I live in a different country. I'm hoping that it's something non-trivial that is preventing them from operating in countries like Canada and the UK, and I look forward to using the service once they are able to offer it to me.
Respect. Stripe is a very smart company solving a big problem.
This is an incredible product built by a team of amazing developers, solving a serious problem.
I will enjoy watching their success.
I will enjoy watching their success.
Awesome that the payouts are now much faster. That was the one thing keeping me on the fence but will be using it right away for StartupThreads.com
I operate in what the credit card processors consider to be a "high risk industry". It's nearly impossible for myself or my competitors to get a merchant account without a reserve. In other words, for every $1 we charge, the merchant bank holds X% in reserve (until we hit a certain threshold). Thus, if we tried to defraud customers by selling bad products and then "disappearing," the merchant bank could use the reserve to refund customers.
So, with that as a preface, how will Stripe deal with chargebacks? It seems like it would be very easy to set up a scam, e.g. a merchant sells phony inventory and then "disappears" when customers complain.
So, with that as a preface, how will Stripe deal with chargebacks? It seems like it would be very easy to set up a scam, e.g. a merchant sells phony inventory and then "disappears" when customers complain.
Yup, dealing with risk is a hard problem that we're giving a lot and thought and effort to. We rely a lot on online info to verify identity, which gives us some advantages. But yes, we're working hard on mitigating the risks involved with fraud.
https://stripe.com/pricing
There is a $15 chargeback fee.
There is a $15 chargeback fee.
Stripe is simply amazing. We've been using them for many weeks now and things just work. Setting up payments was so much easier.
We've been using Stripe at MixRank, and refreshing how easy it was to set up. This is how easy accepting payments _should_ be. The team is excellent too; they've been extremely helpful so far.
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.
I got this awesome handwritten letter in the mail today from Stripe. https://p.twimg.com/AaoSX5BCQAAx4T9.jpg
I was very excited reading their faq until I realized it's US only service.
Can't wait to see you guys expand internationally. Best of luck.
Can't wait to see you guys expand internationally. Best of luck.
I have a problem with using merchant startups. If they go out of business, what happens to my clients? If I have thousands of clients, I would not want to be forced to get all of their credit card info again (since I wouldn't be storing any of that info).
Although I hate using the big guys, at least I know they will be around in 5+ years.
Although I hate using the big guys, at least I know they will be around in 5+ years.
We'll happily export your card data to another provider if you ever want to move away.
Are you legally allowed to even do that? Do you store card data yourself?
Yes and yes. We are a PCI Level 1 Service Provider. More information on our security practices: https://stripe.com/security
Can you fetch any meta data on a customer's saved card? For example if a single customer has four saved cards you might want to present it as:
* Visa ending in 1234
* MasterCard ending in 5678
Also, when a customer's card is expiring how are they prompted to enter an non-expiring card?
Also, when a customer's card is expiring how are they prompted to enter an non-expiring card?
You can get the type and last 4 digits of the card. Right now, we only allow you to store one card for a customer -- something we'll probably change in the future.
Since we aren't putting ourselves anywhere in the front end of your app, we can't notify your customers when they have cards that are about to expire -- it's something you'll have to choose how you want to communicate.
Since we aren't putting ourselves anywhere in the front end of your app, we can't notify your customers when they have cards that are about to expire -- it's something you'll have to choose how you want to communicate.
Awesome company, we're at Mailgun have been using them for a long time and couldn't be happier.
Stripe looks awesome for small scale business. At large scale, Braintree still has cheaper pricing (http://www.braintreepayments.com/pricing) and the monthly cost is negligible.
Pricing is pretty hard to compare directly between something like Stripe and Braintree. In particular, there is no one clear answer, because it depends on your own mixture of AMEX cards, international cards, rewards cards, etc. We have some medium sized businesses on Stripe who have run the numbers and come out cheaper with us, but that won't be true for every merchant.
Part of what we believe to be valuable here is the simplicity of knowing exactly what your fees will be on every transaction, and in aggregate. There aren't any surprises.
Part of what we believe to be valuable here is the simplicity of knowing exactly what your fees will be on every transaction, and in aggregate. There aren't any surprises.
Quick suggestion... I tried to share on Facebook and didn't get an image. Set this in your <head> so it looks better when shared:
<link rel="image_src" type="image/png" href="PATH TO IMAGE" />
<link rel="image_src" type="image/jpg" href="PATH TO IMAGE" />
<link rel="image_src" type="image/png" href="PATH TO IMAGE" />
<link rel="image_src" type="image/jpg" href="PATH TO IMAGE" />
Something that is really needed, looking forward to the availability outside the states.
Does Stripe let us take our data with us if we want to leave for another processor? If I build a recurring revenue business on Stripe, am I screwed if they hike up their fees by not being able to move the credit card #'s elsewhere?
Yup, we do. Checkout my other answers in these comments.
[deleted]
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
[deleted]
Not to take away from the product, which I think is pretty awesome, but I do foresee a rather sticky issue should the company blow up somewhere down the line; the logo is rather reminiscent of that of my former employer Deutsche Bank's, and I wouldn't put it past the multinational financial behemoth to take notice, with potential financial consequences, especially as Stripe pushes its product internationally. For reference:
http://www.oraclefusionnews.com/wp-content/uploads/2011/07/d...
http://www.oraclefusionnews.com/wp-content/uploads/2011/07/d...
Stripe does not currently have a logo, other than the word Stripe.
Sorry about that, I was basing my comment off the Crunchbase profile (http://www.crunchbase.com/company/stripe) and assumed that was the logo.
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.
Can't wait to see how the international version works.
Is there a processing volume limit? Will Stripe be verifying customer orders?
There are no volume limits. What kind of verification are you talking about? Stripe does offer address verification: if you send the address with your requests, we'll return the AVS response from the credit card network, which tells if that the billing zip codes and street number are a match.
What about sales receipts? Are those generated by Stripe and sent to the user or is it up to the merchant to deliver them?
[deleted]
We don't offer support for emailing your users right now.
How long does it take for a refund to be re-credited to the user's card?
What's the chargeback threshold before an account gets put on hold?
Is there a refund threshold? Eg. 1 out of 4 of our customers are dissatisifed with our product, so we refund 25% of all transactions.
Also, you've created something absolutely amazing. ISO Sales agents across the country are going to be trembling.
Speaking of which, will you have a partner program?
Also, you've created something absolutely amazing. ISO Sales agents across the country are going to be trembling.
Speaking of which, will you have a partner program?
The amount of time it takes fro the refund to be re-credited usually depends on the issuing bank. When a refund happens, we send the refund over immediately and settle it at the end of the day. There are currently no chargeback or refund thresholds, but we'll have to see how that evolves as we grow.
We don't currently have any partner program, but it's definitely something we're talking about. Lots of things are in the pipeline!
We don't currently have any partner program, but it's definitely something we're talking about. Lots of things are in the pipeline!
Amazing product, just curious about which font was used in the stripe logo?
Hope you go international as soon as possible there is a lot of good potential around this. I just hate the way paypal has recurring billing setup, the documentation is not 100% completed in paypal and I had to loose a couple of hours to ge around an error that was saying basically: " there are 1000 things that could go wrong ", the problem is that I was missing a field that I had to submit to them, the docs war not saying anything about it, but with the help of good old Google.
Go stripe
Awesome. I have been waiting to have a better look at Stripe, it sounds so great.
I have a question for someone who might know: how can Stripe operate without requiring it's users to sign up for a merchant account? Do they hold what is known as a 'master merchant account'?
I am just curious as these sound notoriously difficult to get and might explain why it's US only for now, not to mention the AML considerations of letting users sign up and accept payments so simply.
This all just makes what they are doing even more impressive :).
I have a question for someone who might know: how can Stripe operate without requiring it's users to sign up for a merchant account? Do they hold what is known as a 'master merchant account'?
I am just curious as these sound notoriously difficult to get and might explain why it's US only for now, not to mention the AML considerations of letting users sign up and accept payments so simply.
This all just makes what they are doing even more impressive :).
We basically are trying to abstract away all the pain of creating merchant accounts and setting up with separate payment gateways. On the backend, we are partnering with Wells Fargo and First Data to set up whatever accounts are necessary to both get you started immediately while making sure you get all the benefits of a full-fledged merchant account.
Cool. I'm not a US citizen but it's great that you can do this and that Wells Fargo is on board as this is a killer feature in my opinion :).
Excellent API and fast support. These guys are gonna go far.
Good to see an alternative to paypal, but instead of paying 3% to a transaction central, I'll still offer a 5% discount to anyone who pays me through bitcoin.
I tried stripe a couple months ago and I was unimpressed. Mostly it was the pricing ( i think at the time it was 3.9% + 30 cents ) because I was looking to do smaller transactions $4.99 a month subscription.
But I got into the beta anyways and started playing with it. Within 10 minutes a rep was emailing me trying to get more information and that I wasn't ready to give out.
I ended up going with Paypal's micro transaction processing.
But I got into the beta anyways and started playing with it. Within 10 minutes a rep was emailing me trying to get more information and that I wasn't ready to give out.
I ended up going with Paypal's micro transaction processing.
Our account application asks for your personal information (thinks like bank account details, home address, etc.) as part of our automated verification process. Once it gets submitted, we try to verify and approve the application as quickly as possible, hence the quick contact.
Of course, you don't have to submit this application until you're ready. You can save your account on Stripe without filling out the account app, and do as much testing as you like, forever. Once you're ready to process real payments, that is when we'll require some of this information.
Hope that helps explain things.
Of course, you don't have to submit this application until you're ready. You can save your account on Stripe without filling out the account app, and do as much testing as you like, forever. Once you're ready to process real payments, that is when we'll require some of this information.
Hope that helps explain things.
This is awesome. The big question is: how are you going to deal with fraud? Fraud policies false positives is largely what makes people hate PayPal.
I think the difference is customer service, not fraud per se. Customer service will always be our highest priority -- and that means when we do end up in situations where fraud is a concern, we'll work with our users to resolve things quickly.
I don't have anything to contribute other than a thank you to the folks behind Stripe for trying to fix this seriously broken system.
If a Stripe employee is reading this, tiny suggestion: I just shared the URL to stripe on both Facebook and G+. On G+, the nice little blueprint icon showed up as the thumbnail. But on Facebook, no icon at all making the post far less noticable in people's feeds. Just a tiny thing that will help the spreading of the word.
[deleted]
Thanks, fixed.
I'm not a developer, but I am considering selling things through my website and maybe also selling things in person outside any shop. Is there any particular reason I would pay a developer to build this into my site rather than just using Paypal (which I've used for years and had no big complaints with) and/or Square?
You would use Square for your in-person payments (Square, so far, is for brick-and-mortar stores whereas we are doing online payments). But we definitely are targeting developers more currently, so can see why we may not be as easy of a choice for you. We do offer quite a bit of analytics around what you are making and being paid out, and we also give you a viable way to get set up easily with minimal PCI compliance without having to use a hosted payment solution (so customers checking out wouldn't be sent to another website, which I believe PayPal's hosted solution does), so these features may appeal to you.
We're incorporated in Hong Kong. I'm beginning to think we should launch a US subsidiary just to take credit cards...
Stripe was like love at first sight, it was exactly what I was looking for a loooong time, but I can't use it for now apparently :(
Two questions: My company is an LLC and I have a valid SSN, however my bank account is in Portugal, can I still apply for stripe ?
If not, do you have plan to support EU countries like Portugal ? thanks
Two questions: My company is an LLC and I have a valid SSN, however my bank account is in Portugal, can I still apply for stripe ?
If not, do you have plan to support EU countries like Portugal ? thanks
You should email [email protected] for specific things like this.
This looks amazing. @boucher, sounds like support for Canada and the UK is in the pipeline, how about other EU countries such as Germany?
In the meantime, can somebody recommend a (vaguely) similar service in/for Germany, or otherwise an old-fashioned payment processor that's less painful to deal with than others?
In the meantime, can somebody recommend a (vaguely) similar service in/for Germany, or otherwise an old-fashioned payment processor that's less painful to deal with than others?
Germany is definitely on our list, thanks!
Can you share list of countries you expect to be supported "real soon now"?
It would be helpful to know if I should keep an eye on your service, or just forget about you fro another year or two.
It would be helpful to know if I should keep an eye on your service, or just forget about you fro another year or two.
That's great to hear, thanks.
Can someone please explain to me how 2checkout couldn't do this? For example they claimed to be pushed by the card companies to become a "reseller", resulting in the fact that their checkout pages cannot be customized. What gives?
I see the Getting Started developers intro, but I'm having trouble visualizing what this can look like purely from the customers side. Do you have any live implementations you can link to as an example of a Stripe integration?
Stripe doesn't communicate directly with your users, so there is no standard look from a customer's perspective. We're providing the tools to build your own payment forms hosted on your own website. Perhaps in the future we'll look into helping by communicating more directly to customers.
Stripe looks great and is definitely at the top of my list. Does anyone know what name shows up on the customers statement? Is it customizable to something that includes your company name (e.g. Stripeyour_name_here)?
Stripe doesn't appear at all. You have full control over what appears on the statement.
These little touches are awesome. With Auth.net it seems I ran into a character limit with my (not very long) company name, and the beginning was truncated - TopHat became Phat... I tried to get it changed once upon a time, but I gave up due to the pain.
The old 1 month payout schedule was one of the few things holding me back from switching, but now that's it's more frequent, count me in!
One question, can one charge from multiple URLs with a single account?
The old 1 month payout schedule was one of the few things holding me back from switching, but now that's it's more frequent, count me in!
One question, can one charge from multiple URLs with a single account?
You can charge from multiple URLs, but all your data will show up together as if it were for one account. If you want to have multiple accounts for different websites, your best bet currently is to just sign up multiple times (we're working on having subaccounts).
Great, that's fine for my purposes. Thanks!
That sounds great! Can't wait to get started. I've been dreading building out the recurring payments portion of our website, but reading about Stripe is easing the stress. The docs and are excellent and the approach is very sensible.
[deleted]
Stripe looks great and is definitely at the top of my list. Does anyone know what name shows up on the customers statement? Is it customizable to something that includes your company nane (e.g. Stripeyour_name_here)?
It's entirely up to you: there's no mention of Stripe. Most of our customers simply put their domain on the statement.
Been using Stripe for Taskforce for a few months now. Stellar API, stellar service.
Well done lads! Just on their customer service - really great. I'm a novice developer hacking together my first webapp and the people I dealt with at stripe were excellent, very patient and helpful. Best of luck with it.
Goodbye recurly and chargify. You're no longer the prettiest girls at the dance.
Will strip offer hosted page in the near future? We are currently using Spreedly's hosted page for customer to input their credit card info so that we don't have to worry about SSL and other security issues?
We may at some point in the future, but it's unlikely to be one of our short term priorities. Stripe.js does make things easier for you, but you'll still need SSL.
Just curious, how does the gambling industry manage payments? I've been thinking about building a poker saloon and would like to know how to get players to put their money on the table, so to speak.
Any plans for supporting a DBA (doing business as) field as part of the API? Having only one identity associated with
the Stripe account wouldn't cut it for us.
For now, we recommend just setting up multiple Stripe accounts; it's a feature I'm sure we'll add in the future.
In our particular case we would need somewhere between 50 or more accounts, so it's just not feasible. Having it as part of the charge API would be ideal. Glad to hear you're considering adding it as a feature.
echoing the excitement for the international expansion.
Is the TOS(Terms of Service) a work in progress? Currently "not found."
https://manage.stripe.com/tos
https://manage.stripe.com/tos
Sorry about that. https://stripe.com/tos is the correct link. We'll get it fixed.
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?
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?
Thanks for the update. I did have one other question and wasn't sure where to post it here. What's your timeline for a Perl API binding?
We're not working on it right now, but would love to discuss. I'm [email protected] -- want to drop me a line?
Having the sample code right there on the landing page is the most compelling thing for developers, when the customers are developers.
Anyone here use WHMCS? (Whmcs.com) I'm curious if Stripe will work with it since it doesn't send the CC# through the server.
Stripe is going to be huge. Theirs is a MASSIVE market, waiting too long to be disrupted. Can't wait to use the service.
Is this real? Am I dreaming? This sounds too good to be true. Someone pinch me, please. (Is there an app for that?)
looks great, though recurly has met my needs so far, not sure what would make me consider porting over to something new
The difference between Stripe and Recurly is that Stripe is dealing with the full payments stack for you. You don't need a separate merchant account or gateway, and it's just one flat fee of 2.9% and 30 cents per successful charge, including our subscription billing services. As a result, it's often quite cheaper than combining several separate services.
Thanks for the details. Merchant account setup with intuit through recurly was very easy though, we had that setup within a few hours. At this point, sounds like stripe would be cheaper though (~50 paying customers at $40 a month).
off-topic: Stripe looks really nice and I wish I could use it but sadly I'm outside USA. Does anyone knows a service like this that doesn't require a bank account? Let's say I want to charge people in USA but I don't have a bank account in USA, then I would transfer the money to Paypal or something. Any thoughts?
If you're transferring the money into Paypal anyway (and exposing yourself to "the paypal risk"), why not just use Paypal Website Payments Pro?
Are you guys looking for investors?
Question for boucher: Can stripe be used for affiliate payments, perhaps by issuing credits?
Probably best to send an email to [email protected] to figure out specific cases like this.
[deleted]
this looks amazing but i cant use this until you support european/canadian/australian payments. both of the e-commerce stores i run get international orders every week.
I'm all over this as soon as Freshbooks supports it.
Thank you Stripe. We will become good friends.
Please come to Australia! We need you!
I really wish I could use this in EU.
It seems great, until you read the fine print, which I did, in its entirety, and what I saw is quite chilling, in terms of fees, fines, and other undefined costs incurred when things go horribly wrong.
"When a Chargeback is issued, you are immediately liable to Stripe for the full amount of payment of the Chargeback plus any associated Fees, fines, expenses or penalties (including those assessed by the Networks or our payment processors). You agree that Stripe may recover these amounts by debiting by means of ACH debit of your Bank Account associated with your Stripe Service Account, debiting your Reserve Account, or setting off any amounts owed to you by us. If we are unable to recover funds related to a Chargeback for which you are liable, you will pay us the full amount of the Chargeback immediately upon demand. You agree to pay all costs and expenses, including without limitation attorneys’ fees and other legal expenses, incurred by or on behalf of us in connection with the collection of any unpaid Chargebacks unpaid by you."
https://stripe.com/tos
I >do< like the positives of Stripe, but I'd feel more comfortable if I knew how Stripe would handle specific extremes, such as the one about which I had recently asked.
http://news.ycombinator.com/item?id=3039782
"When a Chargeback is issued, you are immediately liable to Stripe for the full amount of payment of the Chargeback plus any associated Fees, fines, expenses or penalties (including those assessed by the Networks or our payment processors). You agree that Stripe may recover these amounts by debiting by means of ACH debit of your Bank Account associated with your Stripe Service Account, debiting your Reserve Account, or setting off any amounts owed to you by us. If we are unable to recover funds related to a Chargeback for which you are liable, you will pay us the full amount of the Chargeback immediately upon demand. You agree to pay all costs and expenses, including without limitation attorneys’ fees and other legal expenses, incurred by or on behalf of us in connection with the collection of any unpaid Chargebacks unpaid by you."
https://stripe.com/tos
I >do< like the positives of Stripe, but I'd feel more comfortable if I knew how Stripe would handle specific extremes, such as the one about which I had recently asked.
http://news.ycombinator.com/item?id=3039782
As you noted in your post, these terms are standard (and, essentially, required of us) in this industry. And as people suggested, chargebacks are not a big deal. They are far less common than people think, and usually they are resolved quite easily; all it takes is good communication.
I appreciate the answers given to my question from several days ago. I appreciate that all of the loopholes need to be covered, using >standard< legalese, most of which will never be needed, but when it is, the situation will be resolved entirely in Stripe's favor, not mine. I appreciate that chargebacks are >usually< not a big deal. My concern is about extremes, particularly those which come out of malicious intent, perpetrated against me, through no fault of my own. With the way that these "one-sided" agreements are structured, it appears to be quite easy for me to launch an attack against a small startup's credit processing account, with the likely result being termination of said account, mostly due to the perception of risk which I will have created in the minds of the people who implement the TOS to which the startup agreed. If I can do this to someone's startup, then someone can do it to mine, and I can't be the only person who has thought of this kind of stuff.
And yet, have you ever heard of this happening? I don't mean to minimize your questions; I think there is some amount of trust involved. We're able to tell the difference between someone running a fraudulent business and someone who is being essentially DOSd. Simply having chargebacks is never going to automatically cause your account to be terminated.
"Simply having chargebacks is never going to automatically cause your account to be terminated."
False: "WePay reserves the right to close or put a hold on any account that has generated a ["a", as in "single"] chargeback." - https://www.wepay.com/about/terms
No one talks about the ugly fine print. It's always "just a formality", until they need to use it against you, and that's exactly the kind of leverage a competitor or an enemy will seek out.
False: "WePay reserves the right to close or put a hold on any account that has generated a ["a", as in "single"] chargeback." - https://www.wepay.com/about/terms
No one talks about the ugly fine print. It's always "just a formality", until they need to use it against you, and that's exactly the kind of leverage a competitor or an enemy will seek out.
Well, to be clear, I'm only speaking about our own service, not WePay. Anyway, I think we've covered the issue here but if you feel like you need further discussion I suggest reaching out to [email protected].
"I'm only speaking about our own service, not WePay."
Really? See: "We can terminate this agreement at any time (especially if you do something bad). Termination is effective immediately. Termination does not alter your liability for processed payments or related chargebacks." at the top of https://stripe.com/tos.
I won't bother with support, because you have not given me any real answer to the scenario which I presented. Your system thus appears to be just as easy to defraud as any other, possibly even easier, so I have no reason to trust an entity which can, and likely will, dip into my bank account to extract all sorts of fees and fines when things do go bad.
Really? See: "We can terminate this agreement at any time (especially if you do something bad). Termination is effective immediately. Termination does not alter your liability for processed payments or related chargebacks." at the top of https://stripe.com/tos.
I won't bother with support, because you have not given me any real answer to the scenario which I presented. Your system thus appears to be just as easy to defraud as any other, possibly even easier, so I have no reason to trust an entity which can, and likely will, dip into my bank account to extract all sorts of fees and fines when things do go bad.
EDIT: removed so as to not hijack another announcement. Was not the intention, just wanted to offer something people thought was useful.
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.
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!
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!
How good Stripe is at Fraud prevention?
AFAIK PayPal claims to be Credit Card Fraud Protection service that happens to process credit cards.
Does Stripe focus on fraud prevention?
AFAIK PayPal claims to be Credit Card Fraud Protection service that happens to process credit cards.
Does Stripe focus on fraud prevention?
We're working hard on preventing fraud.
Do you give "fraud rating" back for the potential transaction?
If yes - I could have used that rating to decide whether to approve the purchase automatically or give it a manual review.
If yes - I could have used that rating to decide whether to approve the purchase automatically or give it a manual review.
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.
So when will your merchant accounts be available?
Just wanted to say you guys were one of the few "startups" I actually gave my email to in the beta page when you announced it. I could care less about the next social app, or next reminder app but as soon as I saw your value proposition, I KNEW I had to be notified when it was out. Thanks for making something that actually solves a crucial problems. This is much much needed, and you guys are definitely on your way to success
[deleted](1)
I think that aside from the lack of support for marketplace, like https://www.wepay.com/developer/usecases/marketplace Stripe is awesome.
Any plans to add marketplace support in the near term?
Also are you guys PCI compliant yet?
Any plans to add marketplace support in the near term?
Also are you guys PCI compliant yet?
We're certified as PCI Level 1 Compliant (the highest level). You can definitely build a market place on top of Stripe. We don't, at the moment, have an easy way for you to take money and then pay it out to other people, but if you're able to handle that step on your own then Stripe can be a great way to collect payments for your marketplace.
Is it on the roadmap for the near future?
Possibly -- it's something we're still talking about internally.
Thank you. Pay pal should be obsolete now.
[deleted]
Bitcoin charges 0.01% @:)
CANADA!!
Looks like the site is down??
2.9% and 7 days. if you are still using it, you are infant in this entire thing.
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.