Default Address for Hosted /Manage

[jheymann]

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.

[brianmc]

One option, and I haven't had a chance to try this so you'd need to test it, would be to use the hostedProfileBillingAddressOptions setting (read about it here https://developer.authorize.net/api/reference/features/customer_profiles.html) to not show the billing address when you collect the card details and then update the profile with the billing address you already have in your system, using https://developer.authorize.net/api/reference/index.html#customer-profiles-update-customer-payment-p...

Another option would be to use Accept UI to collect the card details (https://developer.authorize.net/api/reference/features/acceptjs.html#Using_the_Hosted_Payment_Inform...) and then take the secure token and create the customer payment profile from that, again using your previously captured address info.

Hope this helps,

Brian

[jheymann]

Thank you for your reply.

I think there are some issues with it, however. If I set the options to not require the address, doesn't it just check that the card number passes the check digit test, and it doesn't actually check to see if it is a valid card, or anything else? IE, it doesn't test the security code? Perhaps I'm reading it wrong.

With your second accept.js approach, doesn't this require the person entering the informatino to process an actual payment, rather than just enter the card #, expiration date, and cvv code?

Also, I don't know if you work for Authorize.net or not, but can you tell me why this is such a major issue? Why can't we specify a billing address when we create the customer profile, or provide default billing information when we create the hosted payment page token, or pass default billing address information in the POST to the hosted payment page? It seems like any of these three options would be trivial to implement for Authorize.net, they are available from most of the competitors, and they have been requested for over 6 years. Is there some reason why Authorize.net refuses to implement this capability?

[brianmc]

Hi there,

it's actually the validation mode setting (live or test) that determines whether a card validation is done at the point of creating the profile or not.  Bear in mind though your payment form requirements will get checked there so make sure those are unset for address as well.

Accept.js is completely decoupled from any actual transaction, all it does is tokenize card details, so once you have that payment nonce you could use it to create a profile, create a recurring subscription or make a one-time payment, that opaqueData value can go anywhere that payment details go in our API.

On the last point, you probably know that you can do exactly as you mentioned, ie supply default address to our hosted payment page (Accept Payment) just not our hosted profile page (Accept Customer).  Unfortunately I do not have a good answer as to why that has not been done yet other than to say we of course have many more requirements and product requests than we do engineers.  As I say not a great answer but hopefully as a software developer you understand the situation.  We do have this request in our Ideas forum and I can see it got marked as Accepted yet I think there was misinterpretation on our side as to the request.  Go ahead and upvote and I will have the status updated back to Under Review:  https://community.developer.authorize.net/t5/Ideas/Ability-to-set-default-billing-information-in-a-C...

Appreciate the feedback.

[jheymann]

OK, your first idea doesn't seem to work. After spending several hours getting the calls to work, I'm left with it saying that the <payment> section isn't allowed, and when I remove it, it says <payment> is required. What I was doing was to do a GetCustomerPaymentProfileRequest, take the <PaymentProfile> section of that call, change the information for the <address> and <zip> keys, remove the <customerProfileId> section (which shouldn't be in that place in the first place), and then send it back in the UpdateCustomerPaymentProfileRequest call. The error is "the element <paymentProfile> has invalid child element <payment>...

The actual call is:

<updateCustomerPaymentProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name>5d9gM7LT</name>

<transactionKey>86aQZ4n6U4T8gx5L</transactionKey>
  </merchantAuthentication>

<customerProfileId>1917035179</customerProfileId>
  <paymentProfile>

    <billTo>

      <address>1345 W. HOBSON WAY            </address>

      <zip>92225-    </zip>

      <country>USA</country>

    </billTo>

<customerPaymentProfileId>1830481448</customerPaymentProfileId>

<payment>

  <creditCard>

    <cardNumber>XXXX1111</cardNumber>

    <expirationDate>2023-03</expirationDate>

    <cardType>Visa</cardType>

  </creditCard>

</payment>

</paymentProfile>
   <validationMode>liveMode</validationMode>
</updateCustomerPaymentProfileRequest>

Also, I couldn't follow your link, it didn't go to the correct page. I'll see if I can find it.

[jheymann]

Before I spend more hours trying to figure out js and various types of communication for this Nounce, can you verify whether this will even work, to permit someone to enter credit card information without the billing address, and then let me add the billing address later? It doesn't seem likely that this would work if the other calls don't. The whole purpose of doing this is to keep OUT of the PCI scope.

Thank you.

BTW, I did find the request you were referring to, and I did upvote and put my two cents in.

[brianmc]

OK, so here's the sample of a request to create the customer payment profile with an Address plus an Accept payment token/nonce.  Obviously this won't work because it's not from your account but you can easily see how a token is retrieved in this code sample:  https://github.com/AuthorizeNet/accept-sample-app/blob/master/acceptJSCaller.js  Version with a hosted form is even easier to call, see sample at https://developer.authorize.net/api/reference/features/acceptjs.html#Integrating_the_Hosted_Payment_...

<createCustomerProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
   <merchantAuthentication>
     <name></name>
     <transactionKey></transactionKey>
    </merchantAuthentication>
   <profile>
     <merchantCustomerId>Merct_Customer_ID3</merchantCustomerId>
     <description>Profile description hereeeee</description>
     <email>customer-profile-email@hereeee.com</email>
     <paymentProfiles>
       <customerType>individual</customerType>
       <billTo>
      <firstName>John</firstName>
      <lastName>Doe</lastName>
      <company></company>
      <address>123 Main St.</address>
      <city>Bellevue</city>
      <state>WA</state>
      <zip>98004</zip>
      <country>USA</country>
      <phoneNumber>000-000-0000</phoneNumber>
      <faxNumber></faxNumber>
    </billTo>
        <payment>
          <opaqueData>
        <dataDescriptor>COMMON.ACCEPT.INAPP.PAYMENT</dataDescriptor>
        <dataValue>eyJjb2RlIjoiNTBfMl8wNjAwMDUyRkQwQTRENURCQUU5RjU3Q0M2NzJCOEFBNzdFN0QwNkJGODQ5MDU2OUU3REE0ODNCMTBBMEIwNzhCNDdFQ0ZERUY2Nzk2NzFGRTY1QTJDQzFBQzFCMUQzQTA4RDVBMjAxIiwidG9rZW4iOiI5NTQ2OTg4MDIxNjM2ODk3NjAzNTAyIiwidiI6IjEuMSJ9</dataValue>
      </opaqueData>
         </payment>
      </paymentProfiles>
    </profile>
 <validationMode>liveMode</validationMode>
  </createCustomerProfileRequest>

[Renaissance]

I’m just killing time and I don’t want to step on anyone’s toes, but I’ve heavily researched the PCI scope for various authorize integrations.

I am not extremely familiar with the customer profile hosted page you refer to (I think you may be referring to the customer profile API, or maybe you’re referring to your proprietary profile system on your end) but from what I do know and what I am reading on your post, it is very similar to the Accept Hosted payment product.

In that case, I would bet very high that the reason authorize doesn’t allow you to pass along payment information (billing address, name, etc. are considered nonsensitive payment information by PCI SC) in the API call is that this would increase the PCI scope of merchants integrating that solution.

In other words, this is not remotely a technology problem but is instead a marketing problem. I mean a marketing problem in terms of satisfying market demand for a product. People like yourself want the lowest PCI scope possible as long as the solution meets your business’s needs.

Accept Hosted, and the customer profile page if my assumption is correct, are PCI SAQ A level compliance scope products.

SAQ A is the lowest scope you can fall under. It has very few requirements. When you move up just one tiny level to SAQ A-EQ your requirements multiply and become much, much more expensive to implement (including requiring you to hire certified security vendors to conduct testing on your application on an ongoing basis, at least yearly if I remember right).

The key distinction between SAQ A and SAQ A-EQ is a little snippet that reads:

“All elements of the payment page(s) delivered to the consumer’s browser originate directly and only from a PCI DSS certified third party vendor”

That is it almost verbatim. If you answer yes to that question then you are possibly eligible for SAQ A scope. If you answer no, you are A-EQ at minimum, or possibly higher.

If you pass along a billing address in the API call and that billing address is populated on the payment page that means there are elements that do not originate directly from authorize.net (i.e. “ a third party PCI DSS....” as referenced above).

With regards to the js form, it is SAQ A-EQ if you use the nonce for payment data, per authorize’s documentation. Someone correct me if I’m wrong.

Regarding other providers offering the functionality you wish, authorize provides every last drop of it. You can use a pure API driven integration where you have full control over the entire process, including the contents and stying of the payment page. It is not a matter of does this or that provider offer this in most cases, but a matter of do you want the trade off of UX enhancement at the cost of greater compliance requirements. The PCI has a provider blind compliance process. No solution provider is favored over the other.

My clients are all using the Accept Hosted form, which means we have very little control over styling. I researched other companies and found 2 exceptions where you could control the payment form stying and be under SAQ A scope. One was a provider that is hardly known, and they have a method where your api call can pass detailed CSS styling. To satisfy the requirement that all elements are from them and not you, they have an automated security check of your CSS rules, which are then used to create THEIR form. To make a long story short, they tie themselves and you in knots to achieve this. There is a disclaimer on their documentation that reads something like “please note that the validation process may take several minutes and result in payment cancellation by the user.”

The other exception I found was a very well known provider that gives a fairly large degree of control over the payment page. They advertise that an independent PCI assessor has signed off on their page being SAQ A. If they meet the standard as their assessor asserts, they are operating with about one hundredth of a millimeter margin of error in my judgement. My skepticism is shared by many people in the biz I whose commentary I have read online. It doesn’t jive with the PCI documentation that is publicly available. And again, even with that all you accomplish is a greater deal of control over page styling.

You aren’t trying to achieve styling, but that background may help you see how this works and how the PCI SC ties your hands behind your back (for very defensible reasons, even though a pain).

My first clients wanted to use authorize and just by chance of that I am sort of defaulting to authorize for all my other ecommerce guys. I do not know an enormous deal about other providers offerings, only that you are subject to apples to apples compliance scope requirements under them all. This works perfectly for everything I’ve wanted to do thus far so I don’t fix what isn’t broken.

If you are referring to a proprietary customer profile system you have, it may be that you can look into authorizes saved profile api. I think you may be able to achieve what you want using that. I will probably use it in the future myself.

This is just my two cents and I’m not qualified to do or say anything so make what you want of it. If you do your own research I believe you will come to the same conclusions I have.

[Renaissance]

Reading your post again I understand now. You are already using the saved profile API. What I said I think is still as relevant, with one correction. I just noticed that I have been referring to SAQ A-EQ compliance. It is actually SAQ A-EP that is the next level up and SAQ A-EQ doesn’t exist. I’ve researched compliance thoroughly but am apparently still on my training wheels as it relates to the alphabet....

The point remains that when you jump up that one level your requirements are multiplied. That one notch makes a big difference.

[jheymann]

First, thank you for your post.

I don't think this is an issue, however. The key part of the phrase is "... originate directly and only from...". I interpret this to mean that everything on the page must come from a compliant source, with no non-compliant intermediaries. I don't think this implies that all of the data must ultimately originate from the complaint source.

If I POST a default address, and then the Authorize.net sends a page, including in part that address, all of the elements on that page are coming "directly and only" from authorize.net. The POST sends the data to the web server, and then the web server sends a whole page, including the address, to the user's browser.

If this weren't the case, then supplying the amount to be charged in a call would violate that restriction.

I'm not an expert on this, but it is the only interpretation that I think makes sense. After all, none of the data originates from Authorize.net. It all comes, at different times, from other sources. It is, however, delivered directly from Authorize.net, and the page that is being displayed doesn't include any elements that are drawn from other servers or sites.

Anyway, that is the way I understand the requirement.

Thank you.