2011-05-21 66 views
6

我在理解authorize.net交易詳情API(documentation here)時遇到了一些麻煩。我會盡我所能來簡要介紹一下。從authorize.net獲取交易詳情

從授權中提取交易狀態更新的唯一實用方法是(不使用他們的'silent post'功能,這看起來像是一大噩夢*),是獲得一個已結算交易的批次清單日),然後爲每個結算批次提取交易清單。例如:

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)); 

然而,有很多可能的交易狀態。

這些似乎是 '最終' 的,不可改變的:

  • communicationError
  • refundSettledSuccessfully
  • 下降
  • couldNotVoid
  • 過期
  • generalError
  • failedReview
  • settledSuccessfully
  • settlementError
  • 空隙

以下顯示爲 '待處理' 的狀態:

  • authorizedPendingCapture
  • capturedPendingSettlement
  • refundPendingSettlement
  • pendingFina lSettlement
  • pendingSettlement
  • underReview
  • updatingSettlement
  • FDSPendingReview
  • FDSAuthorizedPendingReview
  • authorizedPendingRelease

這些,我不知道:

  • returnedItem(?)
  • 扣款(?)
  • chargebackReversal(?)
  • approvedReview(?)

的getUnsettledTransactionList只是轉儲最後的1000 '懸而未決' 你的大腿上交易,包括拒絕,錯誤等 - 使它非常不可靠,沒有提到你必須解析那些垃圾。

所以,我的問題是:

  • 什麼上面最後四種狀態了?我應該期望這些改變嗎?

  • 其中哪些進入「已結算」批次? (settlementErrorsettledSuccessfully?JUST settledSuccessfully?)

  • 做定期結算交易(documentation here)即使在結算批次顯示?

  • 難道真的沒有辦法從授權中拉出'掛起'的交易,忽略所有不相關的error,declined等?似乎有必要重複開單 - 因爲否則,應用程序(代替交易ID)無法知道訂閱交易是否有問題,直到有足夠的時間過去,您可以安全地假設它應該顯示在一個結算的批次。

*由於兩秒超時,失敗,和從未談話到你,再政策,加上不必依賴於用戶正確配置其設置

+1

你應該問在[支持論壇](http://community.developer.authorize.net/t5 /集成和 - 檢測/ BD-p/Integration01)。他們的員工掛在那裏,可以爲你解答這樣的問題。 – 2011-05-23 13:20:56

回答

7

我已經得到了從Authorize.net響應這就是:


與交易狀態混亂的部分是交易狀態的對象是建立關閉,我們內部使用和以往任何時候都包括可能的交易狀態的類似物體的我們的系統。其中一些地位實際上從未真正被您視爲外部開發者。我檢查了我們的公共知識庫並確認我們目前沒有所有交易狀態的良好列表,所以我正在爲您創建一個。我正在與我們的內部開發人員合作,以確認有關狀態的一些詳細信息,我會盡快回復該列表。我現在可以回答你的其他問題。

其中哪些進入「結算」批次? (settlementErrorsettledSuccessfully?JUST settledSuccessfully?)

在Authorize.Net,所有交易都搬進了一批在交易狀態是最終決定。這是一個批次的Authorize.Net定義和大多數商家服務提供商使用的定義中的重大差異。由於我們所有的報告都是按批次進行組織的,因此重要的是您的所有交易最終都會一批一批地完成。

重複結算交易([此處的文檔] [2])甚至在結算的批次中顯示 ?

是的,自動循環計費(ARB)系統啓動的交易在創建時與其他任何交易都沒有區別。

難道真的沒有辦法拉只是「待定」從 授權交易,忽略所有的不相關errordeclined等的呢? 似乎有必要重複計費 - 因爲否則,應用程序 (代替交易ID)無法知道訂閱交易是否存在 問題,直到有足夠的時間通過,您可以安全地假定它應該已經出現在一個穩定的批次中。

目前沒有辦法拉取只有成功的未結算交易列表或僅拉取與特定ARB訂閱相關聯的交易的列表。我們意識到這一侷限性,並對如何解決這個問題有一些想法,但不幸的是,以編程方式檢查ARB交易的唯一100%可靠的方法是在結算後提取整批貨物。

我正在努力,使更多的正式文件中定義這些領域,但我想我會寄我到目前爲止有:

BasicTransaction以下狀態
我不認爲這些狀態需要任何進一步的解釋,但讓我知道如果我錯了。
- authorizedPendingCapture
- capturedPendingSettlement
- refundPendingSettlement
- settledSuccessfully
- refundSettledSuccessfully
- 作廢
- 過期
- 拒絕

欺詐檢測套件(FDS或AFDS)特異性應答
這兩種狀態都表明交易是等待商家進行人工審查。
- FDSPendingReview
- FDSAuthorizedPendingReview

電子支票具體答覆
- underReview - 在人工審覈,將被批准或拒絕。
- failedReview - 未通過審覈的交易的最終狀態。
- returnedItem - 這不會顯示在原始交易上,但eCheck返回將生成具有此狀態的自己的交易。

其他錯誤
- communicationError - 單個事務被處理器拒絕。這是最終的交易狀態。
- settlementError - 一天的批次被處理器拒絕。這種狀態不是最終的。商家應該嘗試恢復批次。
- 一般錯誤 - 這是任何未另行定義的交易狀態的全部狀態。

過渡交易狀態
這些交易狀態發生僅作爲交易正在發生。它們不應該由Transaction Details API返回。
- couldNotVoid
- approvedReview

遺留狀態
這些交易狀態相關的,我們還沒有3年以上提供的服務。由於Authorize.Net商戶帳戶僅存儲2 - 3年的歷史記錄,因此在任何正常操作中都不會看到實際返回的這些狀態。
- pendingFinalSettlement
- pendingSettlement
- updatingSettlement
- 扣費
- chargebackReversal
- authorizedPendingRelease