多网关的通用数据库设计

Posted 2023-02-22

【中文标题】多网关的通用数据库设计

【英文标题】：Generic database design for multiple gateways

【发布时间】：2016-05-09 20:55:01

【问题描述】：

我正在开发一个需要支持多个支付网关的网站（带有支付功能）。我将使用omnipay包（感谢上帝，有一个包可以处理这个问题）但现在我想知道在不将其绑定到特定网关的情况下将所有支付信息存储在数据库中的最佳方式是什么。

我的第一个想法是有以下表格：

网关

（gateway_id、gateway_name、...）

付款

（payment_id、payment_amount、...）

交易

（transaction_id、gateway_id、payment_id、transaction_reference、transaction_type transaction_status、transaction_request_data、 事务响应数据...）。 类型可以是“授权”、“购买”、“退款”、“无效”等，状态可以是“成功”、“失败”、“待定”等。

通过这种方式，我可以拥有一个网关列表（Paypal、Stripe、TargetPay、WorldPay），并且每笔付款可以有多个交易（一次付款尝试可能会在第一次失败，然后再次尝试并工作但随后无效或退款）但一笔交易属于单笔付款。每个事务都是使用特定网关执行的，并且也会被存储。

我不知道这是否是最好的方法（也许它太简单了？），我想听听一些其他的想法。

谢谢！

【参考方案1】：

您的初始结构是一个良好的开端。我要包括的其他内容是：

responses，它将保存从网关发回的响应消息，以响应您的购买电话 回调。越来越多的网关在通知 url 上向调用者提供 POST 消息。这些指示来自网关的状态消息的变化，例如取消的交易或退款 退款和作废，我会将其存储在一个表中。 对回调、退款和作废的响应，如果您的结构正确，您可以将其存储在与常规响应相同的表中

您可能必须将一些数据存储为 JSON Blob，因为来自每个网关的消息结构会有所不同。您可能想要加密的一些数据，例如，如果它包含可以识别客户或信用卡的数据

【讨论】：

我正在考虑以标准格式（例如，您所说的 JSON）将请求和响应存储在事务表（transaction_request_data 和 transaction_response_data）中。您认为将它们保存在自己的桌子上会更好吗？此外，退款和无效与付款有关，因此我还考虑将它们存储为交易（在交易表中）。您认为将所有这些操作都作为“事务”处理是错误的吗？

我会将响应添加到单独的表格中。单个支付请求可能有多个响应、回调等。是否将请求数据存储在单独的表中是一个有争议的问题。

你能举个例子吗？我不确定如何以这种方式存储响应。

可能不是因为它超出了解释基础知识的范围。您存储数据的方式还取决于您使用的框架。例如在 Laravel 中，您将使用带有 $casts 参数的模型类，该参数指示带有 cast = array 的列，然后只需为该列分配一个数组值，它将为您转换为 JSON。您如何在其他框架中做到这一点可能超出了本次讨论的范围——您应该查看框架文档。在最通用的情况下，您可以在从列中分配或检索数据时手动执行 json_encode() 和 json_decode。

【参考方案2】：

我相信最好的答案是：这取决于网关提供/所需的数据彼此之间的接近程度。如果它们彼此接近，或者您可以映射各种状态类型，则将所有这些存储在单个事务表中。如果没有，那么您需要为每个支付网关维护单独的表。

但是，即使在后一种情况下，我也会有一个单一的交易表来整合所有提供商中最重要和最常见的数据，例如金额、付款状态，并且只将供应商特定的数据存储在相应的表中。

【讨论】：

我完全同意你的看法@Shadow。我认为这是一个非常复杂的问题，因为每个网关可能都有自己的数据，而且还有另一件事：有不同类型的操作：“授权”、“购买”、“退款”、“作废”……和每个操作也可能有自己的数据。所以我不确定如何实现一个能够处理所有这些情况的可靠数据库结构。