cancel
Showing results for 
Search instead for 
Did you mean: 

No card type in XML response?

In AIM, while the card type is returned when using the delimited response in position 22, there appears to be no such information in the response message.

On the other hand the xml response seems to offer more message information in the case of errors.

 

Do I actually have to use the delimited response to get the card type and give up the more elegant an maintainable xml code?

 

Thanks,

Hans

arcasys1
Member
2 REPLIES 2

Are you using Card Present AIM Integration? using the SDKs or your own coding?

22 is card type for Card Present response but for Card NOT present is position 52

RaynorC1emen7
Expert

Thank you for this, but it doesn't answer my question.

I'm using own coded Card Present AIM and field 22 in the the 'delimited string' response is fine and works for me.

 

I rephrase my question:

 

When XML is used as a response type, which btw is default,  there is no equivalent to field 22 in the 'delimited' response.

Field 22 is not the only one missing in the XML response.

So, why are many fields that are available in the 'delimited' response not available in the XML response?

 

In the mean time I've found a decent way to retrieve return values by a name using the following method (Java code):

 

    private Map<String, String> r_split(String response) {
        Map<String, String> rmap = new HashMap<String, String>();
        String[] values = response.split(",");
        try {
            rmap.put("Version", values[0]);
            rmap.put("ResponseCode", values[1]);    // *
            rmap.put("ReasonCode", values[2]);
            rmap.put("ReasonText", values[3]);
            rmap.put("AuthCode", values[4]);        //*
            rmap.put("AVSResultCode", values[5]);
            rmap.put("CVVResultCode", values[6]);
            rmap.put("TransID", values[7]);
            rmap.put("MD5Hash", values[8]);
            rmap.put("UserRef", values[9]);
            rmap.put("CardNumber", values[20]);
            rmap.put("CardType", values[21]);
            rmap.put("SplitTenderId", values[22]);
            rmap.put("RequestedAmount", values[23]);
            rmap.put("ApprovedAmount", values[24]);
            rmap.put("RemainingBalance", values[25]);
        } catch (ArrayIndexOutOfBoundsException e) {
            //TODO insert more  codes as necessary
        }
        return rmap;
    } 

Maybe someone finds this helpful Note that index numbers are always field-number - 1.

 

Perhaps some day Authorize.Net will surprise us with a SOAP interface and present a decent solution to add a tip to a previuos transaction...