Home → Problems →

auxCode not coming through any more

• Edit

Dan Kamins

04 Apr, 2011 08:46 AM

Starting some time in the last month or so, our code stopped receiving the actual "auxCode" error value on AVS errors (422/6001), e.g. our error ID 693566 from 04/03/2011 20:51:24. We are getting instead an empty value, and our error handling code is failing.

We have not yet inspected the XML returned by CG. Has anything changed that we should be aware of?

Thank you.

1. Support Staff 1 Posted by Marc Guyer on 04 Apr, 2011 06:04 PM

   

   Nothing's changed. We also have a regression test specifically for a returned 422/6001 which passes.

   • Edit

2. Marc Guyer closed this discussion on 04 Apr, 2011 06:04 PM.

3. chris re-opened this discussion on 04 Apr, 2011 07:20 PM

4. 2 Posted by chris on 04 Apr, 2011 07:20 PM

   

   I see that March 13th was the last time that your KB article related to this topic was updated: http://support.cheddargetter.com/kb/api-8/error-handling. That date corresponds to the date that we started seeing more problems and errors in our error log in the CG interface.
   Any chance you could share what the changes were to that article?

   • Edit

5. Support Staff 3 Posted by Marc Guyer on 04 Apr, 2011 07:50 PM

   

   Tender does not provide any versioning capability for KB articles. I reread it to see if anything jogged a memory of making a change but nothing... It was probably a typo or a minor addition. At any rate, the change was not substantive.
   

   Are you able to replicate a failed auxCode return with error simulation?
   

   • Edit

6. 4 Posted by Dan Kamins on 05 Apr, 2011 04:52 AM

   

   A few minutes ago (2011-04-05 @ ~04:40 UTC, or ~21:40 Pacific), we called:
   

   https://cheddargetter.com/xml/customers/edit/productCode/TEXTMARKS/code/u_2503161
   

   The response was an HTTP 422 along with a large XML document, starting with:

   <?xml version="1.0" encoding="UTF-8"?>
   <customers>
     <errors>
       <error id="701292" code="422" auxCode="6000">The transaction was declined</error>
     </errors>
     <customer id="28c55970-ad4e-102e-b098-40402145ee8b" code="u_2503161">
       <firstName>Doc</firstName>
       <lastName>Faquer</lastName>
       <company/>
   ...
   

   Our client code was unable to parse this and only saw HTTP error 422. Why? Because this is how errors have traditionally been returned from CG's API:

   <?xml version="1.0" encoding="UTF-8"?><error id="701274" code="422" auxCode="6001">The transaction was declined due to AVS mismatch</error>
   

   This is also how your FAQ (http://support.cheddargetter.com/kb/api-8/error-handling) describes error handling.

   It's not easy to reproduce these exactly, and it doesn't seem consistent, but here you have some evidence. Can you explain why the first error is being returned in this verbose, unfamiliar, nontraditional, and undocumented format?

   Thank you.
   

   • Edit

7. Support Staff 5 Posted by Marc Guyer on 05 Apr, 2011 03:49 PM

   

   This error format has been documented since CG's launch in the KB article you referenced. It's near the bottom under "There's Errors and Then There's Errors".

   It's also referenced in the PHP wrapper quick start: http://support.cheddargetter.com/kb/api-8/cheddargetter-client-libr...

   And a comment about it a year ago: http://support.cheddargetter.com/discussions/questions/119-immediat...

   And a thread about how to simulate it: http://support.cheddargetter.com/discussions/questions/464-xml-resp...

   The difference between the two is simple. The basic error format is returned when the customer had never existed prior to the request. The embedded format occurs when interacting with a customer that already exists.
   

   • Edit

8. Marc Guyer closed this discussion on 05 Apr, 2011 03:49 PM.

9. Dan Kamins re-opened this discussion on 05 Apr, 2011 05:54 PM

10. 6 Posted by Dan Kamins on 05 Apr, 2011 05:54 PM

    

    OK, I withdraw the "undocumented" adjective. Sorry. But let me add these data points:

    1. The client library we are using is cheddarsnake (Python). It's unofficial/unsupported/unmaintained, granted. But it has no capacity to understand these embedded error messages, so there was no clue from here that they were possible.

    2. The KB article on errors you linked to starts off with "First of all, the basics. Errors reported by the API look something like this:" followed by the simple XML example. There is no ToC on that article, and it doesn't even mention that there's another format until you scroll 4 pages down.

    We're going to update our client library to intelligently parse these embedded errors, but I think it would be advantageous and helpful for future client coders if you would clarify that KB article and make it obvious at the top that there are two types of errors.

    As always, thank you for your help.

    • Edit

11. Support Staff 7 Posted by Marc Guyer on 06 Apr, 2011 01:23 PM

    

    Done. Thanks for the suggestion.

    Unfortunately it seems that the original author of cheddarsnake is no longer maintaining it. My sense is that Sharpy will emerge as the best/most mature choice for Python: https://github.com/Saaspire/sharpy. You probably have quite a bit of code talking to cheddarsnake but you might consider retrofitting Sharpy. Otherwise, would you consider taking over as the maintainer of cheddarsnake?
    

    • Edit

12. Dean closed this discussion on 16 Jan, 2013 04:23 PM.