The Authorize.Net Developer Blog

Posts from Authorize.Net employees, community members and experts about integrating with the Authorize.Net Payment Gateway: sample code, tutorials, and problem-solving techniques, just to name a few.

Hosted CIM Forms End of Life Announcement

by on ‎09-22-2017 05:00 PM - last edited on ‎02-13-2018 09:06 AM by Administrator Administrator (131,037 Views)

Updated 2/13/2018 with new End of Life date (5/31/2018) and sandbox disablement (3/30/2018)


When using our Customer Profiles feature to securely store your customers’ payment information on our Authorize.Net servers, you have the choice to pass payment information directly to our servers, or to have your customers interact with one of our profile management forms hosted on our servers. These hosted profile management forms help to avoid your direct exposure to payment card data (such as card numbers) and help reduce PCI-DSS scope while still providing the best possible end-user experience.


If you’re already using this feature, you need to be aware that our “Hosted CIM” forms (the older versions of these forms) will be disabled on March 30, 2018.  To assist developers, we will disable Hosted CIM forms on March 31, 2018.


These older “Hosted CIM” forms have been replaced by our “Accept Customer” forms, a fully mobile-optimized, hosted solution for capturing payment information, which enables developers to leverage our Customer Profiles API while helping to maintain a SAQ-A level PCI-DSS compliance. Switching to the new Accept Customer forms is as easy as changing a single URL in your application.


“How do I know if I’m using your older forms?”


Whether you’re using the older Hosted CIM forms or our newer Accept Customer forms, you’re obtaining a form token from our API, and then using an HTML form in the browser to submit that form token to a URL for the specific form you want to use. Looking at this URL, you can tell whether you’re using the old hosted CIM forms or the new Accept Customer forms.

In most cases, all you will need to do to use the Accept Customer forms instead is to change the address to which your form token is posted from the old CIM form addresses to the new Accept Customer addresses.


Old CIM Form Addresses (for production) (for sandbox/testing)


New Accept Customer Addresses (for production) (for sandbox/testing)


The process of obtaining the token used to load these forms remains unchanged.


Hosted CIM forms with addresses containing (for production) or (for sandbox/testing) are no longer being updated and will return HTTP Error 410 after March 30, 2018.


For more information about Customer Profiles and our Accept Customer forms, see our Customer Profiles documentation at

by wtc828
on ‎12-13-2017 06:58 AM

We have a legacy application running with "Hosted CIM" for quite a few years.  From the above, is the change to "Accept Customer" a simple change to the URL from '' to '' ?


by Authorize.Net Developer Authorize.Net Developer
on ‎12-22-2017 10:26 PM


In most cases, that simplest of URL changes should work. However, I would recommend running a few testing scenarios using the Sandbox URLs before going live, as well as going through this documentation for accept customer hosted forms:


by rinogo
on ‎01-08-2018 09:49 AM

@wtc828: The text "profile" in the URL has changed to "customer" as well. We're in the same boat as you; hoping that all that is needed is switching out the URLs!

by merit_it
on ‎01-10-2018 06:27 AM

It seems there is a bug in the new form. The one input is labeled incorrectly causing auto-fill to fill the zip code in the address field:


<input id=“billingAddressID” ng-focus=“focusIn(‘billingAddressID’ ,hasBillingAddressFocus=true)” ng-blur=“focusOut(‘billingAddressID’,hasBillingAddressFocus = false)” ng-model=“opt.billingAddress.model” my-maxlength=“60” name=“zip” type=“text” ng-class=“isFieldMandatory(opt.billingAddress.model,hasBillingAddressFocus)” class=“ng-pristine ng-valid address-text-intent ng-touched”>


Note, the 'name' attribute is set to 'zip' for the address field.


Is there an ETA on when this will be corrected?



by batline
on ‎01-10-2018 09:02 AM

We also reported this issue with auto-fill 1/2/18.         

Finding it hard to believe this was missed in initial testing and seems like it would be a fairly simple fix.     This is a critical issue that is causing us to have shipments without a valid ship-to address.     

We're hoping this is considered a critical issue by your development staff.



by vathanas01
on ‎01-12-2018 06:27 PM

Hi, We're a long time user of the service, trying to figure out if this applies to our pages.


We do not have any pages in either of the formats described above.  Instead, we exclusively POST to:


Do these URLs require modifications and testing?  Please advise.



by wtc828
on ‎01-24-2018 07:30 AM

We switched over our "Hosted CIM" customer this morning. They're running live with no reported problems in first 3 hours.


The code change was as simple as others indicated in this thread.

We just had to change "secure" to "accept" in the URL and start using "customer" instead of "profile".


If our customer reports any problems, we will update this thread.


by CFDAmoore1
‎01-26-2018 06:02 AM - edited ‎01-26-2018 06:06 AM

Good morning. How does, or does it change anything with the URLs used with CIM SOAP Service?



by virtualwaytest1
on ‎01-29-2018 09:26 PM



We are using payment gateway API from last 6 years.We have receieved the TLS disablement notice. We have few questions.Please see below.




   We are using Hosted CIM (Customer information Manager) soap calls for storing card information and payment transactions  .


Currently we are using  url for Live transactions.


and  for test transcations .



We have developed our solution on .Net Framework 4.0 .




  1. Will the CIM soap calls get deprecated after 28th feb , if yes then what api's shoud we use ? 
  2.   Are the new APis supported in .Net Framework 4.0? If not what is the minimum .Net framework version required?


  1. We have hosted our web-portal on windows server 2016 ? will this support TLS 1.2 ?