getting duplicate transactions in getTransactionList

[AndyOlson]

After the https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Enhanced-Customer-Prof... announcement that added the CIM profile id's to the getTransactionList, we're now noticing transaction nodes getting duplicated.  One of the transaction nodes will include the "profile" node with the CIM data and the other transaction will be missing that node..  Othere than that, they are duplicates, and I'm assuming that's not an intentional change..  Is it?

[Aaron]

Hi @AndyOlson,

Same transaction ID in both nodes?

[AndyOlson]

yes.  Same transaction record.  The only difference between the two is one has the profile node and the other doesn't

[Aaron]

Great. I don't have settled profile transactions in my sandbox account to look at right now, but I'll try some testing on my end and wait for the transactions to settle.

In the meantime, is every transaction node that's associated with a profile duplicated (without profile info in the duplicate), or just some of them?

[AndyOlson]

Not all are duplicated...  out of 151 from yesterday, 103 had duplicate transaction nodes (one with a profile node, one without).  All 48 of the transactions that showed up only once had a profile node.

I'm looking to see if I can find something about the rows that signifies them as different, but haven't seen a pattern yet.

[AndyOlson]

Just found a couple of patterns...  It appears to be tied around if the transaction flowed through an Authorize then Capture or AuthorizeCapture in one step flow.  Here's how I got there..

1. All voids and declines have only 1 node per transactionID (theoretically the authorize step)
2. All transactions that were run using AuthorizeAndCapture have only one node per transaction
3. All orders submitted first as an Authorize, then later run as a PriorAuthCapture are duplicated

Hope that helps narrow it down

[Aaron]

Hi @AndyOlson,

That's very useful information, thanks! There's two things going on here:

1. When authorization and capture happen separately, there are two entries in getTransactionListResponse. That may be by design, but I'll double-check to be sure.
2. When the two steps are reported separately, the profile info is not included for both. I suspect this may also be "working as designed". It's possible that since the capture step is just another operation on an existing transaction, we felt that it wasn't appropriate to include the profile info. However, since we're reporting it as a separate node, it's confusing not to.

I'll run this around the company to see if I can get a handle on whether or not this is working as designed. If not, we'll look to fix it. If so, we can talk about changes to make it less confusing, or at least better explanations in the documentation.

Thanks for following up on this!

[AndyOlson]

You *might* be able to convince me that it was intended to have tow listed, but then I would additionally expect to see a different state or something else aside from just the appearance or lack of appearance of the profileID.

In addition, duplication of any form before the addition of the profileID did not happen, so I would certainly call it a braking change either way as the current behavior was only ever returnig one node per transaction.  

Love to hear what you find

[AndyOlson]

Hey @Aaron,

Is there any update on this?  My accounting department is asking why the reconciliations aren't lining up and I'd like to know if there is a way forward on this one.

Thanks

[AndyOlson]

@Aaron,

Should I be submitting this somewhere else?