Posts: 17
Registered: ‎12-30-2018

Re: Default Address for Hosted /Manage

I've looked at this somewhat. I'm not sure it will work in my environment.


I'm not programming in a web page, on a web server, but in a traditional POS application. I currently create a profile, get a token, launch a browser to let the operator enter the credit card information, and then get the payment profile ID from, with a GetCustomerProfileRequest from my POS application.


What you are saying is that I will need to get the nounce via page on my webserver, and somehow get that data back to the POS application on a different machine, to continue the transaction. Or, I will have to somehow get the address data from the POS system to the web server, and then build the call to create the payment profile completely on the web server. Very complicated. Is there somewhere in the call to this javascript that I can put the address, so that it is passed back to the handler with the Nounce?


So, this appears to be the only way to avoid the operator retyping or copying/pasting the address and zip code into the Hosted Payment Page? There is no way to supply the default information ahead of time, and no way to edit it after the fact, without also having the sensitive card information, or working completely in a web server?


I think I may have to have my application just display a window with the address information, and let the operator copy and paste it. It seems like a very Mickey Mouse solution.

Trusted Contributor
Posts: 458
Registered: ‎11-05-2018

Re: Default Address for Hosted /Manage

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.