Sorry if I misunderstand. Aren't you(paymentiframe) processing the form which is touching the data and then passing the data onto Stripe via their API?
The iframe uses Stripe's javascript to send the card details directly to Stripe's servers -- the only thing which hits the tarsnap server is a token which Stripe returns (and nothing at all goes back to the server hosting the iframe).
As I point out in my blog post, what the networks care the most about is ensuring that there aren't months or years worth of cards stored anywhere which might leak out. Having a site get compromised and a few days of cards stolen is orders of magnitude less important.
I think the point was frustration over the disconnect between PCI rules and reality, that there's no difference in security between self-hosting the form action (over ssl, sending the cc info to the payment processor, and getting a confirm that way), compared to hosting an iframe and "not touching" credit card data. A compromised webserver means the iframe can be compromised so that the card details do hit your server.
If the iframe that you host is compromised, you have no idea where that info is being recorded. The fact that it doesn't touch your server doesn't ensure that your site isn't leaking numbers.
I loved how you wrote that! Whenever people talked about stripe I always thought: Stop, wait! What if your server is compromised? You can do any change to stripe.js you like using malicious injected code.
Many people would just handwave that away, but you write it perfectly clear and give the reason why what stripe does still helps:
It basically just avoids the PCI checks without being secure ;-) No, you wrote that it avoids having you inadvertently store the data.
More people should write about obvious security holes so clearly and logically correct like you do
