第三十二章 第三方支付平台对接-蚂蚁金服开放平台接入
第1集 常用的第三方支付和聚合支付平台介绍
简介:介绍常用的第三方支付和聚合支付
- 什么是第三方支付
- 第三方支付是指具备一定实力和信誉保障的独立机构,采用与各大银行签约的方式,通过与银行支付结算系统接口对接而促成交易双方进行交易的网络支付模式
- 通俗的例子:
- 支付宝,微信支付,百度钱包,PayPal(主要是欧美国家)
- 拉卡拉(中国最大线下便民金融服务提供商)
- 优点
- 支付平台降低了政府、企业、事业单位直连银行的成本,满足了企业专注发展在线业务的收付要求。
- 使用方便。对支付者而言,他所面对的是友好的界面,不必考虑背后复杂的技术操作过程
- 缺点
- 风险问题,在电子支付流程中,资金都会在第三方支付服务商处滞留即出现所谓的资金沉淀,如缺乏有效的流动性管理,则可能存在资金安全和支付的风险
- 电子支付经营资格的认知、保护和发展问题
- 什么是聚合支付也叫第四方支付
- 聚合支付是相对之前的第三方支付而言的,作为对第三方支付平台服务的拓展,第三方支付是介于银行和商户之间的,而聚合支付是介于第三方支付和商户之间
- 出现的场景
- 一堆第三方支付出现,并通过大量的钱补贴线上商家使用它们的支付,导致商户收银台堆满各种,POS机器,扫码设备,商户还需要去各家支付公司申请账号,结算等
- 聚合支付产品,其实聚合的是一种支付能力(支付宝支付、微信支付、百度钱包、ApplePay……),将这些收款能力聚合在一起,统一打包提供给电商网站或一些线下商家
- 解决的问题
- 聚合支付公司提供的二维码,支付多种方式支付,不再是一种,各个公司的竞争,就是支付渠道和方式的支持
第2集 蚂蚁金服开放平台介绍和支付宝支付应用申请
简介:蚂蚁金服开放平台介绍和支付宝申请
- 蚂蚁金服开放平台
- 地址:https://openhome.alipay.com/docCenter/docCenter.htm
- 介绍:https://opendocs.alipay.com/open/200/105304
- 支付宝扫码登录即可
- 网页移动应用开发指南
- 地址:https://opendocs.alipay.com/open/200
- 申请应用:https://openhome.alipay.com/platform/developerIndex.htm
- 核心是获取APPID
第3集 支付宝沙箱环境介绍和应用权限申请
简介:支付宝沙箱环境介绍和应用权限申请
- 支付宝沙箱环境介绍
蚂蚁沙箱环境 (Beta) 是协助开发者进行接口功能开发及主要功能联调的辅助环境
在开发者应用上线审核前,开发者可以根据自身需求,先在沙箱环境中了解、组合和调试各种开放接口,进行开发调试工作,从而帮助开发者在应用上线审核完成后,能更快速、更顺利的完成线上调试和验收
- 文档地址:https://opendocs.alipay.com/open/200/105311
- 沙箱地址:https://openhome.alipay.com/platform/appDaily.htm?tab=info
- 支付接入:有时不稳定,或者一直报错等等,一般就是支付宝沙箱环境问题
Beta 测试阶段每周日中午 12 点至每周一中午 12 点为维护时间,在此时间内沙箱环境部分功能可能不可用,敬请谅解。
- APPID: 11111
- 沙箱支付宝网关:https://openapi.alipaydev.com/gateway.do
- 买家信息
买家账号11111
登录密码111111
支付密码111111
用户名称沙箱环境
证件类型身份证(IDENTITY_CARD)
证件号码211111
- 商家信息
商家账号11111
商户11111
登录密码111111
第4集 密码学的那些事情-非对称加密和对称加密介绍
简介:介绍密码学-对称加密和非对称加密
- 对称加密
优点:操作比较简单,加密速度快,秘钥简单
缺点:秘钥上面,一旦被窃取,信息会暴露,安全性不高
场景:消息发送方需要加密大量数据时使用
常见的算法:
DES: 全称:Data Encryption Standard,现已被破解
3DES:全称: Triple Data Encryption Algorithm, 暂时未被破解
解释: 3DES 是在 DES 基础算法上的改良,该算法可向下兼容 DES 加密算法,但计算性能不高,暂时还未被破解
AES: 全称:Advanced Encryption Standard,暂未被破解
- 非对称加密
注意:非对称加密具有双向性,即公钥和私钥中的任一个均可用作加密,此时另一个则用作解密
解释:加密与解密的过程不是对称的,不是用的同一个秘钥,一把是公钥,一把是私钥,在加密的时候,用公钥去加密,接收方再用对应的私钥去解密
优点:安全性更高,公钥是公开的,秘钥是自己保存的,不需要将私钥给别人。
缺点:加密和解密花费时间长、速度慢,只适合对少量数据进行加密
场景: 数字签名与验证
常见的算法:RSA,DSA,ECC等,ECC也是比特币底层用的比较多的算法
第5集 应用对接支付宝里面的非对称加密流程梳理
简介:支付宝开里面的非对称加密通讯流程梳理
- 应用对接支付宝加密流程
手机网站支付文档地址:
- https://opendocs.alipay.com/apis/api_1/alipay.trade.wap.pay?scene=API002020081300013628
- 参数介绍
- 流程介绍
项目依赖包添加和样例代码
https://opendocs.alipay.com/open/54/cyz7do
代码语言:javascript复制<!-- https://mvnrepository.com/artifact/com.alipay.sdk/alipay-sdk-java -->
<dependency>
<groupId>com.alipay.sdk</groupId>
<artifactId>alipay-sdk-java</artifactId>
<version>4.10.218.ALL</version>
</dependency>
第6集 支付宝开发助手简介和非对称加密钥生成工具下载
简介:支付宝开发助手简介和秘钥生成工具下载
- 支付宝开发助手简介
- 支付宝开放平台开发助手即密钥生成工具,用于对应用的客户端服务端之间的交互进行加密保护。
- 工具主要功能有生成密钥、签名、验签、格式转换、密钥匹配、智能反馈、开放社区
- https://opendocs.alipay.com/open/291/introduce
- 秘钥生成工具下载
- 代码新建配置类
第7集 手机网站支付宝支付样例代码 单例设计模式应用
简介:手机网站支付宝支付样例代码编写测试
- 编写样例代码
- 测试参数配置使用
//商户订单号,64个字符以内、可包含字母、数字、下划线;需保证在商户端不重复
String no = UUID.randomUUID().toString();
log.info("订单号:{}",no);
content.put("out_trade_no", no);
content.put("product_code", "FAST_INSTANT_TRADE_PAY");
//订单总金额,单位为元,精确到小数点后两位
content.put("total_amount", String.valueOf("111.99"));
//商品标题/交易标题/订单标题/订单关键字等。 注意:不可使用特殊字符,如 /,=,& 等。
content.put("subject", "杯子");
//商品描述,可空
content.put("body", "好的杯子");
// 该笔订单允许的最晚付款时间,逾期将关闭交易。取值范围:1m~15d。m-分钟,h-小时,d-天,1c-当天(1c-当天的情况下,无论交易何时创建,都在0点关闭)。 该参数数值不接受小数点, 如 1.5h,可转换为 90m。
content.put("timeout_express", "5m");
第8集 沙箱环境常见的坑和手机网站支付宝支付样例问题修复
简介:手机网站支付宝支付样例代码问题修改
- Bug修改
- 沙箱环境的坑
- 如果支付页面出现 “支付存在钓鱼风险” ,清空浏览器缓存,只开一个支付宝支付窗口
- 每周日中午12点至每周一中午12点沙箱环境进行维护,期间可能出现不可用
第三十三章 设计模式在多渠道支付里面的设计 编码实战
第1集 软件架构设计-设计模式的六大原则你知道多少
简介:讲解设计模式的六大设计原则
- 设计模式是站在设计原则的基础之上的,软件架构也一样,有必要对这些设计原则先做一下了解
- 软件设计开发原则
- 为了让的代码更好重用性,可读性,可靠性,可维护性
- 诞生出了很多软件设计的原则,这6大设计原则是我们要掌握的
- 将六大原则的英文首字母拼在一起就是SOLID(稳定的),所以也称之为SOLID原则
- 单一职责原则
- 一个类只负责一个功能领域中的相应职责,就一个类而言,应该只有一个引起它变化的原因
- 是实现高内聚、低耦合的指导方针
- 解释:
- 高内聚
- 尽可能类的每个成员方法只完成一件事(最大限度的聚合)
- 模块内部的代码, 相互之间的联系越强,内聚就越高, 模块的独立性就越好
- 低耦合: 减少类内部,一个成员方法调用另一个成员方法, 不要有牵一发动全身
- 高内聚
- 开闭原则
- 对扩展开放,对修改关闭,在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果
- 里氏替换原则LSP
- 任何基类可以出现的地方,子类一定可以出现
- 在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象
- controller->service->dao
- 依赖倒转原则
- 是开闭原则的基础,针对接口编程,依赖于抽象而不依赖于具体
- 高层模块不应该依赖低层模块,二者都应该依赖其抽象
- 接口隔离原则
- 客户端不应该依赖那些它不需要的接口
- 使用多个隔离的接口,比使用单个接口要好,降低类之间的耦合度
- 迪米特法则
- 最少知道原则,一个实体应当尽量少地与其他实体之间发生相互作用,使得系统功能模块相对独立
- 类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及
- 通过引入一个合理的第三者来降低现有对象之间的耦合度
第2集 设计模式最佳实践-第三方支付对接-工厂模式回顾
简介:设计模式知识回顾-工厂模式
- 工厂模式介绍:
- 它提供了一种创建对象的最佳方式,我们在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象
- 工厂模式有 3 种不同的实现方式
- 简单工厂模式:通过传入相关的类型来返回相应的类,这种方式比较单 一 , 可扩展性相对较差;
- 工厂方法模式:通过实现类实现相应的方法来决定相应的返回结果,这种方式的可扩展性比较强;
- 抽象工厂模式:基于上述两种模式的拓展,且支持细化产品
- 例子:
- 需要购买一辆车,不用管车辆如何组装,且可以购买不同类型的比如轿车、SUV、跑车,直接去4s店购买就行(4s店就是工厂)
- 工厂生产电脑,除了A品牌、还可以生产B、C、D品牌电脑
- 业务开发中,支付很常见,里面有统一下单和支付接口,具体的支付实现可以微信、支付宝、银行卡等
- 简单工厂模式
- 又称静态工厂方法, 可以根据参数的不同返回不同类的实例,专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类
- 由于工厂方法是静态方法,可通过类名直接调用,而且只需要传入简单的参数即可
- 优点:
- 将对象的创建和对象本身业务处理分离可以降低系统的耦合度,使得两者修改起来都相对容易。
- 缺点
- 工厂类的职责相对过重,增加新的产品需要修改工厂类的判断逻辑,这一点与开闭原则是相违背
- 即开闭原则(Open Close Principle)对扩展开放,对修改关闭,程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果
- 将会增加系统中类的个数,在一定程度上增加了系统的复杂度和理解难度,不利于系统的扩展和维护,创建简单对象就不用模式
- 项目里面的应用
第3集 设计模式最佳实践-第三方支付对接-策略模式回顾
简介:设计模式知识回顾-策略模式
- 策略模式(Strategy Pattern)
- 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换
- 淘宝天猫双十一,正在搞活动有打折的、有满减的、有返利的等等,这些算法只是一种策略,并且是随时都可能互相替换的, 我们就可以定义一组算法,将每个算法都封装起来,并且使它们之间可以互换
- 应用场景
- 老王计划外出旅游,选择骑自行车、坐汽车、飞机等,每一种旅行方式都是一个策略
- Java AWT中的LayoutManager,即布局管理器
- 如果在一个系统里面有许多类,它们之间的区别仅在于它们的行为,那么可以使用策略模式
- 不希望暴露复杂的、与算法有关的数据结构,那么可以使用策略模式来封装算法
- 对接第三方支付里面,微信支付、支付宝支付等都可以是一种策略
- 角色
- Context上下文:屏蔽高层模块对策略、算法的直接访问,封装可能存在的变化
- Strategy策略角色:抽象策略角色,是对策略、算法家族的抽象,定义每个策略或算法必须具有的方法和属性
- ConcreteStrategy具体策略角色:用于实现抽象策略中的操作,即实现具体的算法
第4集 多渠道支付对接-策略模式 工厂模式编码实战
简介:多渠道支付对接-策略模式 工厂模式编码实战
- PayInfoVO类开发
- 策略接口开发 PayStrategy
- 策略上下文 PayStrategyContext开发
- 具体支付策略开发 AlipayStrategy、WechatPayStrategy
- 简单工厂类开发
第5集 策略设计模式-支付宝支付下单策略编码实战
简介:支付宝支付策略编码实战
- 下单策略编码实战
- 二次支付订单超时设计考虑
第6集 策略设计模式-支付宝订单状态查询编码实战
简介:支付宝订单状态查询策略编码实战
- 订单状态查询策略编码实战
- 接口文档:https://opendocs.alipay.com/apis/api_1/alipay.trade.query
第三十四章 内网穿透工具和支付结果通知回调模块开发
第1集 内网穿透映射工具介绍和使用
简介:内网穿透映射工具介绍和使用
- 什么是内网穿透
支付成功需要配置回调通知应用服务器订单支付成功,需要配置对应的域名
在本地电脑开发,支付宝没法回调,所以需要配置个地址映射,就是外部服务器
可以通过这个地址访问当前开发电脑的地址
- 工具
- ngrock https://ngrok.com/
- 花生壳 https://hsk.oray.com/
- natapp https://natapp.cn/
- 小米球 http://ngrok.ciqiuwl.cn/
- 账号申请
#配置token和子域名
token: A3dc8765c57f4e6e8Ac84276deA889c4
#增加权限
chmod 777 ./*
#启动
./ngrok -log=ngrok.log -config ngrok.conf start httptun httpstun
- 地址配置
- 回调地址:外网可以访问
- http://xdclass.ngrok2.xiaomiqiu.cn/api/callback/order/v1/alipay
- 支付成功配置:外网可以访问
- 回调地址:外网可以访问
第2集 支付宝支付结果通知回调地址配置和接口开发
简介:支付结果通知回调地址配置和接口开发
- 补充支付宝手机支付文档:https://opendocs.alipay.com/open/203/105286
- 支付宝沙箱环境配置支付结果通知回调地址
- 配置文件配置支付结果通知回调地址
- controller接口开发
- 工具转换
/**
* 将request中的参数转换成Map
* @param request
* @return
*/
private static Map<String, String> convertRequestParamsToMap(HttpServletRequest request) {
Map<String, String> paramsMap = new HashMap<>(16);
Set<Map.Entry<String, String[]>> entrySet = request.getParameterMap().entrySet();
for (Map.Entry<String, String[]> entry : entrySet) {
String name = entry.getKey();
String[] values = entry.getValue();
int size = values.length;
if (size == 1) {
paramsMap.put(name, values[0]);
} else {
paramsMap.put(name, "");
}
}
System.out.println(paramsMap);
return paramsMap;
}
第3集 支付宝支付结果通知回调验证签和更新订单状态开发
简介:支付结果通知回调验证签和更新订单状态开发
- 文档:https://opensupport.alipay.com/support/helpcenter/193/201602472200?ant_source=antsupport
- 回调业务逻辑开发
- 更新订单状态
- 如何保证幂等性: 可以不做幂等性处理,本身不影响
第三十五章 订单微服务下单链路完善和支付整合测试
第1集 下单支付链路和超时未支付定时关单功能开发完善
简介:下单支付链路和超时未支付定时关单功能开发完善
- 下单支付功能开发
- 消费者功能完善
- 查询订单状态
第2集 订单微服务下单支付全链路多场景测试准备工作
简介:订单微服务下单支付宝支付全链路多场景测试工作工作
- 下单支付全链路测试-支付-超时未支付
- 登录-加入购物车-使用优惠券-下单-支付
- 登录-加入购物车-使用优惠券-下单-不支付
- 测试准备工作
- 修改多个微服务的死信队列
- 订单5分钟内支付未支付则关单
- 延迟消息6分钟
- 修改了延迟队列的属性,记得先删除下全部交换机和队列
- 检查优惠券记录和商品库存
- 修改多个微服务的死信队列
- 注意:
- bug修改:saveProductOrder方法
- 初次启动微服务记得先调用下,防止超时
第3集 订单微服务下单支付全链路多场景测试
简介:订单微服务下单支付宝支付全链路多场景测试
- 登录-加入购物车-使用优惠券-下单-支付
- 代码本身有问题-比如真的少了参数
- 代码bug修改下单协议:total_amount、timeout_express
- 支付沙箱环境抽风(偶尔出现)
- 代码本身有问题-比如真的少了参数
- 下单支付全链路测试-支付-超时未支付(优惠券记录释放正常、商品库存释放正常、订单关闭正常)
- 登录-加入购物车-使用优惠券-下单-不支付(数据正常)
{
"coupon_record_id":50,
"product_ids":[1,2],
"pay_type":"ALIPAY",
"client_type":"H5",
"address_id":45,
"total_amount":510,
"real_pay_amount":505,
"token":"SbD5D4FLpUzemiuwSEytwGM9LLFGISDQ"
}
第4集 订单微服务订单列表和订单项功能开发
简介:订单微服务分页查询个人订单列表功能开发
- 分页个人查询订单功能开发
第5集 未支付订单二次支付业务逻辑设计和编码实战
简介:未支付订单二次支付业务逻辑设计和编码实战
- controller开发
- service开发
第6集 未支付订单二次支付全链路测试
简介:未支付订单二次支付业务逻全链路测试
- 全链路测试
- 加入购物车
- 下单不支付
- 我的订单列表
- 二次支付
- 备注
- 测试的时候可以快速下两笔订单,3分钟内可以支付,3分钟后就不行
- 订单支付超时,可以往前推,也可以往后推1分钟
第7集 订单微服务-避免重复下单token令牌机制 lua脚本原子操作
简介:订单微服务-避免重复下单tokne令牌机制处理
- 问题
- 前端下单按钮重复点击导致订单创建多次
- 前端有限制,后端也需要有限制
- 任何提交表单的时候,都可以采用token令牌机制避免重复点击
- token令牌机制开发
- 下单前先获取令牌-存储redis
- 下单时一并把token提交并检验和删除-lua脚本
String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";