，在整个体系实现进程中，需要考虑商品相关和同步机制、订单同步机制、付出流程、履约服务

非体系对接的计划一般较为粗暴，便是人工导入订单，导入的商品信息就包括skuID、sku称号，注意，这儿skuID就和本地skuID保持一致即可。

2. 买卖订单

订单同步机制：

1）站外体系对接途径

其实关于订单数据来说，经过网关拉取（或同步）到上游的订单数据。

然后网关调用买卖的下单接口下一笔站内0元订单，仅仅订单存储的时分会将网关获取到的部分重要信息进行存储，如订单状况、外部付出金额、用户信息等。

2）站外非体系对接途径

由于不涉及体系对接，所以也不存在订单拉取的流程，能够以为人工导入订单的进程其实就手动调用下单接口在内部下了一笔订单。

3. 付出

关于付出来说，订单其实调用付出下了一笔站内0元付出单。由于用户现已在外部途径付出完成了，所以不需要在内部重复付出

4. 履约

其实不管是站外途径单还是站内单，关于履约服务来说，他只关心【给谁】以及【履约啥】。

1）站外体系对接途径

【履约啥】也便是履约哪个sku，这个要素其实上面商品同步的时分现已能够定位到了，根据外部sku的信息找到对应的本地skuID；【给谁】这个就比较麻烦了，由于关于站外途径而言，站外的买卖是一套完好的流程；站内和站外途径的账号体系完全是两套毫无相关的。

一般这类问题的解决办法是会在用户在站外途径下单的时分，填入手机号信息，该手机号作为登录APP的账号以此做相关。关于实物订单，则能够经过网关拉取到的用户信息进行履约。

2）站外非体系对接途径

其实在人工导单的时分 人和商品的信息就现已提供这些信息，并不阻塞履约。

5. 售后

售后主要是分为钱和物权，也便是用户付出的钱以及商家为用户履约的物权。

• 关于钱的售后，全都找途径，原因很简单，钱是途径收的；
• 关于物权的售后，全都找商家，原因也很简单，商品是商家履约的。

其实售后最重要的一点是，关于站外体系对接的订单，在外部退款时，要确保订单状况是同步的，不然就会出现用户白嫖的场景，既退了款，又白嫖了商品；关于站外非体系对接途径时，在给用户退款时，也要记得内部体系收回物权。

四、个人考虑

跟着站内流量逐步遇到瓶颈，使用站外引流获客已成为不少商家尝试的事务形式。上述设计思路的场景能够覆盖各种类型的商品，由于不管是什么类型，买卖实质都是一样的。

此外，在整个体系实现进程中，需要考虑商品相关和同步机制、订单同步机制、付出流程、履约服务以及售后处理等方面的问题。当然文章中说到的一些计划模型并不是一个标准，其实各厂实现的计划不尽相同，最重要的是根据事务需求和具体情况来选择合适的计划，没有标准答案，只需能为事务赋能解决问题，便是好计划。