从 authorize.net 获取交易详情

Posted 2023-02-22

【中文标题】从 authorize.net 获取交易详情

【英文标题】：Getting transaction details from authorize.net

【发布时间】：2011-08-30 02:30:49

【问题描述】：

我在理解 authorize.net Transaction Details 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));

然而，有多种可能的交易状态。

这些似乎是“最终的”且不可更改：

通讯错误 refundSettledSuccessfully 拒绝 couldNotVoid 已过期 一般错误 审核失败 成功解决 结算错误 作废

以下似乎是“待定”状态：

authorizedPendingCapture 捕获的PendingSettlement refundPendingSettlement 等待最终结算 待结算 审核中 更新结算 FDSPendingReview FDSAuthorizedPendingReview authorizedPendingRelease

这些，我不确定：

returnedItem (?) 退款 (?) chargebackReversal (?) approvedReview (?)

getUnsettledTransactionList 只是转储您膝上的最后 1000 个“未解决”交易，包括拒绝、错误等 - 使其非常不可靠，更不用说您必须解析那些垃圾。

所以，我的问题是：

上面的最后四个状态是怎么回事？我应该期待这些改变吗？

其中哪些属于“已解决”批次？ （settlementError AND settledSuccessfully? 只是settledSuccessfully?）

定期计费交易 (documentation here) 是否会出现在已结算的批次中？

真的没有办法只从授权中提取“待处理”交易，而忽略所有不相关的error、declined 等？重复计费似乎是必要的——因为否则，应用程序（代替交易 ID）无法知道订阅交易是否存在问题，直到有足够的时间过去，您可以放心地假设它应该出现在一个固定的批次。

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

【问题讨论】：

您应该在support forums 中询问。他们的员工在那里闲逛，可以为您回答此类问题。

【参考方案1】：

我收到了来自 Authorize.net 的回复：

---

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

其中哪些属于“已解决”批次？ （settlementError 和 settledSuccessfully?只是settledSuccessfully？ )

在 Authorize.Net 中，当事务状态为最终状态时，所有事务都会被移动到一个批次中。这是 Authorize.Net 批次定义与大多数商家服务提供商使用的定义的显着差异。因为我们所有的报告都是分批组织的，所以您的所有交易最终都以一个批次结束是很重要的。

定期结算交易（[此处的文档][2]）甚至显示 在已解决的批次中？

是的，由自动定期计费 (ARB) 系统发起的交易在创建后的处理方式与任何其他交易没有区别。

真的没有办法只提取“待处理”交易吗？ 授权，忽略所有不相关的error、declined 等？ 重复计费似乎是必要的——因为否则，一个应用程序 （代替交易ID）无法知道是否存在 订阅交易出现问题，直到有足够的时间过去 您可以放心地假设它应该以固定的批次出现。

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

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

基本交易状态 我认为这些状态不需要任何进一步的解释，但如果我弄错了，请告诉我。 - 授权PendingCapture - 捕获PendingSettlement - 退款待定结算 - 成功解决 - 退款成功解决 - 作废 - 过期 - 拒绝

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

eCheck 具体回复 - underReview - 在人工审核中，将被批准或拒绝。 - failedReview - 未通过审核的交易的最终状态。 -returnedItem - 这不会显示在原始交易中，但 eCheck 退货会生成具有此状态的自己的交易。

其他错误 -communicationError - 单个交易被处理器拒绝。这是最终的交易状态。 - 结算错误 - 处理者拒绝了一天的批次。此状态不是最终状态。商家应尝试恢复该批次。 - 一般错误 - 这是未另行定义的任何事务状态的包罗万象的状态。

过渡交易状态 这些事务状态仅在事务发生时出现。事务详细信息 API 不应返回它们。 - couldNotVoid - 批准评论

旧版状态 这些交易状态与我们超过 3 年未提供的服务有关。由于 Authorize.Net 商家帐户仅存储 2-3 年的历史记录，因此您不会在任何正常操作中看到这些状态实际返回。 - 未决最终结算 - 未决结算 - 更新结算 - 退款 - 退款逆转 - 授权PendingRelease