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?
It does work with authCaptureTransaction. Using authOnlyTransaction works fine, too, so priorAuthCaptureTransaction is definitely the problem.
If you're seeing similar behavior if you try to separate auth and capture, that would seem to rule out my account configuration and SDK issues (I'm assuming you're not using the same SDK), leaving either this isn't how the API is supposed to be called, or the API isn't working like it should. Any idea how to determine which it is?
When I first read about partial authorization, that's what I assumed I would have to do. Only when I read about split tender transactions and this split tender id being tracked between them that I thought I was supposed to be doing something different. Honestly, I have no idea what the split tender id is for if I have to capture each transaction individually. They're not really "grouped" anymore into any kind of atomic operation.
How do I get a mod's attention? I don't see any kind of PM or direct contact funcationality on this message board.
I appreciate the time you took to look into it for me.
I've reported your issue to the product team for analysis.
I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.
I face the same issue with the iOS SDK.
I actually created another post for this:
Is there any update on this?
Did you find a solution?
I'm just capturing the transaction id of each partial auth individually. I am still collecting and passing around the split tender id, even though it doesn't look like it actually does anything. I had already done it, and I'm still holding out some hope that the API will eventually get fixed and it'll be easier for me to transition back.
My guess is that Authorize.Net can't make it an atomic operation, because on their side they have to contact potentially different banks (or gateways, processors, whatever the term is), one for each card, and there's no way for those banks to keep in sync with each other. If they exposed it as one operation and it failed halfway though, what would we see/do as consumers of the API? Sure, if we tried the same operation again, they could skip the ones that succeeded and just try the ones that failed again, but what if they continually fail? What if we never send the operation again? It would be left in some kind of half-captured state that may be hard to diagnose or back out of.
At least that's my theory. It doesn't mean they shouldn't fix the API documentation to keep people like us from assuming it does work. I'd also still like to know what benefit this split tender id even offers. I guess it shows multiple transactions as related when you view it in the web admin, but that's about it.