Question

我在理解authorize.net事务详细信息API（documentation here）时遇到了一些麻烦。我会尽力做到简短。

从授权中提取交易状态更新的唯一实用方法（不使用他们的“无声帖子”功能，这看起来像是一大堆梦魇*），是获得已结算交易的批量清单（比如让我们说一天）然后为每个已结算的批次提取交易清单。例如：

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
pendingFinalSettlement
pendingSettlement
underReview
updatingSettlement
FDSPendingReview
FDSAuthorizedPendingReview
authorizedPendingRelease

这些，我不确定：

returnedItem（？）
退款（？）
chargebackReversal（？）
approvedReview（？）

getUnsettledTransactionList只会在你的膝盖上转储最后1000个'未结算'的交易，包括拒绝，错误等等 - 这使得它非常不可靠，不提你必须解析那个垃圾。

所以，我的问题是：

上面的最后四种状态有什么用？我是否应该期待这些改变？
其中哪一个进入“已确定”批次？（settlementError和settledSuccessfully？JUST settledSuccessfully？）
定期结算交易（documentation here）是否会显示在已结算的批次中？
是否真的无法从授权中提取“待处理”交易，忽略所有不相关的error，declined等等？似乎有必要重复计费 - 因为否则，应用程序（代替事务ID）无法知道订阅事务是否存在问题，直到有足够的时间通过，您可以放心地认为它应该出现在已批准的批次。

*由于两次超时，失败且永不与您交谈的政策，以及必须依赖用户正确配置其设置

Answer 1

我收到了Authorize.net的回复。这是：

与事务状态混淆的一部分是事务状态对象是由我们在内部使用的类似对象构建的，并且在我们的系统中包含了可能的事务状态。实际上，您作为外部开发人员实际上看不到其中一些状态。我检查了我们的公共知识库，并确认我们目前没有所有交易状态的良好列表，所以我正在为你创建一个。我正在与我们的内部开发人员合作，以确认有关状态的一些细节，我会尽快回复该列表。我现在可以回答你的其他问题。

其中哪一个进入“已确定”的批次？（settlementError AND settledSuccessfully？只是settledSuccessfully？）

在Authorize.Net中，当事务状态为final时，所有事务都将移动到批处理中。这是批量的Authorize.Net定义和大多数商家服务提供商使用的定义的重大差异。由于我们的所有报告都按批次进行组织，因此所有交易最终都要批量生产，这一点非常重要。

定期结算交易（[此处提供] [2]）甚至显示在已落定的批次中？

是的，自动定期结算（ARB）系统发起的交易在创建后与任何其他交易没有区别。

真的没有办法从中提取'待定'交易授权，忽略所有不相关的error，declined等等？似乎有必要重复计费 - 因为否则，一个应用程序（代替交易ID）无法知道是否有订阅事务的问题，直到足够的时间过去你可以放心地认为它应该以一个稳定的批次出现。

目前无法提取仅有成功的未结算交易的列表，也无法仅提取与特定ARB订阅相关联的交易。我们知道这个限制，并对如何解决它有一些想法，但不幸的是，以编程方式检查ARB交易的唯一100％可靠方法是在结算后拉出整批。

我正在努力制作更多用于定义这些字段的官方文档，但我想我会发布到目前为止的内容：

基本交易状态
我不认为这些状态需要进一步解释，但如果我弄错了，请告诉我 - authorizedPendingCapture
- capturePendingSettlement
- refundPendingSettlement
- 已成功结算 - refundSettledSuccessfully
- 无效 - 过期的 - 谢绝了

欺诈检测套件（FDS或AFDS）特定回复
这两种状态都表明交易正在等待商家进行人工审核 - FDSPendingReview
- FDSAuthorizedPendingReview

eCheck特定回复
- underReview - 在人工审核下，将被批准或拒绝 - failedReview - 未通过审核的交易的最终状态 - returnedItem - 这不会显示在原始事务上，但是eCheck返回生成具有此状态的自己的事务。

其他错误
- communicationError - 处理器拒绝单个事务。这是最终交易状态 - settlementError - 处理器拒绝了一天的批处理。这种状态不是最终的。商家应该尝试恢复批次 - 常规错误 - 这是未定义的任何事务状态的全部捕获状态。

过渡交易状态
这些交易状态仅在交易发生时发生。它们不应由交易细节API返回 - couldNotVoid
- approvedReview

遗产状态
这些交易状态涉及我们未提供超过3年的服务。由于Authorize.Net商家帐户仅存储了2 - 3年的历史记录，因此您无法在任何正常操作中看到实际返回的这些状态。
- 待定最终结算
- 待定结算
- 更新结算
- 退款
- chargebackReversal
- authorizedPendingRelease

从authorize.net获取交易详情

1 个答案: