同城商城搭建联调阶段常见误区是把「调起支付通道」和「下单写单」绑在同一次点击里一点支付同时创建订单、调起收款、改库存。任一环节失败用户都看到「支付失败」研发却难定位是下单问题还是通道问题。正确做法是支付通道与下单收款拆开测先保证订单写入口稳定再测通道调起与回调最后做端到端小额单。结论订单单写、收款可重试、回调防重复用户提交购物车 - order-service 创建订单 (statuscreated) - 返回 order_id payable_amount - payment-service 创建支付意图 (intent_id) - 客户端调起通道 - 回调 - 验签 - 更新订单 statuspaid禁止在未创建订单前直接调支付也禁止回调里才第一次写订单主表。下单流程单一写入口defcreate_mall_order(user_id:str,cart_lines:list)-dict:snapshotcatalog.quote(cart_lines)# 价格快照写入订单行order_idorder_repo.insert({user_id:user_id,status:created,amount:snapshot.total,lines:snapshot.lines,})return{order_id:order_id,amount:snapshot.total}商品改价只影响新单历史订单行保持下单时快照避免对账时「页面一个数、导出另一个数」。支付意图与订单绑定、可单独重试defcreate_payment_intent(order_id:str)-dict:orderorder_repo.get(order_id)iforder.statusnotin(created,pay_pending):raiseBusinessError(order not payable)intent_idpayment_repo.create_intent(order_idorder_id,amountorder.amount,idempotency_keyfpay:{order_id}:{order.pay_attempt},)order_repo.update_status(order_id,pay_pending)return{intent_id:intent_id,client_payload:build_channel_payload(intent_id)}用户关闭支付窗口后再次点击应复用或递增pay_attempt而不是新建影子订单。回调验签 幂等 状态机defon_payment_notify(payload:dict,signature:str):verify_signature(payload,signature)intentpayment_repo.get(payload[intent_id])withorder_repo.lock(intent.order_id):orderorder_repo.get(intent.order_id)iforder.statuspaid:returnOK# 幂等ifpayload[status]!success:order_repo.update_status(intent.order_id,pay_failed)returnOKorder_repo.update_status(intent.order_id,paid)inventory_service.commit(intent.order_id)returnOK拆开测的三段验收段 1仅下单不调通道订单created可查库存预占正确。段 2仅支付意图 沙箱回调固定order_id验证回调幂等与验签。段 3端到端小额单正式或准生产环境导出字段与订单行一致。与商城页面的关系页面团队可先验收展示与购物车支付团队用固定order_id测意图与回调。不必等 UI 定稿才第一次写订单服务。常见踩坑坑 1前端本地改「已支付」以回调后服务端状态为准禁止 UI 抢先。坑 2支付金额由前端传入金额必须来自订单服务通道侧与订单侧交叉校验。坑 3退款走另一套订单库售后宜关联原order_id不新建平行表。光合同城边界光合同城同城电商成品含订单写入口与可配置支付对接底座支持支付意图与下单分开验收私有化源码交付。具体国家/通道按需定制对接商务结算规则由客户确定系统侧不抽成客户平台订单。小结同城商城搭建联调时把支付意图与下单流程拆开测定位快、返工少端到端通过后再做页面美化比「一点支付碰运气」稳得多。联调现场怎么拆问题很多团队第一次联调会把「购物车能加」和「通道能扣款」当成同一张验收表。更实用的拆法是先在测试环境只走下单接口固定两件商品、固定金额确认订单表里状态为已创建且订单行价格与商品快照一致。第二步才用同一订单号创建支付意图在沙箱里走完回调看状态是否变成已支付而不会重复扣库存。第三段才是端到端用户从页面点支付。若第三段失败回查前两段哪一段红了而不是从零猜测。财务同事宜在第二段就参与导出表格是否与订单应付金额一致。这一步通过后面换页面皮肤不会动到对账口径。上线前还可模拟回调重复投递、支付失败回调看订单是否仍停在可重试状态。交付验收宜归档下单段、支付段、端到端段各一张签字表附测试订单号与导出样例便于第二城复制同一套拆法。