The book describes techniques that Stripe could use in developing their own iframed credit card form. I'd only trust a solution from them directly.

That doesn't make any sense, because the whole point of PAYMENTIFRAME.COM is that you don't trust Stripe.

Colin implemented this because besides credit card numbers, he was unwilling to give Stripe control over his website. Colin's users trust him with things that are much more sensitive than credit card numbers.

People trust Stripe. I think the issue here is Javascript and origin-policy and relinquishing control. When Stripe releases their version of STRIPEPAYMENTIFRAME.COM as an iframe solution then this can go away. I believe Colin mentioned a need for this now rather than waiting for Stripe.

Interesting side note: Yes I know it's only meant to be a demonstration site but PAYMENTIFRAME.COM is using Google Analytics. Oh HAI GA...what's my Security Code again? Just needed a nice chuckle before I head back from lunch.

Colin trusts Stripe to collect credit cards. He does not trust them for anything else. Embedding the form on a page on TARSNAP.COM trusts them for everything that can happen on any web application on the same domain.

Did my comment not cover something?

That's great for Colin. But he should describe the steps he took to host his own iframed Stripe form. Not encourage others to blindly copy/paste an <iframe> tag pointing to his domain onto their website.