You are welcome. This forum has become a good hobby when waiting at restaurants or having a sick day.
First, let me tweak my earlier post. I looked this up and the overlap between cardholder data and billing information is only the cardholder name. In my earlier post I appended "address, etc." Misfired memory there. Too much PCI documentation relative to working memory brain cells. The js form is either SAQ A or SAQ A-EP, depending on the implementation method you use. You can look at the docs. I'm going to dig into that one a little more myself. I'm not understanding how the billing information works between the 2 options. It looks like the hosted form does it differently.
In regards to the "originates directly and only" and the payment amount, that is an obvious something that sticks out. The elements will all ultimately come from authorize in a hosted form, but from their end they have to vet it. It would be similar to the CSS I mentioned.
As a necessity they take the payment amount. It is a relatively constrained thing to do, meaning that youโre just looking for numbers. In that case they can economically implement a thorough sanitization on their end, vet the amount and display it on the form. The complexity goes up exponentially with mere CSS, and when you put in the mix having a userโs form post values that can potentially have every character on the entire keyboard, including programming scripts, it seems to me to just be impossible.
Here are some snippets from the PCI SC documentation:
โPayment forms should be developed to avoid the inclusion of any third-party content, or to restrict any third-party content to only that which has been thoroughly vetted and is trusted. Any third-party content (images, scripts, or other content) included on a payment form is an opportunity for an attacker to silently steal CHDโ
โAttacks have at various points in history been executed from images, style sheets (CSS), and other HTML elements using browser content-type sniffing.โ
From the perspective of authorize, we are all third parties. These snippets more explicitly refer to paid service providers, but it is still the same.
This is a quite interesting question. Everything Iโve said regarding how authorize does things is obviously speculation, but it seems kind of clear cut to me. I have some unrelated questions to ask a banks compliance affiliate and Iโm going to run this by them while Iโm at it. The docs are not as explicit as I wish they would be in defining what an โelementโ is, nor are they in giving clarity of what originates from what party.
Everything Iโve seen so far in their docs shows SAQ A as being pure redirect or pure iframe with a redirect. Every single doc they have that shows information posted from the merchant to the gateway payment form as SAQ A-EP. They term this โdirect postโ. What you are describing is a hybrid and the situation isnโt so clear cut.
