So the XML-based API is supposed to be ready for prime time and that's what we should be using for new development?
I could be up for that and for retrofitting it, BUT...
I was more than a little surprised when installing per instructions put almost 4,200 files (and 25 MB) on my server to support what a little digging shows can be done in a couple of dozen lines of code or less per type of operation, probably less on average taking overlap into account. IOW minimal change. That's to get from input-array to output-array sandwiching actual execution of the transaction. A guy sure can't tell that from a first look at the dox, though.
Even after (or because of) all that, there were unresolved dependencies and the sample code was dying on yaml. It seems this general approach to installation and configuration would become a chronic source of inherent fragility and even vulnerability to deliberate sabotage.
So now I'm just embedding a curl connection pretty close to what my existing code base uses, merely spouting and digesting XML instead of the old format.
If I'm not supposed to be using the new stuff yet for production work, then where can I find the docs and examples for old-style ARB and TD not dependent on adapters to the new schema?
Now about the refunds in my title: I copied the example request verbatim. (That part of the documentation seems a vast improvement over the past, quite an elegant little digest.)
<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<merchantAuthentication>
<name>API_LOGIN_ID</name>
<transactionKey>API_TRANSACTION_KEY</transactionKey>
</merchantAuthentication>
<refId>123456</refId>
<transactionRequest>
<transactionType>refundTransaction</transactionType>
<amount>5</amount>
<payment>
<creditCard>
<cardNumber>5424000000000015</cardNumber>
<expirationDate>1220</expirationDate>
<cardCode>999</cardCode>
</creditCard>
</payment>
<refTransId>1122334455</refTransId>
</transactionRequest>
</createTransactionRequest>But I plugged in real live everything for a recently settled transaction.
Here's what I get: back:
<?xml version="1.0" encoding="utf-8"?>
<createTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<refId>1448841865</refId>
<messages>
<resultCode>Error</resultCode>
<message>
<code>E00027</code>
<text>The transaction was unsuccessful.</text>
</message>
</messages>
<transactionResponse>
<responseCode>3</responseCode>
<authCode />
<avsResultCode>P</avsResultCode>
<cvvResultCode />
<cavvResultCode />
<transId>0</transId>
<refTransID>9999999999</refTransID>
<transHash>99999999999999999999999999999999</transHash>
<testRequest>0</testRequest>
<accountNumber>XXXX9999</accountNumber>
<accountType>Visa</accountType>
<errors>
<error>
<errorCode>33</errorCode>
<errorText>Invoice Number is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Description is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Customer ID is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Bill To First Name is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Bill To Last Name is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Bill To Address is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Bill To City is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Bill To State/Province is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Bill To Zip/Postal Code is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Bill To Country is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Phone is required.</errorText>
</error>
<error>
<errorCode>33</errorCode>
<errorText>Email is required.</errorText>
</error>
</errors>
</transactionResponse>
</createTransactionResponse>
(Transaction-specific return data changed to 9999s)
What's going on? I've tried providing some of that information, but then it complains about the enclosing elements. It's almost like it's not recognizing this as a refund request. But surely the feature must work or it would have come to light already. So what do I need to do?
Having now put my client on notice of the need to implement a new protocol to get new functionality they have requested/demanded, I'm reluctant to backtrack. But the main thing is to have refunds, subscriptions, and transaction detail functioning by Wednesday AM, so I'll do it the old way if that gets there faster.
