You need a US bank account to receive transfers in USD. It will be great when Stripe allows non-US companies to receive USD without requiring conversion to another currency.
They seem to represent everything right in the field of payment processing, and their office vibe is extremely chill-- I just got rejected for a job there after a few weeks of really promising interviews, and I've gotta say it stings a lot to be told you don't fit in a company full of cool people.
In as much as Stripe allows you to customize the colors of the Checkout modal and add your company logo, Checkout helps create a smooth, trusted, "first-party-ish" experience. The modal behavior however detracts from this quality - it hints to the customer that a third-party is involved. On my most recent project, feedback from users to this effect caused me to go and make my own form using stripe.js instead (pretty easy :) but means giving up the benefit of Checkout's thoroughly thought-out, always-getting-better, broadly-tested UX :( ). I have also observed others asking for an inline version of Checkout in #stripe on freenode.
Edit: also I was doing some digging on the subject, and there is an opinion (not condoned by Stripe) that Checkout is "more PCI-compliant" than Stripe.js because the iframe is sourced to Stripe, and Stripe is PCI-audited. Therefore having an inline option for Checkout might please folks wanting the inline UX without giving up the potential upside of Checkout with regard to PCI-compliance.
I've only used Stripe for about a month. Stripe.js seems like the right solution in this case; but, I'm curious to know how the UX is improving. Aside from the addition of payment providers (e.g. Alipay), the UI/UX doesn't seem to change much. I don't really see anyone making drastic changes to payment forms.
There is but a small niche between "project is not important enough to care about a modal vs. an iframe" and "project is SO important that I carefully style my own payment form." A dead-easy Stripe-built solution appeals in this small niche; however I'm not going to introduce a third-party dependency in this case - at that point I'll just make my own form - which is what I did :)
(Is my memory wrong that Colin's tool predates the launch of Checkout? Perhaps even Colin's tool inspired Checkout to a small extent?)
But.. Payments is more than about developers. It's the finance people that reconcile, the budget that pays for it's transaction fees, the customer support when a transaction goes wrong. My point is ease-of-integration is just one part and for large companies, an insignificant part. Sometimes this feels lost and it's all "wahey, JSON API".
i had horrible experiences with an "industry standard and cheaper provider"
i once spend several hours in a cusomer care help center of my payment provider to figure out why and how they broke our checkout. this was in the middle of the night obviously because of timezones and the people on the other end where non-technical.
not saying this couldnt happen w/ stripe or that my payment provider was the best alternative (it was before stripe existed and was a european provider) but still…
i agree w/ you that payment providers are more than JSON API but from my perception stripe does a good job in those areas as well
You've never integrated an old-school payments API have you? Integration is not insignificant. Having spent developer/weeks wrangling XML (I'm looking at you authorize.net), being able to do the same in an afternoon is life changing.
Now, I'm a loyal customer and recommend them to everyone. Sure, they cost more, but it's worth it.
Yeap, done a ton of them. Alot get it right, some wrong. Many of them have caught up. The biggest problems you can run into are usually support orientated which I rarely see anything about here.
That's absolutely true and I think support is an area that they are going to invest in soon. I had a client that wanted to process $250k/year with them, but didn't sign up because they couldn't get someone on the phone. Not even sales, let alone support!
...and thats when it becomes a normal payment provider. I worked for one that invested far more in its call centers than its APIs. It actually worked very well for them!
I completely agree that support matters. What I like about both Stripe and Braintree is that both have great documentation that make integration super-simple. (I liked their docs so much that I blogged about them: http://dev.clintonblackburn.com/2015/07/24/good-documentatio...)
I have integrated with CyberSource and PayPal. CyberSource took a week. PayPal took a couple days. Braintree and Stripe? A few hours!
Besides this, their reporting (via API) is simple to use and integrate with our analytics pipeline. By contrast my analytics team spent days on the phone with both CyberSource and PayPal.
Finally, the rates aren't that bad. If you have significant transaction volume, you can negotiate a rate comparable to the "legacy" payment processors. Both the sales and support teams have been quite helpful.
When you are a working on a side project 10-15 hours a week and need to integrate payments, being able to integrate stripe in a few hours is a game changer. Imagine having only 10-15 hours a week to work on something but spending 40 hours just on payments.
I'm one of Stripe's cofounders. It's about the functionality, not the promotion. The whole premise of Stripe is that a richer, more powerful stack of APIs -- rather than the bare-bones electrical outlet to the credit card networks that existed before -- is a better solution for most businesses. Whatever success (and any recognition) we've had to date follows from that; not the other way around.
I wish something like Stripe existed in 2004. If it had, we wouldn't have had to start the company...
Agreed. Payments has been a quite stinky industry with lots of dodgy monopolies (see government payment providers for particularly bad examples). I'd just like to see a more balanced debate on payments. Its a very busy industry with plenty of niches which Stripe clearly fits, but it's also a very boring industry. I get surprised seeing this heavily promoted on a site I use for opinion and news.
Uh, frankly, all you are offering is yet another credit card gateway. There are large countries out there where credit card usage is much much lower compared to debit cards.
So it's cool you're translating stuff, but none of it matters if customers can't pay. It's 2015, you need PayPal level of compatibility.
I'm a huge fan of Stripe and the benefits of using it, although I've had close to 40% of all international customers receive a 'your card was declined error'.
I've had to ask them to call up their bank/card provider and request for the restriction to be removed.
Is Stripe's ease of onboarding/getting started causing such a high rate of flagged transactions? What's going on behind the scenes between banks and payment services providers and is this something that could be improved in the future?
I’m sorry to read of your problem, but also glad to know it’s not just us. The last time I checked, we were losing more subscribers to mysterious international card failures on Stripe than all other causes (including deliberate cancellations) put together, but I’m talking about a small side business here so I wondered whether we’d just been an unfortunate statistical anomaly.
I did contact Stripe support a while ago to ask about this, but they didn’t seem to know any more than we did and weren’t able to do anything to improve the situation. The best theory we have so far is that given how many of the transactions fail in the second month of a subscription and the greater proportion of international failures compared to domestic, we’re coming in borderline on a lot of US banks’ fraud checks, perhaps because we’re abroad and charging in a different currency. Then when we don’t have the card security code after the first payment, maybe that pushes us over the line. We’re hardly a high risk business generally, though, so it would be interesting to know whether this problem is inherent to accepting international card payments or something more specific to Stripe.
Naturally we’re investigating whether general improvements we could make, such as charging in local currencies or better Dunning management, would improve the success rate. However, it’s hard to make sensible decisions with so little useful data about the cause of the problem, particularly for a business with limited development resources available that we’d rather spend on developing the service itself. In the meantime, I read these anecdotes on HN about businesses aiming for at least 95 or 98 percent retention month-to-month and dream...
This helps so many users around the world trust the e-commerce websites on a whole new level. Hopefully you'll start expanding to more countries soon without limits on bank accounts, particularly Eastern European region.
41 comments
[ 3.4 ms ] story [ 91.0 ms ] threador
"Am I not douchey enough for this douchey company"
Edit: also I was doing some digging on the subject, and there is an opinion (not condoned by Stripe) that Checkout is "more PCI-compliant" than Stripe.js because the iframe is sourced to Stripe, and Stripe is PCI-audited. Therefore having an inline option for Checkout might please folks wanting the inline UX without giving up the potential upside of Checkout with regard to PCI-compliance.
(Is my memory wrong that Colin's tool predates the launch of Checkout? Perhaps even Colin's tool inspired Checkout to a small extent?)
I meet industry sales people who are baffled why some companies insist on Stripe despite the cost. HackerNews promotion is clearly a powerful force.
i once spend several hours in a cusomer care help center of my payment provider to figure out why and how they broke our checkout. this was in the middle of the night obviously because of timezones and the people on the other end where non-technical.
not saying this couldnt happen w/ stripe or that my payment provider was the best alternative (it was before stripe existed and was a european provider) but still…
i agree w/ you that payment providers are more than JSON API but from my perception stripe does a good job in those areas as well
Now, I'm a loyal customer and recommend them to everyone. Sure, they cost more, but it's worth it.
I have integrated with CyberSource and PayPal. CyberSource took a week. PayPal took a couple days. Braintree and Stripe? A few hours!
Besides this, their reporting (via API) is simple to use and integrate with our analytics pipeline. By contrast my analytics team spent days on the phone with both CyberSource and PayPal.
Finally, the rates aren't that bad. If you have significant transaction volume, you can negotiate a rate comparable to the "legacy" payment processors. Both the sales and support teams have been quite helpful.
in case of doubt i would act them same
I wish something like Stripe existed in 2004. If it had, we wouldn't have had to start the company...
So it's cool you're translating stuff, but none of it matters if customers can't pay. It's 2015, you need PayPal level of compatibility.
I've had to ask them to call up their bank/card provider and request for the restriction to be removed.
Is Stripe's ease of onboarding/getting started causing such a high rate of flagged transactions? What's going on behind the scenes between banks and payment services providers and is this something that could be improved in the future?
I did contact Stripe support a while ago to ask about this, but they didn’t seem to know any more than we did and weren’t able to do anything to improve the situation. The best theory we have so far is that given how many of the transactions fail in the second month of a subscription and the greater proportion of international failures compared to domestic, we’re coming in borderline on a lot of US banks’ fraud checks, perhaps because we’re abroad and charging in a different currency. Then when we don’t have the card security code after the first payment, maybe that pushes us over the line. We’re hardly a high risk business generally, though, so it would be interesting to know whether this problem is inherent to accepting international card payments or something more specific to Stripe.
Naturally we’re investigating whether general improvements we could make, such as charging in local currencies or better Dunning management, would improve the success rate. However, it’s hard to make sensible decisions with so little useful data about the cause of the problem, particularly for a business with limited development resources available that we’d rather spend on developing the service itself. In the meantime, I read these anecdotes on HN about businesses aiming for at least 95 or 98 percent retention month-to-month and dream...
Unfortunately, I found a few issues: http://imgur.com/vZbheUP
1) The Zip-Code lookup is GREAT, except it looks up the town name, not the 都道府県 (prefecture) like it should.
2) The prefecture is in english, not Japanese
3) The Country names are also in english, not Japanese
4) Was hoping to see auto-kana support for Japanese names: https://github.com/harisenbon/autokana ;)
Overall, looks amazing, and awesome that you're getting ready for a full launch in Japan.
* Running in IE11 on Windows 7 (Japanese)