Live data from Hacker News

Accepting payments is getting harder

medium.com

1–10 of 125 posts

Re: Accepting payments is getting harder

#4
I always recommend people build their payments on Spreedly (https://spreedly.com/).

It checks off the boxes for minimizing PCI scope; you store no payment information, and collect none on your website either. You can either do a transparent redirect (your payment form points to a URL on their domain, which redirects back to your site with a token) or an iframe.

Once you collect payment information, which they tokenize and store, you can run charges/auths/refunds against it using any of 81 different payment processors and gateways. Balanced one day, Stripe the next, and whatever startup is popular after them in a year -- without changing any of your payment code.

Re: Accepting payments is getting harder

#6
> The worst offenders however are the requirements that some businesses simply cannot comply with unless they have some serious cash laying around. Examples of this are

>> Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

> and

>> Is external penetration testing performed per the defined methodology, at least annually, and after any significant infrastructure or application changes to the environment (such as an operating system upgrade, a sub-network added to the environment, or an added web server)?

Have you ever had a penetration test done? They basically run a load of OSS automated tools, generate a PDF report, and then charge you $1000s. It gives you no real insight and reveals nothing unless you've been a total noob. Why is this so expensive?

Broadening of PCI scope + needlessly expensive compliance = Smells like a large opportunity.

Re: Accepting payments is getting harder

#8

I always recommend people build their payments on Spreedly ( https://spreedly.com/ ). It checks off the boxes for minimizing PCI scope; you store no payment information, and collect none on your website either. You can either do a transparent redirect (your payment form points to a URL on their domain, which redirects back to your site with a token) or an iframe. Once you collect payment information, which they token…

Does anyone know if using transparent redirects actually waives your responsibilities for PCI compliance? Even though the credit card details aren't sent to your backend, they are still collected on a form hosted on your infrastructure.

If your servers are compromised and malicious JS is added to your payment form, couldn't an attacker siphon credit card details via AJAX? It seems like the PCI documentation always uses terminology like "sites that collect credit card data", which I think sounds broad enough to include sites that use transparent redirects.

Re: Accepting payments is getting harder

#9

> The worst offenders however are the requirements that some businesses simply cannot comply with unless they have some serious cash laying around. Examples of this are >> Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). > and >> Is external penetration testing performed per the defined methodolog…

We went through a SAQ D Service Provider 3.0, and paying for an ASV didn't hurt nearly as much as filling out that 80 page questionnaire... In fact, it reminded us apply some recent CVE's to our system before taking it to production. We used Comodo HackerGuardian which is $250/y, so you don't have to pay $1000s.

Re: Accepting payments is getting harder

#10
Good. There's no love lost between me and companies that make significant money doing PCI assessments (they tend to be the bottom-feeding remora of the infosec economy), but the one criticism you could not level against the PCI certification program over the last 10 years is that it was too hard to get certified.

Use Stripe. Move on.

Post reply on HN