Live data from Hacker News

Stripe: instant payment processing for developers

stripe.com

221–230 of 369 posts

Re: Stripe: instant payment processing for developers

#221

Earlier quoted context omitted.

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.

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

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

Re: Stripe: instant payment processing for developers

#222
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...

Re: Stripe: instant payment processing for developers

#223
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?

Re: Stripe: instant payment processing for developers

#225
post #222

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

Stripe does not currently have a logo, other than the word Stripe.

Re: Stripe: instant payment processing for developers

#226

Earlier quoted context omitted.

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

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.

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.

Re: Stripe: instant payment processing for developers

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

I would love to see someone drag it kicking and screaming outside of the US. :(

Re: Stripe: instant payment processing for developers

#228
post #80

Earlier quoted context omitted.

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

The exemption you are talking about is not legitimate, because of the way browser security works.

Re: Stripe: instant payment processing for developers

#230

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…

>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

Post reply on HN