本文作者分享了完整的 O2O 预付订单的交易流程。因为用户、商家、平台运营人员、派单系统的参与，流程中有很多分支所以较为复杂。笔者将项目上遇到的情况整理、分享出来，希望对读者有所帮助。

做 O2O 相关业务，本质上是平台作为中介，将能够提供服务的商家（也就是劳动者）组织起来，然后吸引用户来购买商家的服务。商家付出了劳动也付出了时间，对于商家而言这段时间是有机会成本的。如果不给某个用户提供服务，商家可以用这段时间去服务别的用户，或者做别的事情。

现实当中常常发生临近服务时间用户取消订单，或者是商家到达制定地点却联系不上用户的情况。这时商家手上没有任务，而且一时半会儿也接不到新的订单，那么就会产生空档期。

大家使用过打车软件就会知道，用户下完单（并且司机接单）后超过一定时间，如果出于自身的原因要取消订单，用户是要给予司机一定补偿的。

其他 O2O 业务也存在类似打车业务的场景。

临近服务前或者已到了服务时间，用户取消订单，就应当对商家进行补偿。这种情况的过错方在用户，赔偿金理应由用户出。

那么用户怎么支付赔偿金呢？

考虑到少量用户存在诚信问题，会以各种方式拒绝 / 逃避赔付，从而打破 O2O 的订购 - 交付 - 实际完成付款的商业流程和契约（商家按时到达制定地点也是服务交付的一部分，也应当获得收益），那么不少情况下就有必要在下单阶段就要求用户预付款。有了预付款，就可以用来支付前面所说的赔偿金。

O2O 预付订单的交易流程与普通用户常见的 B2C、C2C 实物电商不同。前者因为更多的业务场景和支付方式，某些方面甚至还要更复杂。

下面就以上门洗碗业务为例（先不必在意业务是否合理），来设计一个交易流程。为了覆盖足够多的业务场景，以便这个设计具有更高的通用性，这里我们预设：

. 对于这项服务，用户既可以选择预付也可以选择服务后付款；

用户可以线上付款也可以线下付款；

平台的运营工具包含了会员余额（充 X 送 Y）和代金券（运营 / 客服发放，可以抵扣现金）。

一、整体流程

一次完整的服务从开始到结束包括用户下单并预付、平台派单 & 商家接单、商家提供服务、商家和用户确认最终账单并操作出账、用户最终完成付款和售后。

另外需要说的是，这里的账单指的是商品信息和费用信息，交易指的是用户的支付情况，而订单则是账单 + 交易。

因为交易明细信息（包括服务时长、服务费用、支付方式）在下单时都不是最终态，在后续过程中可能会调整，所以需要将账单和订单区分开来，而交易又有一套独立于账单和订单的流转过程。

在整个流程中，订单包含这些状态：

待预付：生成预付账单还未进行预付时的状态

处理中：用户选择了预付并跳转到收银台进行操作时的状态，如果用户在收银台未完成付款就返回，则订单状态再次变成 " 待预付 "

待确认：系统在派单中时的状态

已完成：完成服务后，订单最终完成付款了结

已取消：订单被取消后的状态

账单有这些状态：

待处理：生成账单后的初始状态

处理中：用户点击跳转到收银台进行支付时，状态 = 处理中。如果用户未完成付款，而是从收银台点击返回，那么状态变回 " 待处理 "

已完成：当账单被成功支付后，账单状态为 " 已完成 "

已关闭：当账单没有被支付或作废，则账单状态为 " 已关闭 "

交易有这些状态：

未支付：订单生成后初始状态为 " 未支付 "

已预付：当订单完成预付则该状态变为 " 已预付 "（非强制预付的订单无此状态）

已出账：未支付 & 已预付的账单由商家更新并出帐，交易状态变成 " 已出账 " 状态

已支付：服务结束后订单被成功支付，状态为 " 已支付 "（当商家确认现金支付时，不使用 " 已支付 "，而是变为 " 已确认 "）

已确认：商家在商家端点击确认收到现金，交易状态 =" 已确认 "

已退款：订单发生过支付（预付），但是后续订单被取消，则交易状态为已退款

已作废：订单未发生过支付，订单被取消后，交易状态为已作废

二、用户端下单流程

用户下单时首先需要选择服务项目、服务时间、服务人员和服务地点，以及这笔订单是否要使用代金券或者是会员余额。用户确认并操作下一步时会生成预付账单信息。系统根据策略判断该笔订单是否需要强制预付款，策略可以根据业务情况自行制定，这里举例：

产品线维度：部分产品线必须预付，其余的无需

时间维度：一天当中的某些时段需要预付

用户维度：多次取消订单用户、芝麻信用分较低用户必须预付

天气：遭遇恶劣天气时需预付

经营情况：平台单量大 / 库存占用率高时需预付

如果用户无需预付，则提交后直接进入系统派单流程；如果需要预付则调起收银台进行付款。付款过程中会占用库存（因为指定了服务人员和服务时间），所以需要限制付款时间，一旦超时未完成付款，则系统自动取消订单。用户完成预付后同样进入派单流程。

另外需要注意，如果用户在一笔订单中同时使用多种支付方式，处理逻辑需要进行设计以避免优惠和运营规则出现冲突或者崩溃。

比如：

如果允许用户同时使用会员卡和优惠券，那么是所有优惠券都可以和会员卡同时使用，还是仅限部分类型的券；

出于更好的用户体验，系统自动帮助用户绑定一张券，那么优先绑定什么券（大额优先还是近期失效的优先？折扣券优先还是代金券优先？等等）。

三、商家端推送账单、保单、结算流程

商家到达制定地点、做好服务准备后，需要在商家端确认 " 开始服务 "，此后商家和用户都无法在 APP 上取消订单。

等到商家完成服务，根据实际情况对服务时长（以及是否使用其自带的工具材料）进行调整，然后发给用户确认，用户确认无误后最终完成付款。基于这样的业务流程，需要将订单结算拆分为推送账单和报单两个部分。

推送账单：是指商家按照实际服务情况填写好消耗的时长和物料，并将服务明细推送给用户。好比是去饭店吃法，在付款前饭店先给一个已上菜名称、价格的列表和汇总金额。如果账单有误，用户看完后可以要求商家调整。因此，推送账单的页面存在两种情况（首次推送前的形态，及推送过后返回来修改的形态）。

报单：是指商家将账单提交给系统，并依据此账单完成结算。

在商家收款过程中，流程设计人员要明确的是：

会员卡、现金、其他线上支付方式在什么情况下可以选用？下面举例的流程中，只有当用户是会员并且会员卡余额充足时才可以使用。当然，从运营的角度，在培训时得向商家强调必须事先与用户确认，才能操作收款；从产品角度，商家完成收款之前在界面上也应该进行提示。

用户是否在商家收款前就完成了线上支付，也就是预付？如果没有预付，则需要用户现金支付或者在用户端进行线上支付。

用户已在线上预付的金额比实际金额多或少该如何处理？一般是多退少补。预付过少时需要再次支付；预付过多时需要考虑扣款的优先级，一般是代金券>会员余额>第三方支付，多余的部分原路退回。

商家正常完成收款时，在商家端如何给予引导？可以参考下面流程图中的情形。

在异常情况下，这笔订单已经完成最终结算了，此时商家继续操作报单、收款应该如何处理？一般而言，需要在前端进行报错提示，可参考流程图中的情形。

四、用户完成支付流程

商家推送账单后，如果仍然有部分金额或者全额需要支付，则用户可以支付现金、使用会员卡余额支付（如果有卡且余额足够），或者是通过第三方支付进行结算。前两个选项都无需用户在 APP 端操作，第三类则需要。

而在后端请求支付接口前必须先校验账单 / 订单的状态，如果订单已经完成支付或者是已取消，则支付流程中断。这些都是基本常见的考量，不赘述。

五、关于订单被取消的处理

一个订单可能因为各种原因被取消，具体包括但不限于下面表格中列出的情况。其中，1 类的情形过失方为用户；2 类情形的过失方为商家；3 类情形过失方为平台。

如果是商家或者平台的过失，则用户不应当承受不利后果。所以对于已预付的订单被取消，则应该对用户进行原路退款、全额退款。

在一些情况下，甚至还应当给用户发券进行补偿。举例：

长期忠实高价值用户因订单取消而发起投诉；

无可派商家，或者是系统多次派单都无法满足用户的需求；

临近服务时间，临时取消订单，给用户带来不便；

优惠券 / 代金券因过期而无法原样退回。

因商家自身原因取消订单，应记录到商家的考核评价体系中。多次取消订单的商家，可以减少派单甚至不派单，也可以根据业务情况进行罚款、扣押金、增加培训、解约等。

如果是因用户的过失而导致取消订单，则会存在全额罚款、部分罚款和全额退款三种处理方式。

未预付的订单：平台无法对用户进行罚款，这种情况下商家时间和收入上的损失由平台进行补偿。但是平台会记录用户的失信行为，用户后期再次使用平台服务就需要预付了。

预付订单：根据用户取消订单的时机来决定应当采取哪种处理方式。举例，距离服务时间 T

对于出现的退款，需要对退款的路径、各种退款方式的优先级、退款中卡券的处理做出相应的规则。

退款路径：原路退回，用户使用什么方式付款，退款时就回到相应的账户中。

退款方式优先级举例：第三方支付>会员卡>代金券 / 优惠券。这样设定，是因为第三方支付无特权，其余两种有特权，既然用户失信则应对特权进行限制；会员卡是用户通过充值获得的，而代金券 / 优惠券是平台运营给予的，用户获取后者的成本远低于前者，所以会员卡的优先级比券高。当然，为了避免用户做出错误决定并导致其投诉，需要在用户使用前就提示这种业务场景。

卡券异常情况处理：卡券如果按照原样返回会过期的情况，根据业务确定是否延期；2. 因为卡券的存在，按照比例规则计算时可能会出现退款金额>在线支付金额的情况，此时应该加一条兜底规则，避免过多的退款。

六、关于售后

如果商家服务完离开后用户发现质量问题并向平台投诉，则在一些情况下平台运营会介入并了解情况，确认问题存在后会先行用代金券赔付给用户，而后再对商家进行惩罚。该流程是整个服务的一部分，但是不涉及预付，此处一笔带过。

本文由 @霹雳 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务