CIM API requires clientID?

[kevinfairchild]

After refreshing the definition for the SOAP web reference for https://api.authorize.net/soap/v1/Service.asmx?wsdl, I noticed that our previously-working code no longer compiles. In each instance, it looks the definition for the methods listed in the compile errors (CreateCustomerProfile, UpdateCustomerPaymentProfile, etc.) all have a string parameter of clientID that is expected (but wasn't in our earlier web reference definitions).

In looking at the CIM API docs (http://www.authorize.net/content/dam/authorize/documents/CIM_SOAP_guide.pdf) and the API reference (http://developer.authorize.net/api/reference/), neither mentions this field anywhere. Additionally, the sample code in the API reference matches our calls and doesn't seem to be passing in a clientID anywhere.

What is clientID and how should we be using it, now that it's required? Is that our userid, tran key, a unique id for that specific card, or what?

[kevinfairchild]

NOTE: I've also tried using api2.authorize.net instead, since a lot of the documentation seems to refer to api.authorize.net as still supported but a legacy url.

[RichardH]

Hello @kevinfairchild

ClientID is for internal use by Authorize.Net and is not required.

Richard

[kevinfairchild]

@RichardH, is something not configured correctly in the WSDL, then?

Example reference definition after refreshing web service reference:

        <System.Web.Services.Protocols.SoapDocumentMethodAttribute("https://api.authorize.net/soap/v1/CreateCustomerProfile", RequestNamespace:="https://api.authorize.net/soap/v1/", ResponseNamespace:="https://api.authorize.net/soap/v1/", Use:=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)>  _
        Public Function CreateCustomerProfile(ByVal merchantAuthentication As MerchantAuthenticationType, ByVal profile As CustomerProfileType, ByVal validationMode As ValidationModeEnum, ByVal clientId As String) As CreateCustomerProfileResponseType
            Dim results() As Object = Me.Invoke("CreateCustomerProfile", New Object() {merchantAuthentication, profile, validationMode, clientId})
            Return CType(results(0),CreateCustomerProfileResponseType)
        End Function

...thoughts?

[Lilith]

@kevinfairchild -- you mentioned compile errors that mention clientID explicitly. Could you share some examples, please?

I confirm that the WSDL has minOccurs=0, meaning the field is not mandatory, and as Richard indicated, it is an internal field only. So I'd like to see the errors to get a better idea of context.

As for the API endpoint's domain -- either api.authorize.net or api2.authorize.net should work. The difference is that api2 utilizes Akamai SureRoute for routing optimization. Both have the same WSDL and reach the same servers in the end.

(I should note we've begun to deprecate SOAP, however. While the SOAP flavor of our API will be supported, we will not be adding new features. Unless SOAP is a requirement, you may want to consider developing using the XML or JSON flavor of our API. We also have a REST API in the works, of which you'll hear more over the next several months.)

[kevinfairchild]

@Lilith,

I get a handful of them for the different create, update, delete calls done in our app.

Here's an example from the error list in VS 2015:

Error	BC30455	Argument not specified for parameter 'clientId' of 'Public Function CreateCustomerPaymentProfile(merchantAuthentication As MerchantAuthenticationType, customerProfileId As Long, paymentProfile As CustomerPaymentProfileType, validationMode As ValidationModeEnum, clientId As String) As CreateCustomerPaymentProfileResponseType'.

This problem has affected us both on a winform application as well as a ASP.NET web app.

As for SOAP being depreciated, I noticed that today as well. We'll be moving to one of the other APIs sometime this year, but until then -- we're just trying to figure out how to get around this new field requirement.

One of the other developers tried passing in an empty string, which he said seemed like it worked the first time but then failed on subsequent attempts. We have an older version of the application that doesn't have the updated API references that include that field and that seems to work correctly as-is. It's only when we update the definitions that it seems to have problems.

[Lilith]

@kevinfairchild -- as I mentioned, I reviewed the WSDL directly. No occurrence of clientId is required in an API request.

Any chance you could send us a copy of the WSDL you're using? I know you said you copied it from us, but I want to review what's cached on your server, in case something odd happened.

[kevinfairchild]

@Lilith, 

Just for clarification... I have an existing winform in VS 2015 with an old reference definition for the SOAP API. No compile errors and transactions and everything work perfectly. Clicking "Update Web Reference" refreshes the definitions which then adds the new parameter and causes compile errors.

I completely agree with you that from what I can see of the WSDL, that field should not be required. I'm just reporting what is happening on seperate apps and to seperate developers after updating the reference data.

I can paste a copy of the Service.wsdl file the client has after the refresh, but I've already verified the routines I'm getting the error on all have:

<s:element minOccurs="0" maxOccurs="1" name="clientId" type="s:string" />

Seems like that's how it should be (optional) from what you've said.

I went ahead and downloaded the sample project from https://github.com/AuthorizeNet/sample-code-csharp to try to see if I could reproduce the issue with it on there, but it doesn't look like that uses a web reference to the SOAP API.

If there's anyone with a SOAP web reference in Visual Studio that can do a refresh of the definitions and let me know if they have the same issue with previously-working Authorize.Net code causing compile errors related to clientID, that would be helpful. Especially within VS 2015. At least then I'd be able to determine if it's something specific to VS 2015 or what...

[kevinfairchild]

@RichardH or @Lilith, were either of you able to do a refresh of the WSDL within VS 2015 to see if it's interpretting clientID as required?

I've had complaints of this from other developers using fresh installs of VS 2015 in different projects, so I'm wondering if that's the issue.

[ruchi_s]

Hi @kevinfairchild @Lilith @RichardH,

I am faciing the same problem. I have updated the service refence from "https://api.authorize.net/soap/v1/Service.asmx?wsdl".

Now all existing code is not working as new update added field "clientid" for most of the methods. I tried to pass loginid as clientid but disn't work.

Also, I do not have any clientid and do not want to generate this.

Please let me know the solution. I am working with Visual Studio 2012 and do not have VS 2015.

Regards

Ruchi