If I remember how they worked (last did stripe integration a ways back), the script instruments your form's submit event to do an (ajax if possible) POST to stripe's server, which processes everything, and returns back a (merchant specific) "token" representing a redeemable charge to the customer. The form is then posted to your server, but all it gets is the "token", which it can then use your private merchant key to redeem behind the scenes with their server.

So you get an anonymous "charge" token that you can revoke if a later part of the checkout process fails, and CC data never touches your system.

(I think the markup for that was a little bit different than what was posted above though).

Correct, and the big reason for that is it means you don't have to be PCI compliant since the card never touches your server, only stripes. That's why Stripe blew up, Paypal had no such offering for allowing you to use your own checkout form but not have to pass the card through your server.

Not true, PayPal Payments Pro offered that.

That product seems to have a marketing problem. I've heard plenty of PayPal horror stories over the years, but this thread is the first time I've ever heard of Payments Pro.

Not exactly, the Paypal transparent redirect one still bounces you through paypal's URL; the Stripe one never leaves your domain.

I think they did eventually. I remember trying to use Stripe for a project during college (2012ish) that involved building a website with a REST integration in C#. My rtfm'ing skills were much worse back then so I could be wrong, but yeah, you had to do a bunch of server-side implementation and make calls to their API. It seemed quite challenging to me at the time, but looking back, it really wasn't. They've gotten rid of that extra step now though. You can just drop in the javascript and their html form with api keys and you're ready to go.