Showing results for 
Search instead for 
Did you mean: 
Status: Accepted

Created from previous thread:


Add ability to pre-load billing information into CIM hosted form.   Our customer's billing information is already stored in our system, and we do not want to force them to enter it a second time when adding a payment profile.  We would prefer instead to show the current billing information as the default values and allow them to modify the displayed information if the billing infomration is different for the credit card than what is already on file.





In our system the user complete billing information, and when we show the form of the CIM hosted API, we need such data are loaded in the form, as we do that?


First we call to createCustomerProfileRequest,  with merchantCustomerId and email.


Then I call createCustomerShippingAddressRequest with customer billing address


and then, I call getHostedProfilePageRequest.

Status changed to: Accepted
Administrator Administrator
Regular Contributor

Progress on this?

Authorize.Net Expert Authorize.Net Expert
Authorize.Net Expert

 The feature "default profile" is already been delivered -

Check for setting the default profile. Please let us know if you are something else.


Please read the request again.   We want a default billing address to show up on payment profiles created by the customer using hosted forms.  We are not asking for the ability to create payment profiles using api calls (yes, that functionality is already there).


It would need to look something like this:


1) We create a customer profile

2) We add a default billing address (this could be part of step 1 or a separate api call)

3) When the customer goes to add a new payment profile via a hosted form, the default billing address shows up on the hosted form.



This request, in various forms, has been out here since 2012, and all of your competition can do this. 

We need you to implement at least one of the following:


* Ideally, add the default billing address to the customer profile, OUTSIDE of payment information (which we don't want to send, due to PCI issues).

* Or, permit the call to get a hosted page token to accept default billing address information for the page, ideally for the /addpayment call.

* Or, permit the POST to the hosted payment page (/manage and /addpayment) to accept html default parameters such as address, city, state, zip, etc. Note: This is probably the easiest and quickest for you to implement, so I would encourage you to do this while we are waiting on the other two items.


This is REALLY FRUSTRATING, and is one of the reasons why I try to push customers away from, to native processor implementations.


This is a feature that would be a great usability boost for our customers and employees. Currently our registered customers on our site have to reenter their billing information when adding payment profiles which introduces some unneeded friction into the payment step of our checkout. This feature would fall within the goals of what Auth.NET has posted for customer profiles. Customer profiles are for businesses that "want to provide returning customers with the convenience of not having to re-enter personal data."


Building off of the previous comments and original idea, here are a couple of the specific options I could see being implemented:


Option 1

Update getHostedProfilePageRequest to have a billTo element for billing information. The billTo information would then be included in the generated token. The billing information can be prepopulated in the Accept Customer form when executing a POST to or with the token that's passed. For the "/manage" action, it currently uses the billing address of the most recent payment profile for prepopulating the form when adding a new payment profile. It could continue to do so when billing information isn't passed.


Having a billTo element follows the pattern already in place for the Accept Hosted solution when making a call to getHostedPaymentPageRequest. The getHostedPaymentPageRequest accepts values under the transactionRequest element to prepopulate its form fields.


This option would probably make the most sense IMO as it would keep things consistent in the Web API for the Accept Suite.


Option 2

Update and to accept bill to fields to prepopulate the billing information in the payment profile form when adding a payment profile. For the "/manage" action, it currently uses the billing address of the most recent payment profile for prepopulating the form when adding a new payment profile. It could continue to do so when billing information isn't passed.


Option 3

As @jheymann mentioned in his comment, you could add a default billing address to the customer profile. It could then be used for prepopulating the billing information in the payment profile form when adding a payment profile for and . This option would require additional functions for add/update/get/delete on the customer profile billing information.


I don't see this as the optimal option as it's different than what's already in place for the Accept Hosted solution and it also raises the question of whether or not this new default billing information should be used for Accept Hosted as well—which could result in more changes being needed.



Please, implement this. This has been a needed feature for quite some time and it would be a great addition to an already great product.



For reference, here are all the forum conversations I could find where this feature is being requested/expected:


Not having this feature available is possibly a deal breaker for my team.  We've been using CIM to manage payment profiles, but we now need to meet PCI SAQ-A guidlines, so we are implementing the Accept Hosted Customer Form.  


Like the other requests, it is ridiculous to ask our users to enter all their billing address information for their credit card right after they have entered it on the page before.  


From the post above, option 1 seems like the best choice.  Update getHostedProfilePageRequest to have a billTo element for billing information. That solves the problem.


Also, I spent a ton of time trying to implement this myself, as the last post in this thread claims this to already be possible, which it is not.


From the thread:

It is indeed possible to prepopulate the form. When you request the token, include anything you want prepopulated in the "transactionRequest" element of the request. You can use all of the same information that you see for "transactionRequest" for the regular payment transactions (, with the following known issues: