Magento 支付流程
我正在致力于为 Magento 实现一个新的支付模块,并希望了解这个逻辑背后的核心概念。我知道我必须从 Mage_Payment_Model_Method_Abstract 或其任何子类进行扩展,但我的问题是何时使用以及如何在我的模型中使用捕获和授权方法。 例如,如果我将整个过程分成如下步骤:
- 用户来到购物车并选择某种付款方式,即网关。
- 系统拦截请求,收集所有提交的数据并将用户发送到网关 URL。
- 用户在网关站点下订单(或取消订单),网关站点将有关订单的信息发送到我的商店。
- 我的商店使用收到的数据对订单进行更多修改,并保存状态为已完成或已取消的订单。
在这些步骤中,我必须在哪里使用授权和捕获方法?如果有人能向我解释授权和捕获的含义,我将不胜感激?
I am working on implementing a new payment module for Magento and want to understand the core concept behind this logic. I know I have to extend from Mage_Payment_Model_Method_Abstract or any of its children classes, but my problem is when to use and how to use capture and authorize methods in my model.
For example if I split the whole process in steps like this:
- User comes to the shopping cart and choses lets say some payment method which is gateway.
- The system intercepts the request, collects all submitted data and sends the user to the gateway url.
- User places his order (or cancels) at the gateway site which sends information about it to my store.
- My store does some more modifications to the order with the received data and saves the order with status completed or canceled.
Where in these steps will I have to use authorize and capture methods ? I would appreciate if someone could explain to me what authorize and capture means?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这是我一直以来理解这些概念的方式,以及在 Magento 中实现支付模块所需了解的内容。您的具体“这种情况发生在哪里”的答案在下面以粗体显示,尽管它并不像您希望的那么简单。
在互联网出现之前,实体信用卡交易分为两个阶段。
在销售时,当商家拿着消费者的信用卡进行购买时,他们会将其滑过销售点设备,该设备会呼叫信用卡的中央办公室并询问“这张卡是否已获得该网络的授权,以及该特定消费者的可用信用额度是否足够大以允许进行此次购买”。
如果购买被接受(而不是被拒绝),则该费用被称为“授权”。消费者将拿起他们的产品,销售点系统/收银机将注意到交易已获得授权。然后,在一天结束时或一周结束时,按照其他预定的定期时间表,或者当所有者决定停止饮酒时,商家将检查所有授权收据并发送另一张授权交易中获取资金。获取资金就是将钱存入商家的账户。
这仍然是大多数网关使用的模型,也是 Magento Inc. 选择为其支付模块实施的域模型。
事情应该运行的方式是,当消费者在 Magento 等系统中到达最终结账步骤时,Magento 会向网关的 API 发出授权请求。如果交易成功,订单将被系统接受,并存储来自授权请求的唯一 ID。接下来,当消费者的货物发货时,店主使用 Magento 管理员创建发票。此发票的创建会发出捕获请求(使用从授权请求返回的商店 ID)。 这是在 Magento 中发出这些方法调用的地方。
然而,事情变得棘手,因为每个支付网关对这些概念的解释都略有不同,并且每个商家对“在我们发货之前不要捕获”责任的解释也不同。除了上述场景之外,支付模块还有一个称为“支付操作”的系统配置值。可以将其设置为“仅授权”,这将实现上述流程。它还可以设置为授权和捕获,这将在下订单时授权并捕获付款。它甚至变得更令人困惑,因为尽管该方法称为 Authorize 和 Capture,但当前版本的 Magento 仅在设置为这种模式时才会发出捕获请求(至少对于 Authorize.net 而言),而 Authorize.net在一天的大部分时间里,内部会将捕获请求置于已授权但未捕获的状态。 Magento 如何处理订单、付款和发票是代码库中随版本变化很大的一个领域。
因此,Magento 支付模块系统背后的想法是保护您免受 Cluster F 的影响——即编程支付网关逻辑。在您的
authorize
方法中,您实现对支付网关的授权 API 的调用(或执行您此时想要发生的任何检查和逻辑)。该方法传递一个支付对象和一个金额。如果您让您请求/执行您的逻辑并确定它因任何原因无效,您将抛出一个异常,这告诉 Magento 授权失败,并且它将采取相应的行动(显示错误消息等)。否则,您可以在 Payment 对象上设置数据成员并发出 a
数据成员是您稍后在捕获付款时需要的内容。这将我们带到支付模块的
capture
方法。此方法还会发送支付对象和金额。在这种方法中,您发出捕获请求。付款对象将具有cc_trans_id
数据成员,该成员允许您针对网关发出捕获。这是您负责在
authorize
中保存的数据成员之一。同样,如果您的代码确定捕获失败,则会抛出异常。否则,您返回$this
。Authorize.net 支付模块有很好的示例说明如何完成此操作。
例如,考虑
capture
方法的这一部分。这里,capture 方法正在检查付款是否具有
cc_trans_id
。根据结果,它将anet_trans_type
设置为以下任一值:然后,API 请求对象使用该值发送 API 调用以进行以下任一操作:
Here's the way I've always understood the concepts, and what you'll need to know to implement a payment module in Magento. Answers to your specific "where does this happen" are bolded below, although it's not quite as simple as you're hoping for.
Pre-internet, brick and mortar credit card transactions were a two stage process.
At the time of a sale, when the merchant took a consumer's credit card for a purchase they'd slide it through a point of sale device which would call into the credit card's central office and ask "is this card authorized for this network, and is this particular consumer's line of available credit large enough to allow this purchase".
If the purchase was accepted (as opposed to declined), the charge was said to be authorized. The consumer would take their product, and the point of sale system/cash-register would note that the transaction was authorized. Then, at the end of a the day, or the end of the week, at some other predetermined regular schedule, or when the owner decided to stop drinking, the merchant would go though all their authorized receipts and send another request to the central office to capture the funds from the authorized transaction. Capturing the funds is what puts money in the merchant's account.
This is still the model in use by most gateways, and is the domain model that Magento Inc. chose to implement for their payment modules.
The way things are supposed to run is, when a consumer reaches the final checkout steps in a system like Magento, Magento issues an authorization request to the gateway's API. If the transaction is successful, the order is accepted into the system, and a unique ID from the authorization request is stored. Next, when the consumer's goods ship, a store owner uses the Magento admin to create an invoice. The creation of this invoice issues a capture request (using a store id returned from the authorization request). This is where these method calls are issued in Magento.
However, things get tricky because every payment gateway interprets these concepts a little differently, and every merchant interprets their "don't capture until we've shipped" responsibilities differently. In addition to the scenario described above, payment modules have a system configuration value known as a Payment Action. This can be set to Authorize Only, which will implement the flow described above. It can also be set to Authorize and Capture, which will both authorize and capture a payment when the order is placed. It gets even more confusing because although the method is called Authorize and Capture, current versions of Magento will only issue the capture request when set in this mode (at least for Authorize.net), and Authorize.net will, internally, leave capture requests in an authorized but not captured state for most of the day. How Magento handles orders and payments and invoices is one area of the codebase that changes a lot from version to version.
So, the idea behind the Magento payment module system is to shield you from the Cluster F--- that is programming payment Gateway logic. In your
authorize
method you implement a call to your payment gateway's authorize API (or perform whatever checks and logic you want to happen at this point). This method is passed a payment object and an amount. If you make you request/perform-your-logic and determine it's invalid for whatever reason, you throw an Exception withThis tells Magento the authorization failed, and it will act accordingly (show an error message, etc.). Otherwise, you set data members on the Payment object and issue a
The data members are things you'll need later, when capturing the payment. Which brings us to the
capture
method of your Payment module. This method is also sent a payment object and an amount. In this method you issue your capture request. The payment object will havecc_trans_id
data memberwhich will allow you to issue a capture against your gateway. This is one of the data members you're responsible for saving up in
authorize
. Again, if your code determines the capture has failed, you throw an exception. Otherwise, youreturn $this
.The authorize.net payment module has good examples of how this is done.
For example, consider this part of the
capture
methodHere the capture method is checking if the payment has a
cc_trans_id
. Depending on the result, it setsanet_trans_type
to either:This value is then used by the API request object to send an API call for either