Live data from Hacker News

Stripe: instant payment processing for developers

stripe.com

191–200 of 369 posts

Re: Stripe: instant payment processing for developers

#191

Earlier quoted context omitted.

> 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…

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 t…

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.

Re: Stripe: instant payment processing for developers

#192
post #179
post #28

Earlier quoted context omitted.

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 t…

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 support@stripe.com

Re: Stripe: instant payment processing for developers

#193
post #188

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.

Re: Stripe: instant payment processing for developers

#194
post #165

Earlier quoted context omitted.

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.)

Navigation menu doesn't work in IPad.

Re: Stripe: instant payment processing for developers

#195
post #5

Stripe pretty much takes payment processing kicking and screaming into 2011. Merchant accounts are a serious drag. I've opened a few and they've been nothing but headaches (especially if you're young—nobody trusts you.) Couple that with getting a gateway account, dealing with credit checks, monthly fees, monthly minimums, slow people in the payments industry, PCI compliance... Stripe takes payments and put them behin…

> 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…

    Q: Do I need to be in the United States to use Stripe?
    A: Yes.
--> FFFFFFUUUUUUUUUUUUUUUUUUUUUUUU

Would you finally be the one to tell us what the hell is the problem with non-US customers?

Re: Stripe: instant payment processing for developers

#196

Earlier quoted context omitted.

> 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…

Q: Do I need to be in the United States to use Stripe? A: Yes. --> FFFFFFUUUUUUUUUUUUUUUUUUUUUUUU Would you finally be the one to tell us what the hell is the problem with non-US customers?

Unfortunately, there are just a lot of regulations when dealing with payments across international borders.

Re: Stripe: instant payment processing for developers

#197

Earlier quoted context omitted.

It's mostly just a custom thing I wrote. The CSS is mostly taken (with permission) from Jeremy Ashkenas' sites (see Backbone, CoffeeScript, etc.)

Navigation menu doesn't work in IPad.

I think it's fixed in iOS 5, but yeah not an ideal answer.

Re: Stripe: instant payment processing for developers

#198

Earlier quoted context omitted.

Q: Do I need to be in the United States to use Stripe? A: Yes. --> FFFFFFUUUUUUUUUUUUUUUUUUUUUUUU Would you finally be the one to tell us what the hell is the problem with non-US customers?

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.

Re: Stripe: instant payment processing for developers

#200

Earlier quoted context omitted.

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).

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…

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.
Post reply on HN