topic Getting transaction details in Integration and Testing

Getting transaction details

stymiee — Wed, 06 Jul 2011 14:54:52 GMT

This question was asked at StackOverflow but did not receive an answer so I am asking it here.

I'm having some trouble making sense of the Transaction Details API. I'll try my best to be brief.

The only practical way of pulling transaction status updates from authorize (without using their 'silent post' feature, which seems like a big bag of nightmares* ), is to get a batch list of settled transactions (for let's say a day) and then pull transaction lists for every settled batch. Eg:

public function getTransactionsForDay($month = false, $day = false, $year = false)
{
    $transactions = array();
    $month = ($month ? $month : date('m'));
    $day = ($day ? $day : date('d'));
    $year = ($year ? $year : date('Y'));
    $firstSettlementDate = substr(date('c',mktime(0, 0, 0, (int)$month, (int)$day, (int)$year)),0,-6);
    $lastSettlementDate  = substr(date('c',mktime(0, 0, 0, (int)$month, (int)$day, (int)$year)),0,-6);
    $response = $this->getSettledBatchList(true, $firstSettlementDate, $lastSettlementDate);
    $batches = $response->xpath("batchList/batch");
    foreach ($batches as $batch) {
        $batch_id = (string)$batch->batchId;
        $request = new AuthorizeNetTD;
        $tran_list = $request->getTransactionList($batch_id);
        $transactions = array_merge($transactions, $tran_list->xpath("transactions/transaction"));
    }
    return $transactions;
}

   $request = new AuthorizeNetTD;
    $transactions = $request->getTransactionsForDay(12, 8, 2010);
    $this->assertTrue(is_array($transactions));

Yet, there's a multitude of possible transaction statuses.

These appear to be 'final' and unchangeable:

- communicationError
- refundSettledSuccessfully
- declined
- couldNotVoid
- expired
- generalError
- failedReview
- settledSuccessfully
- settlementError
- voided

The following appear to be 'pending' statuses:

- authorizedPendingCapture
- capturedPendingSettlement
- refundPendingSettlement
- pendingFinalSettlement
- pendingSettlement
- underReview
- updatingSettlement
- FDSPendingReview
- FDSAuthorizedPendingReview
- authorizedPendingRelease

These, I'm not sure about:

- returnedItem (?)
- chargeback (?)
- chargebackReversal (?)
- approvedReview (?)

The getUnsettledTransactionList just dumps the last 1000 'unsettled' transactions on your lap, including declined, error, etc -- making it pretty unreliable, not mention you have to parse that junk. So, my questions are:

- What's up with the last four statuses above? Should I expect those to change or not?

- Which of these go into a 'settled' batch? (`settlementError` AND `settledSuccessfully`? JUST `settledSuccessfully`? )

- Do recurring billing transactions ([documentation here][2]) even show up in the settled batches?

- Is there really no way to pull just the 'pending' transactions from authorize, ignoring all the irrelevant `error`, `declined`, etc ones? It seems necessary for recurring billing -- because otherwise, an app (in lieu of a transaction id) has no way of knowing if there's a problem with a subscription transaction, until enough time passes that you can safely assume it should have showed up in a settled batch.

* due to the two second timeout, fail-and-never-talk-to-you-again policy, plus having to rely on users to properly configure their settings*

Re: Getting transaction details

Trevor — Fri, 08 Jul 2011 22:07:51 GMT

A part of the confusion with the transaction statuses is that the transaction status object is built off of a similar object that we use internally and includes ever possible transaction status in our system. Some of these status will effectively never actually be seen by you as an external developer. I've checked our public knowledge base and confirmed that we don't currently have a good list of all of the transaction statuses, so I'm working on creating one for you. I'm working with our internal developers just to confirm some details on the statuses and I'll reply with that list as soon as I can. I can answer the rest of your questions right now.

Which of these go into a 'settled' batch? (`settlementError` AND `settledSuccessfully`? JUST `settledSuccessfully`? )

Within Authorize.Net, all transactions are moved into a batch when the transaction state is final. This is a significant difference in the Authorize.Net definition of a batch and the definition used by most merchant services provider. Because all of our reporting is organized into batches, it is important that all of your transactions ultimately end up in a batch.

Do recurring billing transactions ([documentation here][2]) even show up in the settled batches?

Yes, the transactions initiated by the Automated Recurring Billing (ARB) system are treated no different from any other transaction once they are created.

Is there really no way to pull just the 'pending' transactions from authorize, ignoring all the irrelevant `error`, `declined`, etc ones? It seems necessary for recurring billing -- because otherwise, an app (in lieu of a transaction id) has no way of knowing if there's a problem with a subscription transaction, until enough time passes that you can safely assume it should have showed up in a settled batch.

There is currently no way to pull a list of only successful unsettled transactions or of pulling only transactions that are associated with a specific ARB subscription. We are aware of this limitation and have a few ideas of how to address it, but unfortunately the only 100% reliable way of checking ARB transactions programmatically is to pull the whole batch after settlement.

Re: Getting transaction details

Trevor — Fri, 19 Aug 2011 23:10:57 GMT

I'm working towards making more of an official document for defining these fields, but I thought I would post what I have so far:

BasicTransaction Statuses

I don't think these statuses need any further explanation, but let me know if I'm mistaken.

authorizedPendingCapture
capturedPendingSettlement
refundPendingSettlement
settledSuccessfully
refundSettledSuccessfully
voided
expired
declined

Fraud Detection Suite (FDS or AFDS) Specific Responses

Both of these statuses indicate that a transaction is pending manual review by the merchant.

FDSPendingReview
FDSAuthorizedPendingReview

eCheck Specific Responses

underReview - Under manual review, will be approved or declined.
failedReview - Final status of a transaction that fails review.
returnedItem - This will not show on an original transaction, but eCheck returns generate their own transactions with this status.

Other Errors

communicationError - An individual transaction was rejected by the processor. This is a final transaction status.
settlementError - A day's batch was rejected by the processor. This status is not final. The merchant should try to recover the batch.
General Error - This is a catch-all status for any transaction status that is not otherwise defined.

Transitional Transaction Statuses

These transaction statuses occur only as a transaction is taking place. They should not be returned by the Transaction Details API.

couldNotVoid
approvedReview

Legacy Statuses

These transaction statuses relate to services that we have not offered for over 3 years. Because an Authorize.Net merchant account stores only 2-3 years of history, you will not see these statuses actually returned in any normal operation.

pendingFinalSettlement
pendingSettlement
updatingSettlement
chargeback
chargebackReversal
authorizedPendingRelease

Re: Getting transaction details

stymiee — Sun, 21 Aug 2011 01:34:36 GMT

Thanks, Trevor. I've relayed this information to the original question asker.

Re: Getting transaction details

svetozar — Wed, 07 Mar 2012 18:21:12 GMT

Hi Trevor,

Did you have a chance to create an official document after you finalized your research? Just wondering whether you have any new info since this post...

Thanks