4 ms·
> not wanting to redirect or otherwise interrupt the normal order process of my site with another company's (branded) checkout form just to handle credit card p
by powertower 15y ago
> not wanting to redirect or otherwise interrupt the normal order process of my site with another company's (branded) checkout form just to handle credit card payments.
That's a restriction only for the free accounts.
With the Pro account ($30/month) you use the API and your customers never leave your site.
- michaelschade 15y agoThanks, I wasn't aware of that. Edit: I was looking at it more and, as MichaelGG pointed out, I think it still means that you have to handle the credit card on your server and be PCI compliant.
- MichaelGG 15y agoBut doesn't that API require you to submit the card number to them from your server and hence makes you have to do a ton of PCI compliance work?
- aysar 15y agoWould like to know more about this- i thought the whole point of it was that you didn't have to deal with PCI... Edit: i just checked; https://www.paypal.com/pcicompliance https://www.paypal.com/pcicompliance It looks like Paypal takes care of PCI compliance only if you use; PayPal Website Payments Standard, Email Payments, or Payflow Link. Otherwise you're on your own.
- dangrossman 15y agoIt's common sense once you boil it down to this: If someone's credit card number hits your server at any time, you are liable for a proper level of care for that information. The proper level of care in this case is set by the payment industry in the form of PCIDSS (the Payment Card Industry's Data Security Standards). So setups where the data goes through you, you're on the hook. Where you're sending someone to an external site to pay, in a frame or otherwise, then you're not. A quick glance at the implementation guide for any payment system, present or future, is enough to know who's on the hook for PCIDSS just by seeing whether the card number's gonna get POSTed to your server or someone else's.
- lsh123 15y agoI think the better description would be: You are on the hook as soon as your code touches credit card data.
- yangez 15y agoIs this true? I was under the impression that if we used Stripe's javascript function to tokenize credit cards, we get to skip a lot of PCI compliance stuff we would otherwise be responsible for.
- saurik 15y agoSome discussion: http://stackoverflow.com/questions/4219636/pci-compliance-and-ajax http://stackoverflow.com/questions/4219636/pci-compliance-an...
- lsh123 15y agoYou might want to talk to your PCI QSA to get a professional opinion. My views are explained here: http://news.ycombinator.com/item?id=3332001 http://news.ycombinator.com/item?id=3332001 Said that, you might want to think beyond PCI. Security is as strong as your weakest link and you might want to "play" in your mind a few scenarios: what if there is an XSS attack? what if your employee goes "rogue"? what if your server is hacked? Then you will need to decide what is important for you and how much risk you are willing to tolerate. Different solutions (Stripe + javascript, WePay + iFrame or redirect, PayPal, traditional payment gateway, etc.) will give you different upsides and downsides in usability, security, international support, price, customer support experience, ... There is no silver bullet :)
- airlocksoftware 15y agoI used to work as a low-level tech for one of the largest PCI compliance providers. For smaller merchants (I think less than 20k? transaction per year) there's 4 levels of compliance: A, B, C, and D. A is for merchants who redirect to another site or use an iframe (like paypal). B is for merchants who use a dial up terminal. C is for any merchant who accepts credit card information electronically (i.e. an internet connected terminal or a website with no redirect / iframe). D is for anyone who stores credit card information. A & B just require you to fill out a self-assessment indicating you're aware of the rules and following them. C & D both require "scans", probably of your website or server (at least a couple hundred dollars, if not more).
- powertower 15y agoRequire? No. Unless you do more than 20k CC transactions/year, OR store CC numbers directly on your server, no one is going to require much of anything from you except one of those fake website scans.
- MichaelGG 15y agoRight, there's always the option to just ignore PCI and live with the possibility of being fined if something goes wrong. But you're right, that's not always a big risk.