支付平台因超时或重试重复发送 Webhook 是正常机制,Magento 2 接口必须做到幂等。本文说明事件去重、事务锁、订单状态判断和响应时机,避免重复开票与重复发货。

继续阅读

创建发票提示没有可开票商品时,应核对订单行 qty_ordered、qty_invoiced、父子商品、退款与支付 Capture 状态,而不是直接改订单状态。

继续阅读

出现 MySQL Deadlock 时,保存 InnoDB 现场,识别冲突事务、锁顺序和可安全重试的业务边界。

继续阅读

部分发货后可发数量异常,应核对 order item 父子行、qty_shipped、虚拟商品和 MSI Source deduction。

继续阅读
后台给多网站订单开票时,发票号偶尔用了另一个店铺的前缀。真正要追的是创建发票时的 store_id,而不是订单页面显示的 Store View。继续阅读

Reservation 补偿前必须先确认订单状态和重复事件。命令能生成补偿记录,但不能替你判断业务事实。

继续阅读

订单死锁不是简单加重试次数。先从数据库 deadlock 记录还原锁顺序,再缩短事务、统一更新顺序并保证重试幂等。

继续阅读

订单没有创建发票按钮,先检查是否已经开票、订单状态是否允许、商品数量和支付动作,而不是直接修改按钮显示代码。

继续阅读

成功页依赖checkout session中的last order数据,支付模块提前清Session或跨域Cookie丢失会导致订单存在但页面空白。

继续阅读

下单时Extension Attribute里有值,订单也保存成功,但再次通过Repository或REST读取却变成空。字段必须同时打通写入、持久化和读回三条链路。

继续阅读

项目 1 到 10 共 13个

每页
  1. 1
  2. 2
设置升序顺序