Using the .NET SDK library, createCustomerPaymentProfile and updateCustomerPaymentProfile doesn't seem to expose the CVV and AVS result codes as easily as it is with createTransactionRequest.
Customer/Payment profile management happens at a different time than the transactions. I can get the CVV and AVS results during the transaction, but I'd like to expose that information earlier in the process, if possible.
Parsing validationDirectResponse will work, but since I can't control whether or not the field data will have commas or what the gateway settings will be now or in the future, I'm looking to manually set x_delim_char and x_encap_char each time a payment profile is created or updated.
Is there a way to do that, either through extraOptions or some other programmatic means? I didn't see any obvious ways to do it while reviewing the API reference documentation.
@Joy, I'm actually looking to see how to set that through the Authorize.Net library for .NET. I've looked through the API docs and sample apps, but didn't see anything.
Basically, whenever I build a createCustomerPaymentProfileRequest or updateCustomerPaymentProfileRequest, I'm looking to pass in my extraOptions so the validationDirectResponse I get back from the controller has my desired field encapsulation and delimiter character.
Is that something you or one of the other admins can help with?
If it's easier to get that information from createTransactionRequest, then please use that. We'd rather you move away from createCustomerProfileTransactionRequest anyway.
createTransactionRequest has been extended to allow you to specify profile information instead of payment information, and we have sample code showing you exactly how to do that. The transaction will happen the same way as if you called createCustomerProfileTransactionRequest, but you'll get the response back in the same format as any other use of createTransactionRequest.
Sorry, @kevinfairchild, I can't see any way to get a better response out of createCustomerProfileRequest or updateCustomerProfileRequest. <extraOptions> doesn't even work for you in that case because that's only applicable to createCustomerProfileTransactionRequest.
One suggestion would be to set preferred delimiter/encapsulation in the merchant interface, which will reflect in the response to those requests.
Other than that, an appropriate workaround would be to do an authOnly transaction for 0.00 immediately before the createCustomerProfileRequest or updateCustomerProfileRequest (since that's essentially what the validation in those two requests are doing anyway). The difference is that by doing it in a separate call you'd get the more readable response.