While I can go for hours talking about the actual technical risks here, I'm less firm about how a PCI auditor is going to interpret any specific thing you do. We don't PCI audit; we find and fix vulnerabilities in software.
Having said that:
The technical risk of you hosting HTML that POST's via HTTPS somewhere else is that any input that influences any dynamic component of the page on which the form is hosted could alter the "action" attribute of the form to point somewhere else, without it even being detectable in the page source.
You can say that about any chain of pages, including in-app page flows all the way through Google SERPs, but it's a particularly severe risk on the actual page that asks for the credit card number, since there are no macro-level cues a user has as to whether the page is valid or not.
OWASP is making more noise about things like "insecure redirects" for, among other things, this exact scenario. Expect the "host the HTML FORM that asks for the credit card number and send it to the payment processor" technique to run afoul of PCI DSS any year now.
Having said that:
The technical risk of you hosting HTML that POST's via HTTPS somewhere else is that any input that influences any dynamic component of the page on which the form is hosted could alter the "action" attribute of the form to point somewhere else, without it even being detectable in the page source.
You can say that about any chain of pages, including in-app page flows all the way through Google SERPs, but it's a particularly severe risk on the actual page that asks for the credit card number, since there are no macro-level cues a user has as to whether the page is valid or not.
OWASP is making more noise about things like "insecure redirects" for, among other things, this exact scenario. Expect the "host the HTML FORM that asks for the credit card number and send it to the payment processor" technique to run afoul of PCI DSS any year now.