Showing results for 
Search instead for 
Did you mean: 

Default Address for Hosted /Manage

I have an integration based on using the hosted /manage page (or the /addPayment page, I can use either). The last issue is that I need a way to default the address for the new Payment method, as I can't have the client reentering the address that is already in our system. I've seen posts, some dating back as far as 2012, requesting this feature. The only thing that some have said is that the /manage page should work, if the Shipping address has been created. I tested this, using the <shipToList> section of the create profile call. When I get the token and go to the Add Payment Method page, the address is still blank. The only time I've see the address defaulted is when I'm adding a second payment method for the customer.


Is there any solution for this? If so, please be specific on what I need to do to provide the address.


Thank you.


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.

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.

Thanks for post

Thanks for sharing more info