书接上文，在开始准备的时间里，想的太多。

比如团购、外卖、点评、电影票、单车、住宿、甚至包括海淘等等。把自己思路带乱了。

然后想到，其实我只是用支付平台举例就好了，

并不是开始就把美团各个业务线按统一规则进行整合。

上文链接：账户体系——美团面试带来的思考

01

—

假定背景

所以这个背景的要求就很简单，对美团收购的支付牌照进行产品梳理和调整，要符合以下要求：

1尽量快的交付时间

2可以满足美团外卖的基本需要

3完成支付平台所需的基本能力

02

—

补充相应条件

基于以上条件，原有与其他支付平台的合作模式也能够满足。所以还要考虑到美团外卖自身的一些特性。出于交付时间的要求，适量考虑美团其他业务线的适配模式。（全面的考虑需要增加复杂度及时间，将通过单独章节进行描述）

通过美团外卖的网页，和个人过往的订单等信息，梳理到的条件如下

1美团外卖的商户ID为18位；（美团团购商户ID为9位）

2美团外卖的订单ID为17位。

3美团外卖中，买家可使用红包和代金券；红包和代金券有多个种类，使用条件有差异；第一阶段可简化为：红包—美团外卖补贴，代金券—商家促销；

4配送费，由美团或自有配送的商家制定

5解决二清

最后这个没有看错，美团之前一直在二清，即使有了收购了具备支付牌照的钱袋宝之后，迄今为止，依然在二清。

个人曾经用招行信用卡完成过美团外卖的订单，在招行的对账信息里，收款方是美团点评（商城）（云闪付），并不是实际交易的**餐厅。

为了再次验证，3月25日又定了一次美团外卖，交易商户为支付宝-北京三快在线科技有限公司。

注意，美团收购的支付牌照为北京钱袋宝支付技术有限公司，三快在线无论是否通过钱袋宝将资金付给**餐厅，都是明显的二清行为。

如果美团外卖直接调用微信或支付宝，并且完全撇清二清嫌疑，需要外卖商家在微信和支付宝开立收款账户，并与美团外卖中用户ID进行关联；而且，实际资金进入了卖家在微信和支付宝的账户中，并未进入美团支付的卖家账户，所以美团支付提供给卖家的平台（通常称作云中台或商户后台），缺少此笔资金的入账。

上面两个问题，都是美团无法接受的。可以挨罚，但是不能失去市场。这也是美团一直进行着二清的重要原因。也算是美团收购支付牌照的必要性吧。

解决方案其实很简单，只是没想到美团在这方面的动作很慢。不知道是否存在市场反馈等其他方面的压力延缓了这件事。

03

—

过往经验适配

根据过往经验，先以最简模式适配到上述的场景中（简化模式下，此支付平台可为美团外卖提供单纯的交易支付渠道功能）。

账号长度：共25位

内部账号按会计科目划分：

4+4+4+4+4+4+1

用户账号按会计科目划分：

4+18+3

主要规则账号：

应收账款为：1133****1；

应付账款为：2202****1；

手续费收入为：6001****1；

用户账户为：2001****001（中间18位为用户ID）

主要交易流程：以某烧烤店100元外卖订单为例，采用美团自有配送，无红包及代金券，用工商银行卡完成支付

Dr  1133 0001 **** 1（假定工商银行编号为0001）100；

Cr  2001 123**** 001（假定某烧烤店用户号为123***）100；

若此笔订单使用招商银行卡支付，使用了3元美团红包及10元商家代金券；实际支付金额为87元

Dr   1133 0002 **** 1（假定招商银行编号为0002）87；

Cr    2001 123**** 001（假定某烧烤店用户号为123***）87；

PS：简化模式下，美团外卖APP及网站在需要进行支付时，应已生成订单，即已处理完成订单总金额与实际支付金额关系，支付平台仅完成需支付的金额即可。

特别注意：

需保证实际收款人，避免出现二清。

过往项目中，通常会提供一个Excel表格，配合word及流程图进行说明。包括资产、负债类等科目设置，以及产品线划分等。公众号文章中不适合直接放文档，仅做简要描述。部分内容的理解需要有一部分的账务或会计基础。

04

—

账户体系针对性升级—阶段一

大部分用户常用微信或者支付宝完成付款；

方案一：美团外卖可以直接调用微信或支付宝的支付接口完成付款，不涉及美团支付。

此方案因存在前文提到过的二清等问题，将不再纳入考虑范围。

方案二：通过美团支付，调用微信或支付宝收款接口，支付成功后，完成账务及订单处理。

将支付宝与微信等第三方支付机构，与银行进行同等级别的会计科目设置，如设立微信应收账款：1133 1001 **** 1，支付宝应收账款：1133 1002 **** 1。

完善支付平台上的信息，为后续产品拓展和运营打下基础

在前文提到的记账方式中，并未对个人用户进行记账，即个人用户需要查看交易记录时，仅能通过单独查看各个订单进行统计，对自己参与交易的资金流水进行查询、和导出缺少整体支持。

举例：支付宝在早期通过银行卡购买余额宝的时候，通过详单能够看到，先是一笔向个人账户的充值，然后是一笔个人账户购买余额宝的支出。后续优化了页面查询，将此类充值交易进行了屏蔽，目前应该在账务记录上又进行了优化，推测是对交易类型进行了分类细化，针对性调整记账规则。

因个人未在阿里内部任职，后续也未进行持续的关注，仅通过之前明确的情况，在本文进行参考举例。

原使用工商银行卡完成的交易记账为：

Dr  1133 0001 **** 1（假定工商银行编号为0001）100；

Cr  2001 123**** 001（假定某烧烤店用户号为123***）100；

调整为：

Dr  1133 0001 **** 1100；

Cr  2001 999**** 001100；个人用户号为999****

Dr  2001 999**** 001100；

Cr  2001 123**** 001100；

考虑到用户ID为18位，通过前面三位固定999（建议设计为0开头，只是999更便于通过文字引导思路），足够满足个人类用户的开立数量。

如果后续提供个人交易流水的查询或者导出，尽量在输出内容上做一些优化，避免账号的直接输出，毕竟用户关注的是资金信息。对于非重点的账号等数字信息易造成用户的注意力分散。

另外在面对极高并发量的时候，此会计分录可进行性能优化，后面会详述。

05

—

账户体系针对性升级—阶段二

阶段2.1

美团支付，不只是外卖业务对接的支付平台，同样需要为团购、单车、住宿等业务提供支持。

阶段2.2

不仅提供支付通道能力，作为整个美团的一项账务能力基础。比如红包补贴、配送费（补贴）、小贷（白条）等涉及资金的业务整合在支付中。

阶段2.3

是否可为其他平台提供支付能力。

阶段2.4

在极高并发量前提下，考虑分布式账务设计

敬请期待。

只希望能将一些产品设计的想法与各位分享，减少一些因产品设计不合适带来的996。

——————琐碎的说了些个人想法。

文不对题，感谢读完。

得者自得，唾者轻言。

...