I'm using the AuthorizeNet SDK library from Nuget/Github in my C# MVC project, but I'm trying to add support for partial/split tender transactions, and I'm confused as to how. There's lots of API documentation, but next to nothing on the SDK.
I can send an AuthoriztionRequest() with includeCapture:false and then set AllowPartialAuth = "true" with the test zip 46225. The IGatewayResponse that comes back will fail with a ResponseReasonCode of 295, which means I can then convert the IGatewayResponse to a full GatewayResponse and then read the SplitTenderId from that. So far, so good.
Now I can do another transaction like above, but use a different zip code to not trigger the test behavior and set the amount for the remainder of the transaction. I can add the SplitTenderId from above to this request, and it approves as expected.
At this point, I can log into the web admin for Authorize.Net, and I see both transactions as Authorized/Pending Capture, and the summary box at the top of the transaction detail lists both transactions, so it knows those two are linked together. So the first half of this process seems to work just fine.
My understanding based on reading API documentation is that I'm supposed to not pass in a TransactionId for capture, and supply the SplitTenderId instead (using both throws the expected error). I create a PriorAuthCaptureRequest() with the amount for the full order, and pass a null transactionId. Then on the request object I get back, I set the SplitTenderId to what was given to me on the partial auth and passed to the second auth. The response that comes back from the server is a simple "This transaction has been approved." with a transactionId of "0". Checking the status of the transaction in the web admin for Authorize.Net, both still show as Authorized/Pending Capture. The SDK seems to have done a silent NOP.
I can go in and pass the TransactionId for each in two separate Capture requests without the SplitTenderId, and then they show up as Captured/Pending Settlement, as expected, but I didn't think that's how the process was supposed to work. If I still have to capture each individually, what's the purpose of passing around this SplitTenderId, or even having one at all?
08-25-2015 08:33 AM
In order to make this simpler, forget everything I said above about the SDK. I changed to use the new model that looks a lot more like the API. I'm guessing the old model is pretty deprecated at this point. Authorizing seems straightforward, but I still don't know how to capture the split tender.
For example, I'm placing an order for $5.46, using two test partial transactions at $1.23 each and one full one to take up the remaining $3. The response from that final authorization is this:
<?xml version="1.0" encoding="UTF-8"?> <createTransactionResponse xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <messages> <resultCode>Ok</resultCode> <message> <code>I00001</code> <text>Successful.</text> </message> </messages> <transactionResponse> <responseCode>1</responseCode> <authCode>13LAZJ</authCode> <avsResultCode>Y</avsResultCode> <cvvResultCode /> <cavvResultCode>2</cavvResultCode> <transId>2239009165</transId> <refTransID /> <transHash>F1C54ABF1FA0969C70D1A1F9B5548715</transHash> <testRequest>0</testRequest> <accountNumber>XXXX0015</accountNumber> <accountType>MasterCard</accountType> <splitTenderId>114826</splitTenderId> <messages> <message> <code>1</code> <description>This transaction has been approved.</description> </message> </messages> <splitTenderPayments> <splitTenderPayment> <transId>2239009055</transId> <responseCode>1</responseCode> <responseToCustomer>1</responseToCustomer> <authCode>V62MJR</authCode> <accountNumber>XXXX1111</accountNumber> <accountType>Visa</accountType> <requestedAmount>5.46</requestedAmount> <approvedAmount>1.23</approvedAmount> </splitTenderPayment> <splitTenderPayment> <transId>2239009130</transId> <responseCode>1</responseCode> <responseToCustomer>1</responseToCustomer> <authCode>CGDLQN</authCode> <accountNumber>XXXX0012</accountNumber> <accountType>Discover</accountType> <requestedAmount>4.23</requestedAmount> <approvedAmount>1.23</approvedAmount> </splitTenderPayment> </splitTenderPayments> </transactionResponse> </createTransactionResponse>
What do I need to do to capture this transaction? Do I call PriorAuthCapture three times, once for each transId returned? If so, what's the benefit to passing around a splitTenderId on these Authorization requests? Does it only count as one transaction as far as fees are concerned?
08-26-2015 01:24 PM
Should be just 1 call to the PriorAuthCapture with the split transaction id
http://www.authorize.net/support/AIM_guide_XML.pdf
page 30
08-26-2015 01:36 PM - edited 08-26-2015 01:40 PM
According to the API docs, it doesn't even list taking a splitTransId. The description for the required refTransId mentions skipping it if supplying splitTransId (which by definition means it's not required).
If I do it anyway, I get the situation I outlined at the end of my first post. The web admin says all three transactions are still Authorized/Pending Capture, as if nothing was ever called. The response lists all three transactions, and says they're approved, but it doesn't actually appear to be so. I can call this multiple times and get the same response. That doesn't seem right.
<?xml version="1.0" encoding="UTF-8"?> <createTransactionResponse xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <messages> <resultCode>Ok</resultCode> <message> <code>I00001</code> <text>Successful.</text> </message> </messages> <transactionResponse> <responseCode>1</responseCode> <authCode /> <avsResultCode>P</avsResultCode> <cvvResultCode /> <cavvResultCode /> <transId>0</transId> <refTransID /> <transHash>E3BA0E2F36DF128C0FBACF31D21C4AB7</transHash> <testRequest>0</testRequest> <accountNumber /> <accountType /> <splitTenderId>114826</splitTenderId> <messages> <message> <code>1</code> <description>This transaction has been approved.</description> </message> </messages> <splitTenderPayments> <splitTenderPayment> <transId>2239009055</transId> <responseCode>1</responseCode> <responseToCustomer>1</responseToCustomer> <authCode>V62MJR</authCode> <accountNumber>XXXX1111</accountNumber> <accountType>Visa</accountType> <requestedAmount>5.46</requestedAmount> <approvedAmount>1.23</approvedAmount> </splitTenderPayment> <splitTenderPayment> <transId>2239009130</transId> <responseCode>1</responseCode> <responseToCustomer>1</responseToCustomer> <authCode>CGDLQN</authCode> <accountNumber>XXXX0012</accountNumber> <accountType>Discover</accountType> <requestedAmount>4.23</requestedAmount> <approvedAmount>1.23</approvedAmount> </splitTenderPayment> <splitTenderPayment> <transId>2239009165</transId> <responseCode>1</responseCode> <responseToCustomer>1</responseToCustomer> <authCode>13LAZJ</authCode> <accountNumber>XXXX0015</accountNumber> <accountType>MasterCard</accountType> <requestedAmount>0.00</requestedAmount> <approvedAmount>3.00</approvedAmount> </splitTenderPayment> </splitTenderPayments> </transactionResponse> </createTransactionResponse>
And that last one looks odd, the one that wasn't a partial authorization. It says I requested $0 but was approved for $3?
The paragraph from the AIM guide about capturing is odd, too. I don't really understand what this is saying:
"If the merchant needs to release the group of transactions before the final transaction is approved (if the balance is paid by cash, for example), send a PRIOR_AUTH_CAPTURE request and include the split tender ID instead of a transaction ID."
What is "releasing" the transactions? The paragraph right below it talks about voiding. What it describes (call PriorAuthCapture with the splitTenderId) is what you said should be done to capture the group, which sounds logical, but doesn't look like it does anything.
08-26-2015 02:29 PM
I wanted to follow up on this issue and see if anyone had some input on the behavior I'm seeing. Could I get someone else to run through a scenario like above and see what it looks like? Can you capture the SplitTransId multiple times, and does it still look uncaptured in the web admin? I'd like to determine if this is a problem with how I'm calling it, with the SDK, my account's settings, or the test system.
08-31-2015 09:02 AM
The one thing I can still test is the test system itself, so I just ran a test with a prepaid card on our production account, and the behavior is exactly the same. Capturing the split tender id does nothing.
Where's my problem? How is split tender supposed to work?
09-02-2015 08:05 AM
Also, I just voided those two production authorizations, and then ran the capture for the split tender again to see what error I'd get, and I get no error. It behaves just like it did when they were active. Apparently capturing a split tender id is a no-op, despite documentation indicating that's what's supposed to happen.
Should I be calling capture with the transaction id of each card in the split tender instead, and just have error checking for when half the operation fails since it's not atomic anymore?
09-02-2015 08:11 AM
It doesn't look like it doing a priorAuthCaptureTransaction, can you see the request xml?
09-02-2015 09:35 AM
Yeah, using the "new model" of calling the SDK dumps out the full XML request/response to debug, so it makes testing much easier.
This is the request for that test run on 8/26:
<createTransactionRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <merchantAuthentication> <name>*************</name> <transactionKey>*************</transactionKey> </merchantAuthentication> <transactionRequest> <transactionType>priorAuthCaptureTransaction</transactionType> <amount>5.46</amount> <splitTenderId>114826</splitTenderId> <transactionSettings> <setting> <settingName>allowPartialAuth</settingName> <settingValue>True</settingValue> </setting> </transactionSettings> </transactionRequest> </createTransactionRequest>
A transactionType of priorAuthCaptureTransaction is set.
09-02-2015 10:46 AM - edited 09-02-2015 10:48 AM
Just try it with AIM sample code, it look like you are correct, it not working. I pretty sure it work before as I try it myself when it first came out.
Ok. Try it with a different way. Did it with AUTH_CAPTURE and it works.
09-02-2015 11:58 AM - edited 09-02-2015 12:07 PM