The attacker can replace the server's response with his own form that pretends to be Stripe's, too. In the end, there's no real defense against phishing.
Flow 1: User visits shop.com, selects some items, hits checkout, enters his credit card details into a form on shop.com, hits submit, gets emailed a receipt.
Flow 2: User visits shop.com, selects some items, hits checkout, is redirected to a form on processor.com, enters his card details, hits submit, gets email a receipt.
Now flow 1 and flow 2 could be the same internally if the form in flow 1 was actually from processor.com, just embedded into an iframe displayed on shop.com. But the key is that the user has no idea if it is or not.
The form in frame 1 could be in an iframe from anywhere, or it might actually be embedded directly into the page and posting, again, to anywhere. You just have to take it on faith that shop.com hasn't been compromised, and isn't now sending your details to malware.com.
In flow 2, you only enter your details into a form on processor.com; you no longer need to worry if shop.com has been compromised, you just need to verify that you're actually at processor.com, and not proccesor.com or whatever.