一文搞懂“交易核心”：交易、订单、账单、支付

职场 2025-01-16 09:43 天津

全文共8667个字，本文底部有入门、架构、支付、清结算、账务等全链路支付文章推荐，按顺序看即可系统性提升

交易是支付的前提，对整个支付业务流程起着至关重要的作用。本文将重点阐述交易层中的交易系统与订单系统，单独探讨交易的逆向处理流程，并辨析交易系统与支付系统之间的区别。

1.交易系统

交易系统是交易过程中推动整个交易流程进行的信息化系统。交易流程始于用户挑选商品，终于用户完成订单并满意离开。这一流程涵盖了商品导购、下单签约、营销计价以及履约等多个环节。

1.1.交易模型分析

为了更直观地理解交易模型，本小节将以家政O2O场景为例，深入剖析交易的业务架构、交易环节的抽象以及交易模式等关键问题。所采用的分析方法具有通用性，同样适用于电商、出行、团购平台、OTA等众多其他业务场景。交易的业务架构如图1所示。

图1 交易业务框架

其中，交易流程是指交易各个环节按照既定顺序进行的有序编排，即明确本次交易中各项操作的先后顺序；交易核心处理层是交易系统的核心引擎，负责处理各类交易事务，如创建订单、核销优惠券等；业务系统则是整个交易过程中所依赖的其他系统，如订单系统、合同系统、计价系统等，它们为交易提供必要的支持。

可以将平台交易过程进行抽象，形成不同的交易环节，如图2所示。

图2 交易环节抽象

交易环节并非固定不变，而是随交易模式的变化而调整。因为平台通常涵盖多种业务类型，如不同的业务线、城市以及经营模式，从而催生了多样化的交易模式，例如月嫂自营模式、月嫂经纪模式、保洁平台模式、保洁自营模式以及保姆交易模式等。此外，交易环节还受其他多种因素影响，如产品是单卖还是打包售卖、业务是经纪业务还是对公业务、订单是内部生成还是来自外部渠道等，这些因素都会使交易环节的构成和顺序发生相应变化。这里，我们从业务线、售卖模式、经营模式和订单来源四个维度来界定不同的交易模式，如图3所示。

图3 交易模式抽象模式

由于业务类型的差异，必然会导致某些交易环节的不同。例如，月嫂实行线上预约、线下面试、线上签单、线上支付的流程；而保洁交易则可以在线上直接完成下单和支付等全环节，实现了交易的全线上化。这样一来，不同的交易模式就形成了各自独特的交易环节组合。基于这个思路，我们可以完成对整个交易模型的抽象概括。比如，保洁普通交易模式的流程安排就如图4所示。

图4 保洁普通交易模式和交易流程

1.2.架构及上下游关系

交易系统由交易服务、交易模式、交易计价、履约确认、订单创建服务、账单模块、卡券处理、支付处理等多个模块构成。其中，交易计价、订单创建、卡券处理以及支付处理等模块均需调用外部系统来完成其功能。这些模块协同工作，最终形成了以交易核心为中心的系统协同交易网络，其协同关系如图5所示。

图5 交易系统架构以及与上下游系统关系

可以从以下几个方面来理解和把握交易核心：

多层次组成：交易系统由交易流程、交易核心、业务系统三个层次构成，各层次相互协作，共同支撑整个交易过程。
流程性特点：交易流程是交易各个环节按照既定顺序进行的有序编排，明确了本次交易中各项操作的先后顺序。
外部系统依赖性：交易核心作为各类交易处理的引擎，其处理服务依赖于外部相应系统的支持和配合。
多模式并存：由于业务类型、流程安排和处理方式的不同，交易核心存在多种交易模式，这是交易核心拓展和灵活应对不同业务需求的关键空间。

1.3.交易账单

账单是连接订单业务和支付处理业务的过渡单据，也是支付处理的核心枢纽。交易过程中的支付、付款、退款等操作都是基于账单来进行的。一个订单可以创建多条账单，例如，一个订单分两次支付，则会创建两条账单。同时，一条账单也可以进行组合支付，如结合三方支付、卡券以及活动优惠等多种支付方式。在进行支付处理时，系统会针对不同支付方式分别请求相应的系统来完成支付流程。最后，基于各渠道的支付结果进行后续处理，如图6所示。

图6 订单与账单的关系

上面提到，一个平台会存在多种交易模式，而不同的交易模式下又会有不同的订单模式。对于这些不同的模式，我们需要设定不同类型的账单类型。比如，面向消费者（ToC）的账单和面向商家（ToB）的账单会有所区别，用户下单时的账单与商家缴纳保证金时的账单也会不同。这是因为不同类型的账单中，所包含的费用项、账单金额的计算方式以及账单的周期等都可能存在差异。例如，在保洁业务中，可能有预付账单和后付账单；在月嫂业务中，则有定金账单和尾款账单；在保证金业务中，会有保证金充值账单；而在卡券售卖业务中，则会有卡券售卖账单。因此，设计好一个账单子系统是构建完善交易系统的重要一环。账单模块的具体功能如图7所示。

图7 账单模块组成

1.4.正向交易流程

正向的交易流程通常是这样的：用户选好商品后，将其加入购物车，接着填写订单信息，然后进行支付，之后等待服务履约，最后完成交易。整个交易流程如图8所示。

图8正向交易业务流程

用户将选好的商品加入购物车后，前往结算页面填写订单信息。提交订单后，系统生成订单并创建账单。交易核心系统随后请求支付核心系统获取收银台链接，并将该链接返回给用户端。用户完成支付后，交易核心系统处理各种支付方式的支付结果，并通知订单支付成功。最后，交易核心系统基于支付结果通知清结算系统进行相关计费和记账。

以1.1节中提到的家政保洁交易为例，整个交易业务流程的详细交互逻辑和细节如图9所示。图中，最上层展示的是用户交易路径，中间层则是各个交易处理环节，而最底层则反映了交易状态。

图9 交易逻辑流程范例

1.5.三大交易处理

交易核心依据账单支付记录，向各个系统发起处理请求，包括外部渠道的支付请求、内部优惠券的核销处理以及积分的扣减等一系列支付相关操作。本小节将详细阐述支付处理、优惠券处理以及卡处理的过程。

1.5.1外部渠道的支付处理

交易核心中账单支付记录对应的“余额支付”和“渠道支付”类型，需通过支付核心系统来完成。具体流程如图10所示。

图10 交易的支付处理过程

购物线向交易核心发起创建订单的请求；交易核心随后进行订单、账单以及账单支付记录的创建。对于基于渠道支付的“应付部分”，交易核心会向支付核心发起请求；支付核心在接收到请求后，会生成相应的支付单据。接着，支付核心会根据交易特征返回收银台参数；交易核心则负责封装这些收银台参数，并将其返回给上游系统。用户在收银台选择支付方式并发起支付；支付核心随后请求支付渠道完成支付处理，并将支付结果通知上游系统。最后，交易核心会完成账单和订单的更新，并补充渠道名称、渠道流水号等相关信息。

1.5.2优惠券的处理

如果订单使用了优惠券，那么交易核心需要与券系统进行两次交互。首先进行“用券冻结”操作，以防止优惠券被多次或跨订单使用；其次，在支付成功后，进行“核销”操作，即当支付渠道确认支付成功后，通知券系统将优惠券状态置为已使用。若支付处理失败，则执行“券解冻”操作，恢复优惠券的可用状态。当然，有些平台可能会选择直接作废未成功支付的优惠券。交易的券处理流程如图11所示。

图11 交易的券处理过程

1.5.3卡、积分等余额类处理

卡和积分作为余额类的内部支付方式，在处理时实际上是对用户余额的操作。这种操作可以采用两次处理或一次处理两种模式。两次处理模式即“先冻结再扣除”，而一次处理模式则是“直接扣除，失败则返还，成功不做额外处理”。如果支付失败，在两次处理模式下会进行“解冻余额”的操作。一般来说，卡和积分作为用户的资产，不会因支付失败而作废。具体处理流程如图12所示。

图12 交易的卡处理过程

2.订单系统

本小节将通过分析电商平台的电商订单模型和支付公司的纯支付订单，来深入解析订单系统的设计。内容将涵盖订单模型的特点、订单的拆分方式、订单的正向与逆向处理流程，以及订单在业务链中的上下游关系等方面。

2.1.电商订单模型

电商类订单因其模型复杂、种类繁多，是最具代表性的订单类型之一。在订单处理过程中，若发生退换货，则会触发订单的逆向流程。此外，在订单的中间环节，也可能因用户取消订单而导致订单终止，例如用户提交订单后长时间未进行付款，导致订单因超时未支付而自动关闭。

2.1.1订单信息

订单需记录多个维度的核心信息。根据业务模式的不同，可能还需补充其他辅助信息。以下主要介绍订单的核心信息内容：

购买者信息：记录谁买了商品；
商家信息：说明商品是从哪里购买的；
商品信息：详述购买了哪些商品；
支付信息：记录支付方式和支付状态；
对账信息：确认支付是否真实完成；
物流信息：追踪商品是否已发货及物流状态；
服务信息：记录是否提供了上门安装等服务；
售后信息：反映客户是否有投诉及处理情况；
退换货信息：处理商品破损或需更换的情况；
订单日志：记录订单的整个处理流程；

这些信息并非存储在同一张数据表中，也不是简单的一对一关系。各类信息可能分散在多个数据表中，这些数据表之间存在着复杂的关联关系，具体如图13所示。

图13 订单信息关系

2.1.2拆分和父子单

当用户选择了多个商家的商品时，订单会被拆分成多个对应商家的子订单。首次支付时，通常是对总订单进行支付；若因故中断，后续支付则针对每个店铺的子订单进行。此时，订单列表中会显示多个待支付的子订单，这是按照店铺维度进行的订单拆分。当然，也可以根据业务需求或其他模型对订单进行拆分。影响订单拆分的主要因素包括：

不同商家：需单独结算，商家各自发货；
不同发货仓库：如北京仓库、天津仓库等；
品类包装要求：易碎品需特殊包装，大件与小件分开包装；
物流因素：物流公司对包裹的体积和重量有特定要求；
商品限价：如海购商品，海关有限价规定等。

这些拆单环节的具体流程如图14所示。

图14 订单拆分环节

订单拆分后，会形成父子订单的数据结构。以宇宙购买了2个商家的ABC三个商品为例，总价100元，平台优惠20元。其中，A商品属于店铺1，B商品属于店铺2。拆分后的父子订单关系如表1所示。

表1 父子订单数据关系

2.1.3优惠分摊

在某些情况下，一个订单会包含来自多个店铺的多个商品，结算时还可能涉及多个优惠活动，如满减、优惠券、折扣等。当这些优惠活动跨店铺应用时，比如平台的“满100减20”活动，就需要明确每个商家或商品具体享受了多少优惠。一旦用户发起部分商品退款，如何计算退款金额？如何与商家结算？财务又该如何记账？

为了解决这些问题，我们需要制定一套优惠分摊策略。将优惠分摊到具体商品上是一个较为合适且公平的方法，因为这样便于订单逆向处理及优惠处理。如表6-5所示，优惠是按照商品价格在订单商品总价中的比例进行分摊的。因此，子单1的分摊优惠金额为：

子单1的优惠分摊金额 = （总优惠20元） × （子单1商品金额20元） / （订单商品总价100元） = 4元。

2.1.4订单状态

订单状态用于记录订单的处理进程。根据具体业务和订单模型，我们会设计订单的状态及其变化逻辑。常见的订单状态包括：待付款、待发货、待收货、订单成功、订单关闭和退款中等。这些状态的流转关系如图15所示。

图15 订单状态流转

2.2.支付订单模型

三方支付机构的支付业务涵盖收款、付款、退款等种类，这些业务同样会生成订单，用于记录支付业务的相关信息。然而，与电商业务相比，支付业务的订单存在一些差异。例如，支付业务订单不涉及实体商品，因此不需要发货和收货流程，自然也就没有物流相关的内容。当我们从电商业务的订单关系中剥离出业务订单部分后，剩余的部分就构成了支付业务订单的关系，如图16所示。

图16 支付订单单据之间的关系

根据支付机构的业务特性，我们将订单按交易类型进行了细致分类，具体包括收款订单、退款订单、清算订单、打款订单、营销订单以及其他订单等，这使得订单的范畴更加广泛和全面。其中，收款订单是指由商户平台提交的支付请求订单，其业务流程如图17所示。

图17 收款订单处理流程

一个支付机构通常会提供多种支付产品，并且可能拥有多个处理系统。因此，不同类型的订单在流转过程中会需要请求不同的系统进行处理。订单路由就是根据订单的类型和基本信息，选择相应的订单系统进行交互处理，比如决定请求哪个交易系统或结算系统。交易订单作为总订单，会根据账户和营销等因素被拆分成多个子订单，具体拆分示例如表2所示。

表2支付订单数据关系

除了之前提到的订单类型，还有其他如退款订单、分账订单等，这些订单类型在处理上大同小异。一个优秀的订单系统，不仅需要高效处理自身的订单业务，还应向上下游提供优质的订单服务。常见的订单服务包括：

不同订单类型的创建服务；
不同订单类型的状态变更通知服务；
其他如补单、结算、订单分账等增值服务。

在深入理解了业务模型，并设计好订单模型及订单系统的核心功能后，设计订单的展示层和运营操作层的后台就变得相对容易了。我们只需明确需要为运营提供哪些功能支持，以及需要展示哪些订单信息，然后基于实际业务需求进行设计即可。订单后台常见的功能点包括：

订单管理：提供订单列表作为基本工具，支持通过不同条件查询各类订单；
信息展示：全面展示订单的基本信息、商品信息、状态信息、支付信息等；
系统关联：方便关联到支付系统查看支付详情，或关联到用户中心查看用户相关信息。

3.逆向交易

有正向交易就必然会有逆向交易，有下单就会有退单，有支付就会有退款，有发放就会有撤回，有发货就会有退货。因此，逆向交易是一个全局性的问题，而非仅仅是一个单点问题。在不同的场景下，逆向交易会触发不同长度的处理链条。

3.1.逆向的处理方式

先来看个小例子。一个订单支付了100元，其中平台先分了10元（剩下的90元待分给商家）。此时发生了40元的退款，可以选择以下两种逆向处理方式：

方式一：按比例逆向退款。也就是平台的佣金按正向分账的比例逆向退回一部分。具体来说，平台分账退回4元，待分账给商家的90元中，逆向退回36元。

方式二：平台佣金不动，从待分账给商家的待结算金额里全额逆向退回40元。

实际上，这两种方式在业务中都有应用。大部分电商、家政等电商类业务都采用按比例逆向退款的方式。而第二种处理方式则更多出现在交易中包含某些特定费用的情况下。

举个例子，如果签订了“佣金不退”的协议，那么逆向退款时就不会退佣金。比如租房子的场景中，租户支付了9000元，其中包括3000元中介费、3000元押金和3000元房租。如果租户住了半个月后不住了，由于这三个费用的性质不同，逆向处理时就不会按比例退钱。而是基于租房场景的特殊规定，中介费和押金不退，房租退一半。

再比如家政业务中，也有不按比例逆向退款的场景。请了一个月嫂，支付的费用包括“客户信息服务费+阿姨工资+阿姨信息服务费”。其中的客户信息服务费就跟租房子的中介费类似，一般上户满一定天数后就不会再退回了。

因此，选择哪种逆向处理方式，要看公司的具体业务要求。

3.2.逆向场景及处理

不同类型的逆向业务需要处理哪些环节，又该如何处理呢？常见的逆向类型包括订单逆向、交易逆向、物流逆向、支付逆向和计价逆向等，它们的处理方式如下：

订单逆向，即“退单”，此时订单状态会变为逆向状态。物流逆向，即“退货”，会产生退货单或逆向物流单。支付逆向，即“退款”，会产生退款单，基于正向支付单向支付渠道发起退款申请。计价逆向，即“逆向计价”，在计价环节需要计算应退还给用户的金额，以及其他相关的逆向计算。

交易逆向，即“逆向交易”，是逆向处理中最复杂的一种。特别是部分退款时，交易层需要决定逆向处理的顺序，如“渠道支付金额、卡支付金额、券支付金额、积分兑换金额、折扣金额”等支付手段的退款顺序。根据不同的策略和业务需求，我们会选择不同的退款顺序。例如，如果优先退虚拟资产，则顺序为“积分>券>卡>渠道支付”；如果先退钱，则渠道支付先退，用户会收到退款。

卡逆向，即“卡余额退回”，交易处理退卡时，卡余额会退回到卡里，并在卡账户里生成一笔卡余额退回的流水。

券、积分等虚拟资产的逆向处理取决于“退不退”的政策。在很多平台上，券和积分一旦消耗就不退回。因此，当用户发起订单退款时，这部分资产通常不会退回。具体处理方式需根据平台制度而定，但至少平台不再承担这部分成本，并在财务层面冲销积分和券的成本。

清结算逆向，即“逆向计费和记账”。当交易或订单通知清结算环节进行逆向处理时，清结算系统需要决定如何处理分账的逆向计费和记账。这涉及最初的问题：佣金退不退？怎么退？部分退款的金额如何分配到各个费用上进行逆向撤回？是按比例还是按顺序？最终选择需根据公司运营方案或法务、税务、财务等更多制度约束进行。

分账逆向，即“撤回资金”。清结算逆向完成后，需要请求已分账资金的逆向记账和资金撤回，这只需发起逆向指令即可。

财务逆向，即“逆向凭证”。正向时财务已记账，逆向时也需要记录逆向凭证。例如，正向时消耗了平台优惠券并借记销售成本，逆向时退回了券并贷记销售成本，这样一进一出销售成本就被冲销了。

4.交易和支付

我们先来看一个问题：支付系统和交易系统在功能上有什么差别？有人可能会觉得，交易系统能做的事，支付系统似乎也能做！

那么，我们深入思考一下：既然支付系统似乎无所不能，为什么它不包办一切呢？这要从系统的发展史说起。在企业的发展过程中，出现了“职能细化，子系统独立拆分”的现象。就像盘古开天辟地一样，系统建设也从最初的混沌状态，逐渐衍生出一个复杂的系统生态。

4.1.系统集成阶段

当公司刚成立且规模较小时，只需要一个“交易系统”就能满足在线交易的需求。因为业务体量小，公司资金有限，人手也不足，所以没有必要构建复杂的产品体系。即便只是这一个“交易系统”，它也完整地包含了收银台、订单管理、卡券管理、计费结算、支付处理、渠道管理以及财务等功能模块，其职能清晰明确。

无论公司后来发展到拥有多少个系统，系统规模有多大，其主体业务大体都是相同的：用户需要选购商品、下单、支付，商家则需要进行结算。因此，此时期交易系统应该具备如图18所示的能力。

图18 早期的交易系统

因此，在了解系统之前，我们首先要弄清楚企业的各种职能，比如什么是交易、什么是订单、什么是支付。这些职能不仅可以通过系统来实现，线下面对面同样可以完成，比如支付，线下直接给现金并开具收据即可。所以，我们要先把这些“事情”搞清楚、弄明白。

4.2.子系统分化

随着公司的发展和业务体量的增加，原来的交易系统变得越来越笨重，调整起来也越来越困难，逐渐成为了平台的瓶颈。此时，公司已经有了更充足的资金，开始重新细化和打包各项职能，对旧交易系统中的收银台服务、订单服务、清结算服务、支付处理服务、卡券营销服务以及渠道管理模块进行重新定义和规划。

为了更精准、高效地管理这些服务，公司逐渐将这些模块独立出来，形成新的独立系统，并交由单独的团队和产品经理负责。因此，独立系统收银台系统、订单系统、清结算系统、卡券系统、支付处理系统以及渠道管理系统应运而生。此时的交易系统与这些衍生出来的新系统形成了如图19所示的关系。

图19 中期交易系统与子系统

随着公司的发展，每个独立出来的系统被分配给不同的产品部门和产品团队，产品经理队伍也逐渐扩招，从最初的几人扩展到20人，甚至200人、2000人。在这个过程中，这些独立系统之间的协同变得至关重要，因为每一次交易都需要所有系统的共同参与。这种协同关系和处理流程，其实就是最原始的那个“交易系统”的核心所在。

虽然各个系统逐渐独立，但一些核心职能仍然保留在交易系统中。例如，订单系统独立出去了，但“创建订单服务”依然留在交易系统里；卡券系统独立出去了，但“核销优惠券服务”还是由交易系统负责。这种保留核心职能的模式随着企业的发展而不断重复。

随着企业规模的进一步扩大，业务体量达到了初期的上百万倍，更多的职能开始产生，更多的子系统开始独立出来，更多的人被招募进来。收银台系统分化出了前台、后台、H5收银台、App收银台、收银台中台、收银台策略平台；清结算系统分化出了计费系统、清分系统、规则子系统、结算系统、账户系统；支付系统分化出了收款系统、付款系统、调拨系统、支付风控系统、支付策略系统；渠道管理系统也开始分化出路由系统。这使得整个交易体系变得更加复杂，如图20所示。

图20 更复杂的交易体系

因此，我们不能静态地理解“谁能做什么、谁做什么、做成什么样”，而应该从历史发展、演变、分工和选择的角度去深入理解当前的职能和系统。当前的系统现状，是企业在发展过程中，基于其自身特色和个性化选择逐渐形成的系统体系。

首先，我们要理解企业的职能——即企业要干什么；然后，再去理解这些职能由谁来执行，如何执行，以及为什么要这样执行。

最后，我们来回答最初的那个问题：交易系统和支付系统在功能上有什么区别？从用户进入平台开始选购商品，到最后支付成功，这一整个过程都属于交易范畴。而交易系统，就是负责统筹管理这个过程的产品。因此，这个过程中的所有业务都可以归属于交易系统，也都有可能从交易系统中独立出去。支付系统，就是其中独立出来的一部分。

具体来说，支付系统主要是处理外部支付渠道的支付业务，即用户实际支付的那部分资金的处理系统，比如通过微信支付、支付宝支付、银行卡支付等。然而，一笔交易可能涉及多种支付方式，如使用卡、券、积分等。这些支付方式的处理并不由支付系统完成，而是由相应的卡系统、券系统、积分系统来承接。而交易系统，则负责连接这些系统，处理它们之间的交互。这种连接职能，就是卡、券、积分等系统从交易系统中独立出去后，留在交易系统中的那一部分职能。