[phereford]

I've worked with similar organizations that want the transaction on their site due to all the reasons mentioned in the comments.

There are providers that use JavaScript to allow you to take payment information on your platform but never let the sensitive details hit your server. I believe this removes your platform as an attack vector for leaking credentials. The only locations that have traces of that information are the browser and the payment provider.

[makomk]

Which presumably is why the attackers here are injecting their own client-side JavaScript that sends a copy of the payment information to the attacker. Even if the business never sees a copy of the sensitive information, their server can still be made to serve up malicious code that does.

[phereford]

Yep. I completely agree. I hadn't had my early am coffee yet ;)

[Silhouette]

Unfortunately, even if your payment service is hosting the system that processes the sensitive details, there's always an element of vulnerability on the merchant's side if they are hosting the rest of the site, simply because a compromise could redirect customers to a hostile alternative site to collect those sensitive details. At that point, they're really no better off than a completely fake site that never had any real relationship with a payment service at all. Merchants should always be serving their own pages securely for this among other reasons, even if they are never intending to receive sensitive payment credentials.

[phereford]

You are absolutely right.