Will AuthorizeNet support old API CIM commands after March 2018?

[VitaliKram]

Hello,

This is regarding news that Hosted CIM will be deprecated after March 2018 and news that Authorize Net is moving to one general API.

Our ERP software (desktop application) use CIM API for registering  Customer Profiles, adding Payment Profiles (with credit cards) and charging Customers by their Payment Profiles. We don’t use Hosted CIM page technology, we use direct CIM API calls in XML format.

We use createCustomerProfileTransactionRequest command several years already to Authorize, Pre-Authorize, Post-Authorize, Void, Credit our CIM customers with usage of their Payment Profiles. The description of new API doesn’t have this "old" command listed. The only new similar command is createTransactionRequest. 

1. So the main question is: will createCustomerProfileTransactionRequest command be supported in future, after March 2018? We really don’t want to change code again in our system.
2. Why new createTransactionRequest command is so poorly documented for working with Customer/Payment Profile transactions? This doesn’t have info how to Void, Pre-Authorize, Post-Authorize. I had to test it on my own trying to send different values in transactionType tag and guessing why the service returns error this time, what I didn’t send in this command, etc. Previous description in CIM XML Guide documentation was pretty detailed and it was easy to start to use it.

Thank you.

Vitali

[Aaron]

Hi @VitaliKram,

We haven't made any announcement regarding the CIM-specific API calls like createCustomerProfileTransactionRequest. The End-Of-Life announcement only pertains to hosted profile creation or management pages served from https://test.authorize.net/profile/ or https://secure.authorize.net/profile/. For those merchants using hosted CIM, the update if their code is simple and is usually just changing the URL that they do the form post to.

For those using the CIM API, like you, there's no End-Of-Life notice on those calls, but there are still good reasons to switch to the current API calls. The CIM API bears a strong resemblance to the current API, and even goes to the same endpoints. The difference is that over time our API has evolved to use fewer separate calls, and to use a more hierarchical structure to get a little more flexibility.

I'll spend some time doing a more detailed explanation here for the benefit of anyone else coming across this thread.

Here's a sample request using the CIM API (createCustomerProfileTransactionRequest ):

<createCustomerProfileTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name>{{loginId}}</name>
    <transactionKey>{{transKey}}</transactionKey>
  </merchantAuthentication>
  <refId>123456</refId>
  <transaction>
    <profileTransAuthOnly>
      <amount>5</amount>
      <tax>
        <amount>1.00</amount>
        <name>WA state sales tax</name>
        <description>Washington state sales tax</description>
      </tax>
      <shipping>
        <amount>2.00</amount>
        <name>ground based shipping</name>
        <description>Ground based 5 to 10 day shipping</description>
      </shipping>
      <lineItems>
        <itemId>ITEM00001</itemId>
        <name>name of item sold</name>
        <description>Description of item sold</description>
        <quantity>1</quantity>
        <unitPrice>6.95</unitPrice>
        <taxable>true</taxable>
      </lineItems>
      <lineItems>
        <itemId>ITEM00002</itemId>
        <name>name of other item sold</name>
        <description>Description of other item sold
        </description>
        <quantity>1</quantity>
        <unitPrice>1.00</unitPrice>
        <taxable>true</taxable>
      </lineItems>
      <customerProfileId>1810727734</customerProfileId>
      <customerPaymentProfileId>1805485138</customerPaymentProfileId>
      <customerShippingAddressId>1809788138</customerShippingAddressId>
      <order>
        <invoiceNumber>INV-12345</invoiceNumber>
        <description>Product Description</description>
        <purchaseOrderNumber>456654</purchaseOrderNumber>
      </order>
    </profileTransAuthOnly>
  </transaction>
</createCustomerProfileTransactionRequest>

And here's the same request using the createTransactionRequest call:

<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name>{{loginId}}</name>
    <transactionKey>{{transKey}}</transactionKey>
  </merchantAuthentication>
  <refId>123456</refId>
  <transactionRequest>
    <transactionType>authOnlyTransaction</transactionType>
    <amount>5</amount>
    <profile>
      <customerProfileId>1810727734</customerProfileId>
      <paymentProfile>
        <paymentProfileId>1805485138</paymentProfileId>
      </paymentProfile>
      <shippingProfileId>1809788138</shippingProfileId>
    </profile>
    <order>
      <invoiceNumber>INV-12345</invoiceNumber>
      <description>Product Description</description>
    </order>
    <lineItems>
      <lineItem>
        <itemId>ITEM00001</itemId>
        <name>name of item sold</name>
        <description>Description of item sold</description>
        <quantity>1</quantity>
        <unitPrice>6.95</unitPrice>
        <taxable>true</taxable>
      </lineItem>
      <lineItem>
        <itemId>ITEM00002</itemId>
        <name>name of other item sold</name>
        <description>Description of other item sold
        </description>
        <quantity>1</quantity>
        <unitPrice>1.00</unitPrice>
        <taxable>true</taxable>
      </lineItem>          
    </lineItems>
    <tax>
      <amount>1.00</amount>
      <name>WA state sales tax</name>
      <description>Washington state sales tax</description>
    </tax>
    <shipping>
      <amount>2.00</amount>
      <name>ground based shipping</name>
      <description>Ground based 5 to 10 day shipping</description>
    </shipping>
    <poNumber>456654</poNumber>
  </transactionRequest>
</createTransactionRequest>

 As you can see, it's essentially all the same elements, just with some either renamed or rearranged to fit the order in the new schema.

• There's now a <transactionRequest> element instead of <transaction>.
• The type of transaction is designated within a <transactionType> element instead of being a container element of its own.
• All of the relevant profile IDs are contained in a <profile> element.
• <lineItems> becomes hierarchical with individual line items detailed in a <lineItem> container.
• <purchaseOrderNumber> moves out of the <order> element and becomes <poNumber>.

Doing this type of rearranging and renaming isn't too difficult as long as the possible values you can submit are the same. In the case of the transaction type, they're not. You need to know a new set of values, and those values aren't provided in the API reference. Instead, we just provide an example of one type of transaction.

In the API reference, if you scroll all the way to the top of the "Payment Transactions" section, you'll see a link to the Payment Transactions Feature Details page, which specifies all the values for the <transactionType> element. They're not laid out in an easy form like a table on that page, though. So, it's a bit of a treasure hunt. Either you find the link to the Payment Transactions Feature Details page by going to a completely different part of the API reference, then do some hunting through the page, or you piece it together by getting relevant values from the rest of the API reference (like the "Charge a Credit Card" page, the "Authorize a Credit Card" page, the "Capture a Previously Authorized Amount" page, etc.)

So, you're right. Not a great experience. Now that you've called that to our attention, we can make changes like either getting all possible values in the API reference, or making it easier to find lists of possible values.

If there's anything else you found confusing about the API reference or any associated documentation, please let us know. We're very gung ho about improving that here, so we really want to hear what we can do better along those lines.

[VitaliKram]

Aaron,

Thank you for your reply. This information is very usefull for me and other Authorize Net developers.

Vitali