Odoo 企业版 POS 在线支付自助单为什么不是“支付回调到了就算后厨可做”：交易确认与备餐入列时机讲透

线上自助点餐最怕“支付看起来成功，厨房已经开做，最后交易又失败或超时”。所以后厨入列必须绑定到更稳妥的支付确认点。

核心链路

1. 在 pos_self_order_preparation_display 里，控制器 _send_to_preparation_display() 已经对“是否已支付”做过一次门控，但那是基于订单状态。
2. pos_online_payment_self_order_preparation_display/models/payment_transaction.py 再向后挪一步：它覆写 payment.transaction._process_pos_online_payment()，先走父类逻辑，再筛选 tx._is_self_order_payment_confirmed() 的交易。
3. 只有满足这个条件的交易，系统才调用 pos.prep.order.process_order(tx.pos_order_id.id)。这意味着真正推动后厨入列的，不是浏览器端“我点了支付”，也不是中间态订单，而是支付事务层的最终确认。
4. 这层设计很重要，因为在线支付场景里订单状态、支付页面状态、支付事务状态并不总是同步。企业版把后厨动作绑定到最靠近资金确认的位置。
5. 也因此，当门店出现“顾客已付但后厨没单”时，排查优先级应该是 payment transaction 是否完成 _process_pos_online_payment()，而不是先怀疑 preparation display 本身。

关键源码位置

• /home/ubuntu/odoo-temp/enterprise/pos_online_payment_self_order_preparation_display/models/payment_transaction.py
• /home/ubuntu/odoo-temp/enterprise/pos_self_order_preparation_display/controllers/orders.py

容易误解的地方

• 误区一：支付页面返回 success 就等于可备餐。源码真正看的是 _is_self_order_payment_confirmed()。
• 误区二：这个模块只是重复调用一次 process_order。实际上它把触发点从订单创建推进到了交易确认。
• 误区三：订单和支付只有一套状态。线上支付至少要区分前端状态、POS 订单状态和 payment transaction 状态。

实战注意事项

• 接第三方支付时，重点核对回调后是否走进 _process_pos_online_payment()，否则厨房永远收不到单。
• 门店要培训：看到顾客支付成功截图，不代表系统一定已经确认交易。
• 如果准备接更多线上渠道，最好把“何时允许备餐”统一挂在 transaction confirmed 语义上，别把判定散落在前端。

结语

企业版这些代码共同说明一件事：真正可上线的业务流程，靠的不是“页面上看起来能点通”，而是权限、状态、时机、对账口径和跨模块回写都被收紧。理解这些边界，实施和二开时就不容易走进“功能演示能跑、真实业务一用就散”的坑。