学习
实践
活动
工具
TVP
写文章

支付系统设计支付系统的账户模型

账户体系是支付系统的基础,它的设计直接影响整个系统的特性。这里探讨如何针对电子商务系统支付账户体系设计。我们从一些基本概念开始入手,了解怎么建模。 支付账户和登录账号 账户体系设计首先要区分两个概念,支付账户和登录账号。 这是两个不同业务领域的概念:支付账户指用户在支付系统中用于交易的资金所有者权益的凭证;登录账号 指用户在系统中的登录的凭证和个人信息。 账户的设计需求 在支付系统中,账户的设置,主要是从如下几个方面来考虑: 交易的需求,比如检查账户是否被锁定、余额是否足够、是否有效等。 本文也暂不分析这内容,将在《信用与支付》一文中分析。 这五个需求,按照其设计的优先级,也是从支付、记账、对账、风控来进行。支付系统根据其发展所处的阶段,逐步将新增需求纳入设计中。

8120

支付系统设计支付系统的账户模型

账户体系是支付系统的基础,它的设计直接影响整个系统的特性。这里探讨如何针对电子商务系统支付账户体系设计。我们从一些基本概念开始入手,了解怎么建模。 支付账户和登录账号 账户体系设计首先要区分两个概念,支付账户和登录账号。 这是两个不同业务领域的概念:支付账户指用户在支付系统中用于交易的资金所有者权益的凭证;登录账号 指用户在系统中的登录的凭证和个人信息。 账户的设计需求 在支付系统中,账户的设置,主要是从如下几个方面来考虑: 交易的需求,比如检查账户是否被锁定、余额是否足够、是否有效等。 本文也暂不分析这内容,将在《信用与支付》一文中分析。 这五个需求,按照其设计的优先级,也是从支付、记账、对账、风控来进行。 支付系统根据其发展所处的阶段,逐步将新增需求纳入设计中。

1.5K21
  • 广告
    关闭

    9块9,云智绘帮您轻松搞定营销设计!

    10万模板,1亿优质图库,正版商用授权,涵盖电商、banner海报、新媒体配图、教育培训海报、H5等各种场景

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    支付系统设计从0到1】支付系统账户体系设计(上)

    在银行、支付公司以及电商平台的支付系统中,如果不是只做交易转发,而是真正需要做账务处理清结算,一定会涉及到账户体系的设计,一套好的账户体系应该是与业务无关的。 账户体系在银行叫核心系统,在支付公司或者电商平台都是虚拟账户体系。在这一篇里我们主要讲讲支付系统的账户体系的产品设计,在下一篇里重点介绍技术设计中需要考虑的问题。 所以,我们在支付系统设计中一般是将记账为分2个步骤,支付成功后系统同步记录流水账,异步通知会计系统做复式记账。 传统的第一代支付系统通常是日终批量记账;现在的流行的支付系统设计通常是异步准实时记账,日终根据银行对账文件,对当日记账做批次结转核对并记录。 所以通常来讲,我们的支付过程与会计记账过程会进行分离。 下一篇详细介绍不同子系统的技术设计。 ----

    1.8K11

    支付系统设计从0到1】支付系统账户体系设计(下)

    在上一篇里我们主要讲了支付系统的账户体系的产品设计,在这一篇里重点介绍技术设计上需要考虑的一些问题。 客户信息子系统技术设计 客户和用户涉及的信息 客户是一个社会化的概念,一个自然人或一个法人(任何社团、组织、机构等,具有社会关系比较紧密,并且有相似消费特征的团体)就称之为一个客户。 客户信息子系统技术设计 通常来讲,客户和用户信息属于比较静态的数据,数据量也不会很大,即使是微信这样也就几亿用户,可以用单库单表硬撑,在数据库上只需要做主从高可用、读写分离考虑即可,如果有条件,还可以加一个 账户子系统 账户子系统存储要素 该系统是整个账户体系的核心,在按照产品设计进行会计科目划分后,体现为单个账户,这些账户,具体在系统中落地为2类数据库表,一个是账户余额表(又叫账户表),主要用来记录账户基本信息 账户子系统技术设计 在存储层面,首先需要考虑的是账户流水会很多,而且都是按账户进行查询检索,所以可以考虑按客户号进行水平切分、分库分表,保证在交易过程中尽量只查单表,不跨库和多表联表查询。

    97511

    支付系统设计中,如何防止重复支付?

    wallet-2292428_1280.jpg 在我们支付系统设计中,经常会遇到这样一个问题,防止用户重复支付。 用户明明只想购买一次,却因为系统问题,导致重复支付,带来额外的物流成本和扯皮退货的运营成本,对商家的信誉和系统的体验很不好。 那么实际我们在设计支付系统时,如何来避免这一问题呢。 如何防止重复支付提交 在我们实际支付系统设计中,我们系统设计人员经常无法区分商品订单和支付订单之间的关系,经常混为一谈。 2.收到渠道异步通知或者通过查询得到渠道支付状态时,更新该笔支付订单状态 3.如果客户再次发起支付,不给客户产生新的支付订单号,先用该笔支付订单号调用支付系统支付系统会判断订单号幂等性,如果已支付,则报错告诉客户已支付成功 结论 在实际设计中,无论多么好的技术,也不可能100%的拦截所有的可能性,必须依靠技术+产品设计+运营支持的综合手段才能解决这类问题。所以即便京东这一类电商等也是配合运营手段进行处理。

    2.5K31

    支付对账系统怎么设计

    支付对账系统是整个支付清结算体系中具体基础性意义的一个环节,是确保支付平台与各类第三方支付渠道数据一致性的关键系统,是商户资金结算、资金划拨、资金报表等逻辑准确运行的重要前提。 针对不同的差错类型情况,需要根据根据系统实际情况,设计相应地处理流程。 而如果是因为支付平台状态未处理成功,则是系统掉单问题导致,除了正常消除这笔差错、产生对应的对账明细数据外,还需要通知支付系统进行状态更新操作,其涉及的业务逻辑,还需要根据整个支付平台的流程设计,触发商户回调 总之,需要根据具体的差错类型及原因,结合整个支付系统的流程来保证系统间数据的一致性,以下是作者根据通用场景设计、根据不同差错类型设计的处理流程,供大家参考: (一)、长款差错通用处理流程 ? 在以上长款处理流程中,关于跨天交易情况的区分,这里有一个细节的设计:在判断完支付订单状态为成功后,之所以在判断是否在T-1天或者T-N天是否存在同一笔匹配的短款差错之前,判断是否存在对账明细的情况,是因为在系统设计时考虑订单结算的实时性

    1.9K22

    支付系统设计从0到1】支付系统流程和典型架构设计

    3.支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作,最终落地资金转移。 支付系统的典型架构 ? 支付核心系统 设计原则 支付网关、支付产品和支付渠道的职责分工为: 1.按照支付能力来划分支付产品。 2.同一支付能力的公共支付流程,在支付产品中实现。 支付渠道 支付渠道模块是调用支付渠道接口执行真正的资金操作。 支付核心系统交易请求数据流 1.支付请求被发送到支付网关。 3.支付产品调用支付渠道执行支付。这个请求并不是直接落地到渠道上,而是通过支付渠道前置来封装,由支付渠道前置来完成和渠道的交付。 支付产品是按照可以提供的支付服务来设计的。 ---- 本文参考“凤凰牌老熊”、“梁川”、“路杨”、“叉一”等相关支付系统架构设计文章结合自己支付系统设计经验整理。 坚持原创,只说真话,我就是金融民工小曾。

    89320

    支付系统架构设计详解

    内容导读:支付永远是一个公司的核心领域,因为这是一个有交易属性公司的命脉。那么,支付系统到底长什么样,又是怎么运行交互的呢? 抛开带有支付牌照的金融公司的支付架构,下述链路和系统组成基本上符合绝大多数支付场景。 其实整体可以看成是交易核心+支付核心 两个大系统。 交易系统关联了业务场景和底层支付,而支付系统完成了调用支付工具到对账清算等一系列相关操作。下面我们就来一起看下 各个系统的核心组成和交互。 作者:Petter Liu 出处:http://www.cnblogs.com/wintersun/ Part one 支付系统总览 核心系统交互 业务图谱 Part two 核心系统解析 交易核心 交易核心把公司的业务系统和底层支付关联起来,让业务系统专注于业务,不比关心底层支付

    10130

    支付系统架构设计详解

    内容导读:支付永远是一个公司的核心领域,因为这是一个有交易属性公司的命脉。那么,支付系统到底长什么样,又是怎么运行交互的呢? 抛开带有支付牌照的金融公司的支付架构,下述链路和系统组成基本上符合绝大多数支付场景。 其实整体可以看成是交易核心+支付核心 两个大系统。 交易系统关联了业务场景和底层支付,而支付系统完成了调用支付工具到对账清算等一系列相关操作。下面我们就来一起看下 各个系统的核心组成和交互。 作者:Petter Liu 出处:http://www.cnblogs.com/wintersun/ Part one 支付系统总览 核心系统交互 业务图谱 Part two 核心系统解析 交易核心 交易核心把公司的业务系统和底层支付关联起来,让业务系统专注于业务,不比关心底层支付

    13820

    支付系统架构设计详解

    核心系统交互 业务图谱 Part two 核心系统解析 交易核心 支付核心 渠道网关 资金核算 Part three 服务治理 平台统一上下文 数据一致性治理 DB拆分 异步化 Part four 生产实践 那么,支付系统到底长什么样,又是怎么运行交互的呢? 抛开带有支付牌照的金融公司的支付架构,下述链路和系统组成基本上符合绝大多数支付场景。 其实整体可以看成是交易核心+支付核心 两个大系统。 交易系统关联了业务场景和底层支付,而支付系统完成了调用支付工具到对账清算等一系列相关操作。下面我们就来一起看下 各个系统的核心组成和交互。 Part one 支付系统总览 核心系统交互 业务图谱 基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 项目地址:https://github.com/YunaiV/ruoyi-vue-pro Part two 核心系统解析 交易核心 交易核心把公司的业务系统和底层支付关联起来,让业务系统专注于业务,不比关心底层支付

    16930

    支付系统架构设计详解

    Part one 支付系统总览 核心系统交互 业务图谱 Part two 核心系统解析 交易核心 交易核心把公司的业务系统和底层支付关联起来,让业务系统专注于业务,不比关心底层支付。 同时,还要负责集成多种支付工具,对支付指令进行编排等等。 支付核心总览 支付行为编排 其目的,是实现 插件式开发、支付规则可配置的 灵活开发方式。 渠道网关 资金核算 Part three 服务治理 平台统一上下文 通过确定系统边界、业务建模拆分之后,整个支付平台被拆分几十个服务,而如何保障在服务间流转业务信息不被丢失,是我们需要考虑的问题。 CAS校验 幂等 & 异常补偿 对账 准实时对账 DB拆分 异步化 支付是整个交易链路的核心环节,那么,怎么兼顾支付系统的稳定性和执行效率呢?是异步化。 资金核算异步化 热点账户账务单独处理 记账事务切分 Part four 生产实践 性能压测 构建压测模型,模拟现实真实场景;压测数据进影子库,正常业务无侵入;单机性能和集权链路都不能忽视;识别系统稳定性和容量配比

    63940

    支付系统设计从0到1】支付渠道对账产品设计

    支付渠道中,除了联机交易以外,最重要的功能是对账,而对于不同的支付渠道,支持的对账方式都不同。这篇文章就给大家详细讲讲支付渠道对账设计的那些事。 对账单获取 通常我们接入的支付渠道比如支付公司、银行、银联,在提供联机交易API以外,一般都提供了对账单下载服务,还有一些仅提供账单交易查询接口或者提供从管理台下载账单文件的方式。 通常来讲,我们需要关心对账单内容有:支付渠道流水号、商户订单号、金额、状态标识(成功,失败)、交易时间、支付时间、清算日期、交易类型。 本系统交易记录 对账交易,其业务意义更多的是在每天日终,确认联机交易中发生调单的交易或者未知的交易是否成功,然后进行相应的账务调账处理。 所以我方需要抽出当天发生的所有交易流水,成功、未知以及失败的(极端情况下会出现我方失败但是渠道成功的情况,比如我方系统或者渠道系统出现问题) 对账过程(轧帐) 由于交易都是我方发起,所以理论上,渠道方应该是我方交易的子集

    1K22

    我的支付总结(二) 系统设计

    支付系统将流程划分为业务受理、支付前置和支付网关、终态获取、结果处理四个大部分,各部分之间以消息队列或系统之间的交互分隔。风控和路由属于支付前置服务,但由于其重要性和复杂性,将它们提出来分别介绍。 支付网关 支付网关是支付系统与三方系统的交互接口,支付网关的设计要考虑的重点是报文的交互。 结果处理 获取到支付结果后,不光要及时更新自己系统内的支付状态,还要考虑对交易的后续处理: 结果通知:同三方系统通知支付系统支付系统要将支付结果及时通知商户。 为了确保通知成功,重试机制是必不可少的,这里考虑三方系统通知支付系统的逻辑。 推送账务系统:由于支付系统的账务由账务和资金管理系统负责,支付系统只负责交易结果的推送。 小结 理清了支付的各个必备模块,系统设计应该就会很清晰了,完成了系统设计,后续的工作就剩下代码的堆砌和完善了。 支付服务中的每一块都有一定的“门道”,有机会和必要的话,会单独拿出来一块写。 感谢关注。

    940101

    堪称最详细的支付系统设计

    通常消费者在手机APP或者网站都会涉及到支付相关的业务场景,用户只需要简单点击支付按钮输入支付密码,就可以完成整个支付过程,那么我就和大家一起来看看一个完整的支付系统有什么功能组成和设计时需要考虑那些问题 系统提供资金流转过程中各个环节的数据,能够从各个维度进行核算和分析,形成对管理人员的决策支持,从而提高决策效率。 03 关键表设计 ? 这样接入方就只需要对接支付网关,增加和调整支付渠道对业务方是透明的。 支付网关前置的设计对整个支付系统的稳定性、功能、性能以及其他非功能性需求有着直接的影响。 总结 支付系统是一个繁杂的系统,其中涉及了各种错综复杂的业务流程,以上只是简单介绍了支付系统我们能看见的一些问题和设计,还有后续的系统保障没有写出来,没写出来的才是关键部分,比如:支付系统监控(业务监控分类 只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了以上所有的业务细节,仍然需要演化式思维,在设计的同时,借助反馈和进化的力量推动架构的持续演进。

    10.4K76

    支付系统订单模型该如何设计

    看到这里,也许不少同学都会诧异,这尼玛为啥不设计相应的机制来解决呢?所以,这个时候开始有人谈起了支付系统重构的问题。而此时作者正好加入这家公司,所以心想也算一个机会,于是也提出的自己的重构方案。 于是乎,好像此时此刻,这件事应该是向着好的方向发展了,支付系统应该是在比较充足的资源配置的情况下,并且经过合理的设计后开始有计划有步骤地重构了。 那么如果假设你承担了这一角色,或者作为一名具体的工程师,在你具体重构或设计支付系统时,如何尽可能地想得长远一些呢?这里有作者根据自身经验设计的一套逻辑模型,供你参考。 ? 上图是一张精简的关于支付系统订单模型设计的图,在模型中我们将订单分为交易&支付两个层面,之所以要这么划分,是在于我们进行支付系统开发时很多时候是需要满足一部分业务逻辑的,而设置交易订单的目的则是为了屏蔽这种业务不确定性而带给支付订单本身的复杂性 按照这种模型进行支付订单结构的设计,并在一开始就撸清楚这些支付场景的对应的数据存储逻辑,会对未来系统的拆分扩展大有好处,因为至少数据逻辑是非常清晰的了。

    1.1K11

    领域驱动设计实践:支付系统建模

    (DDD)方法被用来指导如何对复杂的业务问题和系统设计进行建模。 软件行业中的许多设计模式 都能解决这些问题,在Airwallex,我们尝试采用领域驱动设计(DDD)的方法来为我们的支付系统建模,以管理系统设计中的复杂性。 有助于根据业务领域的基础模型设计软件系统。 从领域模型到微服务 现在,我们已经为支付系统定义了一组有边界的上下文,并在每个有边界的上下文中确定了一组实体、集合体和领域事件服务。 下一步就是要从领域模型到应用微服务的设计。 结论 在这篇博客中,当我们试图对支付系统进行建模时,我们触及了领域驱动设计(DDD)模式的各种概念和策略。

    24210

    领域驱动设计实践:支付系统建模

    (DDD)方法被用来指导如何对复杂的业务问题和系统设计进行建模。 软件行业中的许多设计模式都能解决这些问题,在Airwallex,我们尝试采用领域驱动设计(DDD)的方法来为我们的支付系统建模,以管理系统设计中的复杂性。 | 什么是DDD 领域驱动设计(DDD)是由埃里克-埃文斯(Eric Evans)提出的,它是一套思想、原则和模式,有助于根据业务领域的基础模型设计软件系统。 | 从领域模型到微服务 现在,我们已经为支付系统定义了一组有边界的上下文,并在每个有边界的上下文中确定了一组实体、集合体和领域事件服务。 下一步就是要从领域模型到应用微服务的设计。 | 结论 在这篇博客中,当我们试图对支付系统进行建模时,我们触及了领域驱动设计(DDD)模式的各种概念和策略。

    19540

    支付系统

    通常消费者在手机APP或者网站都会涉及到支付相关的业务场景,用户只需要简单点击支付按钮输入支付密码,就可以完成整个支付过程,那么我就和大家一起来看看一个完整的支付系统有什么功能组成和设计时需要考虑那些问题 系统提供资金流转过程中各个环节的数据,能够从各个维度进行核算和分析,形成对管理人员的决策支持,从而提高决策效率。 03 关键表设计 ? 这样接入方就只需要对接支付网关,增加和调整支付渠道对业务方是透明的。 支付网关前置的设计对整个支付系统的稳定性、功能、性能以及其他非功能性需求有着直接的影响。 总结 支付系统是一个繁杂的系统,其中涉及了各种错综复杂的业务流程,以上只是简单介绍了支付系统我们能看见的一些问题和设计,还有后续的系统保障没有写出来,没写出来的才是关键部分,比如:支付系统监控(业务监控分类 只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了以上所有的业务细节,仍然需要演化式思维,在设计的同时,借助反馈和进化的力量推动架构的持续演进。 END

    1.4K41

    千万级支付对账系统是怎么设计的?

    今天给大家分享一篇关于对账系统设计的文章,出自在支付行业摸爬滚打好几年的小黑哥之手。 如果你之前做过支付相关的业务一定多多少少都接触过“支付数据对账”的问题。 随着交易规模的增长,对账系统设计也一定是在不断的进行迭代。 而本文就是探讨对于每日千万级数据量的时候,对应的对账系统大致应该是长什么样的。 先简单的看一下之前的对账系统设计,了解下对账的整体流程。 原先系统设计上,单一渠道对账处理流程只能在单个机器上处理,无法并行处理。 这就导致系统设计伸缩性很差,服务器资源也被大量的浪费。 — 10 — 对账系统概览 开头的时序图,我们可以看到整个对账过程设计好几个业务流程,那在这里对账系统内部将会维护一个流程状态机,当前一个流程处理结束之后,下一个流程才能被触发。

    8910

    扫码关注腾讯云开发者

    领取腾讯云代金券