仅授权信用卡交易是不是应该与数据库中的授权捕获交易分开存储？

Posted 2023-02-22

【中文标题】仅授权信用卡交易是不是应该与数据库中的授权捕获交易分开存储？

【英文标题】：Should Auth-Only Credit Card Transactions be Stored Separately from Auth-Capture Transactions in a Database?仅授权信用卡交易是否应该与数据库中的授权捕获交易分开存储？

【发布时间】：2017-01-22 18:50:42

【问题描述】：

背景

我已经构建了一个连接到 Authorize.net 支付网关的电子商务应用程序。管理员可以通过以下方式处理信用卡：

“捕获”交易，管理员立即从客户的信用卡中扣款。 “仅授权”交易，管理员从信用卡中授权 $X，然后实际获取金额（见下面的数字 3） “Prior-Auth-Capture”交易，其中管理员捕获的金额等于或小于先前从“Auth-Only”交易中捕获的金额。

此问题与应如何将这些类型的事务存储在数据库中有关。我的“付款”表中有以下架构：

当进行新的付款时，我会在 PaymentAmount 字段中存储有关付款方式的信息（例如信用卡、支票、现金）。

如果 PaymentType 是“Credit Card”，我会存储 TransactionType（例如 Capture、Auth-Only、Prior-Auth-Capture”）。

PaymentAmount 列包含付款金额（如果 TransactionType 为“capture”或“prior-auth-capture”。如果 TrandactionType 为“Auth-Only”我将金额存储在 AuthorizedAmount 列中，并在 AuthExpDate 中跟踪授权金额适用的日期。

与 Authorize.net 的交易/参考数据相关的字段存储在 ApprovalCode 和 TransactionID 列中。

回到问题

现在您有了一点背景知识，让我们深入了解我的问题的细节：每笔交易都应该在这张表中获得它自己的记录吗？或者当我从他们那里获取资金时，我应该为“仅授权”交易更新现有交易吗？

示例：

每个动作的新记录： 如果用户进行“仅授权”交易，我将在 Payments 表中创建一条新记录。如果用户稍后在初始交易上运行“prior-auth-capture”交易，我应该在数据库中创建第二行还是应该更新原始交易并将捕获的金额添加到 PaymentAmount 列？

PaymentsID  TransactionID  PaymentType  PaymentAmount  AuthorizedAmount
------------------------------------------------------------------------
    1          ABC123         Auth           0.00           100.00
    2          ABC123      Auth-Capture    100.00             0.00

每个 TransactionID 单行，并使用每个 aut-capture 更新原始交易。

PaymentsID  TransactionID  PaymentType  PaymentAmount  AuthorizedAmount
------------------------------------------------------------------------
    1          ABC123         Auth           100.00           100.00

从逻辑上讲，我可以看到这两种情况的论据。一方面，如果我为每个事务创建一个新行，我可以看到每个“仅授权”事务的每个命中的良好历史记录。不利的一面是在您针对单个“仅授权”事务进行多个“预先授权捕获”事务的情况下，因为要弄清楚您还剩下多少，您必须编写一个稍微复杂的查询（将表连接到自身并按 TransactionID 分组以获得 PaymentAmount 的总和）。

如果我为每个 TransactionID 创建一行，那么我可以轻松更新 PaymentAmount 并使用简单的计算（AuthorizedAmount - PaymentAmount = AuthorizedBalance）计算授权中剩余的金额。这种方法也使事情变得更清晰，因为 TransactionID、ApprovalCode、Payment Info 和几乎所有其他内容都将保持不变，因此表中的冗余数据更少。此外，从报告的角度来看，为简单起见，大多数用户只想查看每笔交易的一行。

我很想听听您对解决此问题的正确方法的想法。

【参考方案1】：

为了简单起见，我会避免失去数据/灵活性的诱惑；如果您更新原始行，您将如何独立确定身份验证和捕获的日期/时间？捕获了多少？从网关 API 返回的各个身份验证代码和其他新值是什么？

如果在不同事务类型之间共享许多具有相同值的重复字段，则通过将它们移动到新表并存储 ID 值来进行规范化。

【参考方案2】：

我认为这里没有任何正确或错误的答案（因此问题应该基于意见关闭）。但是，我建议第三种方式...

使用您的“更新行”模型，然后使用 Authorize.net 添加一个用于存储低级通信的新表。新表将捕获付款 ID、日期/时间、身份验证类型、身份验证值等。

这样你就有了可以调试的东西，还有每张卡的日期/时间/值的历史记录，以及它们何时进行身份验证和收费。