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.
01-02-2019 02:53 PM
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
01-03-2019 09:45 PM
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?
01-08-2019 07:25 AM
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.
01-08-2019 07:54 AM
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.
01-08-2019 11:58 AM
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.
01-08-2019 12:14 PM - edited 01-08-2019 12:16 PM
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>
01-08-2019 03:01 PM
01-08-2019 08:17 PM
01-09-2019 05:34 AM
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.
01-09-2019 08:33 PM