本篇文章会讲讲支付的一些相关的名词概念以及怎么去设计支付系统，通过理解支付的这些名词概念和支付系统的架构，为接下来写支付系统的代码做好准备。
目录
支付------支付资质
支付------支付场景
微信
付款码支付
Native支付
支付宝
条码付
扫码付
电脑网站支付
支付------名词解释
appid
openid
支付------同步和异步
支付---系统架构
支付------支付资质
支付资质就是可以收钱那个人，就是企业，那我自己做项目怎么办呢？我是自己有appid和秘钥的，相当于我就是企业
支付------支付场景
微信
付款码支付
就是让收银员来扫你的那种
Native支付
就是用户扫商家
其他几种支付我听不懂，暂时先放一放
支付宝
条码付
商家扫你
扫码付
你扫商家
电脑网站支付
就是你交学费，电脑出现一个二维码，你用支付宝扫一扫，然后支付，这个就是电脑网站支付
支付------名词解释
appid
这里的app是application的缩写，即“应用”的id。小程序也好，移动应用也好，网页应用也好，都属于应用，每个应用都有它的appid。一个应用和支付产品是什么关系呢？支付产品就是当面付，电脑网站支付，小程序支付，这些支付方式都叫支付产品。记住一句话：一个应用有多个支付产品。
openid
是微信独有的，是微信用户在公众号appid下的唯一用户标识（appid不同，则获取到的openid就不同），可用于永久标记一个用户。只有公众号支付和小程序支付需要传递这个参数。
支付------同步和异步
异步
支付结果以异步为准
支付---系统架构
那我们构思一下怎么去设计这个支付系统。我们是想让这个支付系统是独立的，也就是说不要把支付的代码写到之前的项目里去。为什么要这么做呢？我等会儿说，等我把我想说的说完。既然我们想把支付系统定位为一个独立的系统，那么这个独立的支付系统就要有自己专用的数据库/表，这个数据库/表只有支付系统可以使用，其他的Java应用不能连这个数据库。由于我这个项目中，关于支付只有一张表，再单独开一个数据库来专门存这张表，感觉有点搞笑，因此我就把这张关于支付系统的表和其他的表放在一起，也就是放在同一个数据库中，但这张表是我们专用的。往后支付系统的功能多了，什么账单，对账功能。你就可以搞个专用数据库。
回到刚刚的问题，为什么要单独搞一个独立的支付系统呢？一般正常人的想法是这样的：
你有没有想过，假如我像上面那样去设计这个支付系统，会有什么问题？
其实也没什么问题！但是当业务多了之后，就会变成这样：
那这个时候，仓库系统和活动系统都需要支付，那怎么办？拷贝代码呗！就像这样：
好了，现在假如你需要完成微信支付，要用到微信平台给我们的id和密钥，那这个时候你就要在这3个系统都配上密钥，这已经是比较麻烦的了，但是还有更麻烦的：假如你要修改密钥，那就废了！3个系统都要改，最后发现这个系统越来越差，越来越不可维护，那这个项目就废了！
所以我们要这样规划：
支付作为一个单独的系统，左边是我们的业务系统，右边是微信和支付宝，由支付系统完成微信和支付宝的对接。我们左边的业务系统不跟微信和支付宝打交道，微信支付宝密钥在支付系统里面，只有这一个地方需要配置。那业务系统和支付系统怎么交互呢？交互其实算比较简单，就两步：第一步发起支付，第二步支付成功，异步通知。发起支付这个步骤很简单，我们直接让他跳转到支付系统（这里跳转到支付系统不是说跳转到支付首页，而是跳转到支付接口。让他携带参数跳转过去，比如订单号，支付金额，支付方式微信支付宝这些参数），支付后，微信和支付宝会有一个异步通知，支付系统拿到这个异步通知，再去通知业务系统，我们这个项目用MQ来做异步通知。
