Hello,大家好,我是小黑哥~ 前端时间小黑哥在公司接手了一个支付项目,这个项目接入了微信、支付宝。这个项目开发下来,小黑哥可是完完整整体验了一下微信、支付宝开发流程,也踩了一些坑。 最近正好看到有些小伙伴想接入微信、支付宝,但是不知道如何开发,所以小黑哥就给大家总结一下微信支付、支付宝接入开发流程。 总体流程 明确使用支付方式 首先我们需要明确我们需要使用的支付方式。 因为微信支付、支付宝中存在很多支付方式,不同支付方式对应的不同的业务场景,开发对接复杂度也不太一样。 以微信支付举例,其总共提供如下几种的支付方式。 这几种支付方式对应的不同的业务场景,比如说: 付款码支付:商家使用扫码枪或其他扫码机具扫描用户出示的付款码,适合于线下商超收款 Native支付:商家在系统中按微信支付协议生成支付二维码,用户扫码拉起微信收银台,确认并完成付款 JSAPI 支付:用户在商家公众号内下单,输入密码支付,完成支付,适合于在线购物的场景 APP 支付:用户在商家的APP中下单,跳转到微信中完成支付,支付完后跳回到商家APP内,展示支付结果 H5 支付:用户在手机浏览器中下单,然后跳转到微信.... 微信支付、支付宝最全接入指引,看完立刻就可以上手! 支付系统
封面送给我狗哥,今天终于大结局了!可伶我钦哥,这么惨了,最后还要把他写没了!! Hello,下午好,我是楼下小黑哥~ 今天的文章我们接着上次的话题,继续聊聊支付系统异常解决办法。 在上篇文章中「支付掉单异常解决方案」,我们主要提到的是支付过程中掉单的场景,用户明明付款成功,银行卡都扣款了,但是订单却还显示待付款。 而在今天的文章中,我们将聊到重复付款的异常,即同一笔订单,扣了用户两笔钱。 另外我们还将会提到另外一种异常,用户扣款成功,但是订单却支付失败的场景。 以上两种异常对于被扣款的用户来讲,使用体验极差,自己多付了钱,订单却还不成功。所以如果不及时处理这两类异常,那就真的等着被投诉吧。 重复付款异常 异常场景 重复付款异常一般常见于网银支付,微信支付,支付宝等这类需要跳转到一个支付网关页(网银支付),或者跳转到钱包 APP(支付宝、微信),从而异步完成扣款的支付场景。 这种支付场景下,只能通过接受异步通知才能知道支付结果,我们一般将其称为异步支付。 PS:有了异步支付,那么同步支付是什么? 其实同步支付指的就是调用支付接口之后,就可以立刻返回支付结果的,比如银行卡类快捷/代扣等.... 一笔订单,但是误付了两笔钱!这种重复付款异常到底该如何解决?|原创 支付系统
小黑碎碎念 Hello,大家好,我是楼下小黑哥~ 这个长假不知道大家玩的开心不?有没有出去玩就被堵在路上的? 哈哈,这个长假,我过的还是有点累( Ĭ ^ Ĭ )。 长假前两天都在加班迁移旧系统的历史数据,由于这个依赖我同事那边的迁移进度,所以第一天其实还好,就是划划水,优化一下程序,晚上还出去看了下『姜子牙』。 第二天的时候,又划了一天的,等到晚上的时候,同事终于把他那边的迁移搞定,我终于可以开始迁移。 可是这个时候甲方爸爸竟然开始加各种需求了,没办法,只能满足他们,临时再开始修改程序,然后再加上监控,一直搞到了12 点。 搞完这下,本来以为没啥幺蛾子了,长假只要每天看看迁移进度就可以了。 哎,没想到设计的时候忘记考虑性能的问题,等到数据量增长到千万的时候,查询速度奇慢,无奈只好优化程序,想办法让查询加快,最后一直搞到了凌晨四点 ┭┮﹏┭┮ 真的是设计不规范,加班两行泪啊~后面有机会跟大家复盘一下这次大数据量迁移。 前言 好了,回归到今天的主题,今天分享一下支付系统中异常一些处理方式。 其实这些处理方式并不只是局限于支付系统,也可以适用于其他系统,大家可以借鉴,应用到自己系统中,提高.... 有更新! 钱被扣走了,但是订单却未成功!支付掉单异常最全解决方案 架构设计
上次的文章手机没网了,却还能支付,这是什么原理?发布之后,没想到大家都比较感兴趣,所以反响还不错。 另外这篇文章还被码农翻身公号改编成漫画漫画:如何盗刷别人的支付宝?,嘿嘿不得不说,还是刘欣老师讲解的更加清晰明了。 现在这篇文章阅读数据已经破千,虽然对于其他号主来说还是很少的数据,但是对于我来说,真是第一个里程碑,期待后面越来越好~ -------------------------我是分割线------------------- 好了,不 BB 了,今天跟大家分享一下聚合收款码的支付原理,这也是我这大半年来一直在做的项目。 微信/支付宝收款码大家应该不会陌生,线下小微商户收款大多使用这个,就比如下图。 这种收款方式很方便,微信、支付宝后台申请开通,然后还可以免费申请相关物料。 不过这种方式用户体验其实不是很好,之前有好几次拿出支付宝,却扫了微信支付码。 另外,这种个人的收款码通常还有单日收款的上限,比如支付宝单日上限 500元。 有了需求,自然会有聪明人人想到解决方案,于是有了聚合收款码产品解决方案,如下图。 一个收款码,支持多种客户端,主流是微信、支付宝,现在常见还会支持银联,.... 有更新! 收款神器!解读聚合收款码背后的原理|原创 支付系统
Hello,大家好,我是鸭血粉丝~ 最近看同事的代码时候,学到了个小技巧,在某些场景下非常挺有用的,这里分享一下给大家。 Spring 中 @Autowired注解,大家应该不会陌生,用过 Spring 的肯定也离不开这个注解,通过这个注解可以帮我们自动注入我们想要的 Bean。 除了这个基本功能之外,@Autowired 还有更加强大的功能,还可以注入指定类型的数组,List/Set 集合,甚至还可以是 Map 对象。 比如说当前应用有一个支付接口 PayService,分别需要对接支付宝、微信支付、银行卡,所以分别有三个不同实现类 AliPayService,WechatPayservice,BankCardPayService。 四个类的关系如下图所示: 如果此时我需要获取当前系统类所有 PayService Bean,老的方式我们只能通过 BeanFactory或者 ApplicationContext 获取。 // 首先通过 getBeanNamesForType 获取 PayService 类型所有的 Bean String[] names = ctx.getBeanN.... 巧用 Spring 自动注入快速实现策略模式 Spring
今天小黑哥来跟大家介绍一下 Redis 发布/订阅功能。 也许有的小伙伴对这个功能比较陌生,不太清楚这个功能是干什么的,没关系小黑哥先来举个例子。 假设我们有这么一个业务场景,在网站下单支付以后,需要通知库存服务进行发货处理。 上面业务实现不难,我们只要让库存服务提供给相关的给口,下单支付之后只要调用库存服务即可。 后面如果又有新的业务,比如说积分服务,他需要获取下单支付的结果,然后增加用户的积分。 这个实现也不难,让积分服务同样提供一个接口,下单支付之后只要调用库存服务即可。 如果就两个业务需要获取下单支付的结果,那也还好,程序改造也快。可是随着业务不断的发展,越来越多的新业务说是要下单支付的结果。 这时我们会发现上面这样的系统架构存在很多问题: 第一,下单支付业务与其他业务重度耦合,每当有个新业务需要支付结果,就需要改动下单支付的业务。 第二,如果调用业务过多,会导致下单支付接口响应时间变长。另外,如果有任一下游接口响应变慢,就会同步导致下单支付接口响应也变长。 第三,如果任一下游接口失败,可能导致数据不一致的情况。比如说下图,先调用 A,成功之后再调用 B,最后再调用 C。.... Redis 发布订阅,小功能大用处,真没那么废材! Redis
哎,最近小黑哥又双叒叕犯事了。 事情是这样的,前一段时间小黑哥公司生产交易偶发报错,一番排查下来最终原因是因为 Redis 命令执行超时。 可是令人不解的是,生产交易仅仅使用 Redis set 这个简单命令,这个命令讲道理是不可能会执行这么慢。 那到底是什么导致这个问题那? 为了找出这个问题,我们查看分析了一下 Redis 最近的慢日志,最终发现耗时比较多命令为 keys XX* 看到这个命令操作的键的前缀,小黑哥才发现这是自己负责的应用。可是小黑哥排查一下,虽然自己的代码并没有主动去使用 keys命令,但是底层使用框架却在间接使用,于是就有了今天这个问题。 问题原因 小黑哥负责的应用是一个管理后台应用,权限管理使用 Shiro 框架,由于存在多个节点,需要使用分布式 Session,于是这里使用 Redis 存储 Session 信息。 画外音:不知道分布式 Session ,可以看看小黑哥之前写的 一口气说出 4 种分布式一致性 Session 实现方式,面试杠杠的~ 由于 Shiro 并没有直接提供 Redis 存储 Session 组件,小黑哥不得不使用 Github 一.... 血的教训!千万别在生产使用这些 redis 指令 Redis
最近在学习 Redis 相关内容,为此买了两本关于 Redis 的书籍,一本为 「Redis 设计与实现」,另一本为 「Redis 开发与运维」。 目前大概看了一半,个人聊聊两本书籍的的区别。 第一本 「Redis 设计与实现」,这本书主要偏重与底层原理,本书大部分内容都是从底层 C 语言代码介绍,再结合大量插图的讲清楚其中技术点。 这样的优点在于从源码出发,可以很深刻的理解其中设计实现点,另外还可以偷学一波大佬们的代码。 第二点,对于有些原理,直接从代码理解,可能很不好弄懂,不过通过插图方式,一下子就能看懂。 再来说说这样的缺点,对于没学过 C 语言的,或者说只接触过 Java 的同学来讲,这样直接从 C 语言看起真的很难。 还记得个人两年前就同事那里看过这本书,刚看第一张,就被劝退了。 密密麻麻的 C 语言,看的真的头疼! 不过随着自己编程经验越来越丰富,现在再来看这些 C 语言代码,已经没有那么费劲。 不知道大家有没有发现,以前有些看不懂的原理知识,有些觉得很难的原理,随着编程经验越来丰富,渐渐都明了了,都能看懂了。 所以有些东西如果在你这阶段真的看不懂,那就不要纠结,适当放弃.... 这两本 Redis 书籍,真经典!! Redis
最近,小黑哥的一个朋友出去面试,回来跟小黑哥抱怨,面试官不按套路出牌,直接打乱了他的节奏。 事情是这样的,前面面试问了几个 Java 的相关问题,我朋友回答还不错,接下来面试官就问了一句:看来 Java 基础还不错,Java HashMap 你熟悉吧? 我朋友回答。工作经常用,有看过源码。 我朋友本来想着,你随便来吧,这个问题之前已经准备好了,随便问吧。 谁知道,面试官下面一句: 那好的,我们来聊聊 Redis 字典吧。 直接将他整蒙逼。 小黑哥的朋友由于没怎么研究过 Redis 字典,所以这题就直接回答不知道了。 当然,如果面试中真不知道,那就回答不了解,直接下一题,不要乱答。 不过这一题,小黑哥觉得还是很可惜,其实 Redis 字典基本原理与 HashMap 差不多,那我们其实可以套用这其中的原理,不求回答满分,但是怎么也可以得个及格分吧~ 面试过程真要碰到这个问题,我们可以从下面三个方面回答。 数据结构 元素增加过程 扩容 字典数据结构 说起字典,也许大家比较陌生,但是我们都知道 Redis 本身提供 KV 查询的方式,这个 KV 就是其实通过底层就是通过字典保存。 另外,.... 阿里面试官:HashMap 熟悉吧?好的,那就来聊聊 Redis 字典吧! Redis