[Alupis]

That's not how they pitched it to us - and I asked for clarification multiple times because of how absurd the proposal was for a well established eCommerce site. Sending customers off-domain for a payment is not something we were willing to do for a normal credit card checkout flow.

Even "hosted fields" is absurd (and by that I assume you mean an iFrame you embed), and would require redesigning significant portions of the checkout process.

That, coupled with their refusal to even match our existing rates, was really off-putting. The sales people made little effort to understand our business and pain points - they just wanted to talk about how great Stripe is and all the AI stuff they do.

[larrik]

"hosted fields" are really just a fancy CC # widget (with postal code and exp built-in, when appropriate). If you use them, the annual PCI attestation becomes a checkbox instead of a giant form.

[rstupek]

actually hosted fields isn't an iframe but replacing the cc detail fields with stripe fields and adding some javascript which tokenizes the cc details so you never see them

[__float]

You don't have to use "hosted fields", but it does mean you have significantly increased requirements regarding PCI compliance (SAQ D vs the much simpler SAQ A, for example).

[Alupis]

Not necessarily true. It depends how your site is setup.

Users of eCommerce platforms generally will be SAQ-A since they are not the ones controlling the system which handles CHD. This covers platforms like Shopify, BigCommerce, 3dCart, Volusion, etc, where the platform itself must be PCI compliant on their own, separate from whatever PCI level you are compliant with.

If you self-host, such as Magento, XenCart or some custom implementation - then yes you will be SAQ-D.