Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe: instant payment processing for developers

stripe.com

Post reply on HN
Print view View original

71–80 of 369 posts

Re: Stripe: instant payment processing for developers

#71

Post by boucher »

seiji wrote: post #55
boucher wrote: post #32

Earlier quoted context omitted.

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?

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

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.

Re: Stripe: instant payment processing for developers

#72

Post by boucher »

debaserab2 wrote: post #37

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

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.

Re: Stripe: instant payment processing for developers

#74

Post by boucher »

Erwin wrote: post #66

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

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.

Re: Stripe: instant payment processing for developers

#75

Post by yahelc »

Erwin wrote: post #66

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

They require that you host your payments in HTTPS.

https://stripe.com/help/ssl

They themselves are PCI Compliant. https://stripe.com/security

Re: Stripe: instant payment processing for developers

#77

Post by whichdan »

saikat wrote: post #60
whichdan wrote: post #46

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

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

Very cool. Is there no underwriting process then? That seemed to be one of the biggest steps in getting setup with Braintree.

Re: Stripe: instant payment processing for developers

#78

Post by edash »

philipsflat wrote: post #61
edash wrote: post #40

Earlier quoted context omitted.

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 Erin@braintreepayments.com . She'll help you out.

Thanks so much, we'll do that!

Re: Stripe: instant payment processing for developers

#79

Post by boucher »

ryanwaggoner wrote: post #73

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.

Re: Stripe: instant payment processing for developers

#80

Post by tptacek »

Erwin wrote: post #66

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

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.

Post reply on HN