1.支付系统设计：支付系统的账户模型(一)
Alipay账户体系产品设计-上海-分享
一个账户有很多维度，科目只是会计维度账户由科目定的，所以一个账户只能归一个科目下，当然，一个账户有不同维度，还可以从产品上去分，设定产品账。
要做好统计，得分维，科目就是维度，为了好分析，又要降维，所以才出了总账。
根据科目账户原理，账户必须隶属于某个科目账户只能隶属于叶子科目，而不能隶属于非叶子科目。
会计核算阿里产品分享账务会计（一）缓冲记账配置和管理缓冲记账是指针对频繁需要进行账务操作的部分帐户提供一种缓冲记账模式（含汇总记账），可以将该账户在一段时间内的账务操作请求放在一次性账务操作中进行处理，避免系统性能瓶颈。
用缓冲记账处理的帐户统一登记在如下表结构的数据表中：（会计分录的记帐其实也可以参考缓冲记帐）账务核心系统在系统启动时自动加载该表的配置内容，并在每日首次被使用时刷新加载数据。
也就是说，任何一项的修改，都将在次日生效。
不选择实时生效的原因是缓冲记账必须在完整的账务日内实现，如果中途随时加载，会造成当日一部分数据是实时记账，一部分数据是缓冲记账，从而导致日终时无法统一处理。
对缓冲记账业务的配置与管理过程，实质就是对这样一个表进行数据增加、删除、修改、查询的操作，应允许设置各个参数项即可。
字段说明：1、某付宝账号：需要使用缓冲记账处理的20位某付宝账号；Account_ID2、业务代码：需要使用缓冲记账处理的6位业务代码；3、补账间隔：缓冲记账处理的时间间隔，以秒为单位，如60秒，则每60秒进行一次缓冲记账；4、记账模式：具体缓冲记账的模式，缓冲记账则根据补账间隔执行记账操作，汇总记账则在日终时汇总执行记账操作；5、其他：其他除了创建时间、最后修改时间为必选，其他字段均为业务预留字段，暂时没有直接的业务应用；业务限制：不允许同一个账号、同一个业务代码配置两条记录，比如某账号的某业务即做收款缓冲，又做付款缓冲，这样的配置业务上是不存在的，系统也应是不允许的。
账务核心系统在系统启动时自动加载该表的配置内容，并在每日首次被使用时刷新加载数据。
电子支付系统的设计与实现方法
电子支付系统的设计与实现方法随着社会的快速发展和技术的不断进步，电子支付系统已经成为现代社会不可或缺的一部分。
电子支付系统通过互联网和电子设备，使得消费者能够快捷、便利地完成交易，并实现资金的安全转移。
本文将讨论电子支付系统的设计与实现方法，包括系统架构、支付流程和安全性保障。
一、系统架构电子支付系统的设计应该基于一个稳定、高效的系统架构。
通常，一个典型的电子支付系统包括以下几个主要组成部分：用户界面、商户接口、支付网关、清算系统和金融机构接口。
1. 用户界面：用户可以通过网页或手机应用程序来访问支付系统，进行支付、查询余额等操作。
用户界面应该简洁、直观，方便用户操作。
2. 商户接口：商户接口主要用于连接商家和支付系统。
商户可以通过接口向支付系统发送支付请求，并接收支付结果通知。
3. 支付网关：支付网关是整个支付系统的核心部分，它负责接收和处理支付请求，包括用户身份验证、资金扣除和订单状态更新等。
4. 清算系统：清算系统用于处理支付系统与金融机构之间的结算操作，包括资金结算、账户管理和对账等。
5. 金融机构接口：为了与银行和其他金融机构进行通信，电子支付系统需要建立相应的接口，实现支付和结算等功能。
二、支付流程电子支付系统的支付流程关键是确保支付安全和效率。
下面是一般的电子支付流程：1. 用户注册：用户需要在支付系统中注册账户，提供基本信息和支付方式等。
2. 选择商品：用户登录支付系统后，可以浏览商品列表，并选择所需商品。
3. 购物车和结算：用户将选择的商品添加到购物车，然后通过支付系统进行结算操作。
4. 支付授权：用户选择支付方式，并提供相应的支付信息。
支付网关将发送支付请求给相关的金融机构，并等待支付结果。
5. 支付确认：支付网关接收到支付结果后，将结果通知给用户和商户。
如果支付成功，商户可以发货，如果支付失败，用户可以选择其他支付方式或取消订单。
6. 清算和结算：支付系统与金融机构进行结算操作，将支付的资金从用户账户转移到商户账户，并进行相应的账务处理。
支付系统设计范文
支付系统设计范文一、系统架构设计支付系统的架构设计需要根据实际需求和可扩展性考虑，一般包括前端界面系统、交易处理系统和后端数据库系统。
1.前端界面系统：用于接收用户的支付请求和显示支付结果。
设计时需要考虑用户友好性和易用性，包括界面布局、页面设计、输入验证和反馈机制等。
2.交易处理系统：负责处理支付请求和与第三方支付机构进行交互。
设计时需要考虑高并发处理、事务一致性和异常处理等，包括支付流程控制、订单管理、支付验证和交易记录等功能。
3.后端数据库系统：用于存储支付系统的相关数据，包括用户信息、支付记录、交易明细等。
设计时需要考虑数据安全性和可靠性，包括数据库结构设计、数据加密和灾备方案等。
二、模块设计支付系统一般包括用户管理模块、支付模块、第三方支付模块和数据统计模块等。
1.用户管理模块：用于用户注册、登录和个人信息管理等。
设计时需要考虑用户身份验证、权限管理和数据隐私保护等。
2.支付模块：用于处理用户的支付请求。
设计时需要支持多种支付方式，包括银行卡支付、电子钱包支付和第三方支付等。
需要考虑交易风险控制、交易状态管理和退款处理等。
3.第三方支付模块：负责与第三方支付机构进行交互。
设计时需要考虑支付接口规范、支付通知机制和对接流程等。
4.数据统计模块：用于对支付系统的数据进行统计和分析。
设计时需要考虑数据采集、数据处理和数据可视化等。
三、数据流程设计支付系统的数据流程包括支付请求的生成、传输、处理和结果返回等。
1.支付请求生成：用户通过前端界面系统生成支付请求，包括选择支付方式、输入支付金额和订单信息等。
2.支付请求传输：支付请求通过网络传输到交易处理系统，需要建立安全的数据通道，采用加密和签名等技术进行数据保护。
3.支付请求处理：交易处理系统接收支付请求后，进行支付验证、订单管理和第三方支付等处理。
需要保证请求的完整性、一致性和正确性。
4.支付结果返回：支付结果通过网络返回给前端界面系统，同时更新数据库中的支付记录和订单状态。
在线支付系统的设计与实现
在线支付系统的设计与实现随着互联网技术的不断发展，移动支付已经成为人们生活中不可或缺的一部分。
而在线支付系统则是移动支付的一个重要组成部分。
在线支付系统简单来说就是用户可以通过网络进行支付的系统，其主要核心是在线支付平台。
在线支付系统设计的成功与否，对于商户和消费者来说都有着非常大的影响，本文将从设计与实现两个方面来探讨。
一、在线支付系统的设计1.系统架构在设计在线支付系统时，首要的是系统架构。
系统架构需要考虑到跨平台稳定性、扩展性和可维护性等因素。
同时，系统的架构应该是模块化的，这样可以方便不同模块的开发人员进行协同工作，提高开发效率。
最好基于可复用的开源框架进行搭建，这样既可发挥框架的优点，也能避免一些可能存在的问题。
2.服务端服务端设计的稳定性和安全性尤为重要。
服务器需要具备高效安全、高容错性、高效性、集群能力等特点，同时要对数据进行科学合理的存储，确保数据的安全性，并且保证在线支付的及时性。
在数据存储方面，需要注意数据的安全性和可靠性。
随着数据量的增大，对于系统的负荷也会越来越大，因此，服务器需要考虑到高可用性，通过负载均衡和优化性能等方式来提高服务质量。
3.客户端客户端的设计与实现要考虑用户体验度，不仅使用户可以轻松愉快地完成付款流程，同时也需要考虑用户安全。
客户端应该充分考虑用户体验，设计简单，易于操作的界面。
需要考虑不同操作系统以及设备的兼容性。
同时应该采用相应的安全技术，确保用户信息不被泄露。
在线支付系统要保证客户端与服务端之间的安全通信和交互，保证交易的安全性。
4.支付方式支付方式是在线支付系统中最核心的一部分。
支付方式的设计要根据用户喜好和使用情况，提供多种支付方式，如信用卡、银联、支付宝、微信支付等。
同时要保证安全性。
二、在线支付系统实现1.实现架构在具体实现系统时，服务端应该基于分布式架构进行设计，客户端需要支持不同的平台，如安卓、IOS、微信等。
在线支付平台需要与相关银行和支付平台进行联合，以便安全稳定地实现在线支付。
第三方支付系统总体设计方案
第三方支付系统总体设计方案一、系统概述第三方支付系统作为一种便捷、安全的在线支付解决方案，旨在为用户提供一站式的支付服务，同时为商家提供高效的交易处理能力。
本方案将从系统架构、功能模块、安全技术、运维保障等方面，全面阐述第三方支付系统的总体设计。
二、系统架构设计1. 系统层次结构本系统采用分层设计，自下而上分别为：数据层、服务层、业务逻辑层和展示层。
（1）数据层：负责存储用户、商户、订单等核心数据，采用关系型数据库进行数据管理。
（2）服务层：提供数据访问、业务处理、接口调用等基础服务。
（3）业务逻辑层：实现支付、退款、查询等业务逻辑处理。
2. 系统模块划分（1）用户模块：负责用户注册、登录、信息管理等功能。
（2）商户模块：负责商户入驻、资质审核、订单管理等功能。
（3）支付模块：实现支付、退款、查询等核心业务。
（4）安全模块：保障系统安全，包括数据加密、风险控制等。
（5）运维模块：负责系统监控、日志管理、故障排查等。
三、功能模块设计1. 用户模块（1）注册：用户可通过手机号、邮箱等方式注册账号。
（2）登录：支持密码、短信验证码等多种登录方式。
（3）信息管理：用户可修改个人信息、绑定银行卡等。
2. 商户模块（1）入驻：商户提交资料，平台审核通过后即可入驻。
（2）资质审核：平台对商户资质进行审核，确保合规经营。
（3）订单管理：商户可查看、处理订单，发起退款等。
3. 支付模块（1）支付：支持多种支付方式，如、支付等。
（2）退款：商户可发起退款申请，平台审核后进行退款。
（3）查询：提供订单查询、交易记录查询等功能。
四、安全技术设计1. 数据加密：采用国际通用的加密算法，对敏感数据进行加密存储和传输。
2. 安全认证：采用数字证书、短信验证码等方式，确保用户身份真实性。
3. 风险控制：通过大数据分析，实时监测交易风险，采取相应措施防范风险。
4. 系统防护：部署防火墙、入侵检测等安全设备，保障系统安全稳定运行。
移动互联网支付系统的功能设计与开发
移动互联网支付系统的功能设计与开发随着移动互联网的快速发展，移动支付成为了人们日常生活中不可或缺的一部分。
移动互联网支付系统的功能设计与开发，涉及用户需求分析、系统设计、安全性保障等方面。
本文将针对这些关键点进行讨论，以指导移动互联网支付系统的功能设计与开发过程。
一、用户需求分析用户需求分析是移动互联网支付系统开发的第一步。
在这一阶段，我们需要明确用户的需求和期望，以确保系统能够满足他们的实际需求。
首先，我们需要考虑到用户的支付场景。
移动互联网支付系统应该支持用户在不同场景下的支付需求，例如在线购物、线下商店消费、转账汇款等。
其次，我们需要重视用户的支付安全需求。
用户对支付安全的关注度越来越高，因此，移动互联网支付系统应该具备安全性强、防范风险的特点，例如支持指纹识别、动态验证码、交易密码双重验证等。
最后，我们还需要考虑用户的支付便利性。
用户希望支付过程简便快捷，不希望频繁输入密码或进行繁琐操作。
因此，移动互联网支付系统应该设计简洁明了的界面，支持快速支付和一键支付等功能。
二、系统设计在用户需求分析的基础上，我们需要进行系统设计，包括系统架构设计、数据模型设计、功能划分等。
首先，我们需要确立系统的整体架构。
移动互联网支付系统通常采用分布式架构，能够支持大规模并发访问。
同时，系统还需要具备高可用性、高并发性和可扩展性。
其次，我们需要设计系统的数据库模型。
数据库设计是移动互联网支付系统的核心部分，涉及到用户信息、支付记录、交易详情等数据的存储和管理。
合理的数据库设计能够提高系统的性能和安全性。
最后，我们对系统进行功能划分。
核心功能包括账户管理、支付功能、交易记录查询等。
账户管理模块需要支持用户的注册、登录、绑定银行卡等操作。
支付功能模块需要实现用户的付款、收款、银行卡验证等操作。
交易记录查询模块需要提供用户的交易明细和统计信息。
三、安全性保障移动互联网支付系统的安全性至关重要。
在功能设计与开发的过程中，我们需要采取一系列措施来保障系统的安全。
第三方支付系统总体方案设计
第三方支付系统总体方案设计一、引言随着互联网的快速发展，电子商务成为了人们生活中不可或缺的一部分。
而在电子商务中，支付环节作为核心环节之一，也得到了广泛的关注与发展。
第三方支付系统作为一种安全快捷的支付方式，已经成为了电子商务中不可或缺的组成部分。
二、背景与目标1.背景目前，国内第三方支付系统的市场竞争激烈，用户对于支付安全性、支付速度和支付便捷性的要求越来越高。
因此，设计一个安全可靠、高效便捷的第三方支付系统是非常有必要的。
2.目标本方案的目标是设计一个基于互联网的第三方支付系统，能够满足用户对于支付安全性、支付速度和支付便捷性的要求，并且具备良好的可扩展性和高性能。
三、系统架构设计1.系统组成本系统由支付服务端、支付网关和支付渠道组成。
-支付服务端：负责接收用户的支付请求、生成支付订单、调用相应的支付渠道进行支付处理，并将支付结果返回给支付网关。
-支付网关：负责接收用户的支付请求，对请求进行安全验证和参数校验，并将请求转发给支付服务端。
-支付渠道：包括银行、第三方支付平台等，负责实际的资金结算和支付处理。
2.系统流程支付流程如下：用户发起支付请求->支付网关验证请求->支付网关转发支付请求给支付服务端->支付服务端生成支付订单->支付服务端调用支付渠道进行支付处理->支付服务端接收支付渠道返回的支付结果->支付服务端将支付结果返回给支付网关->支付网关将支付结果返回给用户。
3.安全设计为保障支付系统的安全性，可以采取以下措施：-使用SSL/TLS协议进行通信加密，保护用户的支付数据不被窃取。
-引入数字证书和签名机制，确保支付请求的真实性和合法性。
-设计灵活的权限控制机制，限制不同角色的访问权限，提高系统的安全性。
四、系统功能设计1.用户注册与登录用户可以通过注册账号和填写个人信息来创建支付账户，登录账户后可以进行支付操作。
2.支付订单管理用户可以查看和管理自己的支付订单，包括支付状态、支付金额和支付时间等。
支付系统架构整体设计详解
支付系统架构整体设计详解支付系统架构是指支付系统中各个组件之间的关系和功能划分。
一个好的支付系统架构应该能够满足高并发的需求、具有良好的伸缩性和可扩展性、保证数据的安全性和一致性以及高可靠性。
下面对支付系统架构的整体设计进行详解。
1.模块划分：支付系统可以划分为多个模块，常见的模块有用户管理模块、订单管理模块、支付模块、对接第三方支付平台模块、数据统计模块等。
每个模块负责特定的功能，通过接口进行通信。
2.高并发处理：支付系统通常面临高并发的请求，为了满足性能要求，可以采用分布式架构。
可以将支付模块部署在多台服务器上，并通过负载均衡进行请求的分发，从而提高系统的吞吐量和并发处理能力。
3.数据库设计：支付系统需要存储大量的用户信息、订单信息等，因此数据库设计至关重要。
可以采用分库分表的方式来解决数据量过大的问题，将数据按照一定规则分散到多个数据库或表中，提高数据库的读写性能。
同时，为了保证数据的一致性，可以使用主从复制、集群等技术。
4.第三方支付对接：5.数据安全与保护：支付系统涉及到用户的敏感信息和大量的资金流动，因此数据的安全性至关重要。
可以采用加密算法对用户信息进行加密存储，以及在传输过程中使用SSL等协议保证数据的安全传输。
同时，需要设置安全的访问控制策略，保护系统免受恶意攻击。
6.异步处理：支付系统中涉及到很多异步操作，如异步通知、异步退款等，为了提高系统的吞吐量和响应速度，可以使用消息队列来进行异步处理。
将一些非实时的操作放入消息队列中，通过消费者进行处理，提高系统的并发能力。
7.监控和日志：支付系统需要实时监控系统的运行状态和性能指标，如请求的响应时间、错误率等。
可以使用性能监控工具、日志系统等进行监控。
同时，支付系统需要记录各个操作的日志，方便排查问题和追踪数据。
8.容灾与备份：为了保证支付系统的高可用性和可靠性，需要设置冗余系统，当一个系统出现故障时，可以自动切换到备用系统。
同时需要进行定期的备份和恢复，以防止数据丢失和系统故障。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
支付系统设计：支付系统的账户模型（一）账户体系是支付系统的基础，它的设计直接影响整个系统的特性。
这里探讨如何针对电子商务系统的支付账户体系设计。
我们从一些基本概念开始入手，了解怎么建模。
支付账户和登录账号账户体系设计首先要区分两个概念，支付账户和登录账号。
这是两个不同业务领域的概念：支付账户指用户在支付系统中用于交易的资金所有者权益的凭证；登录账号指用户在系统中的登录的凭证和个人信息。
一个用户可以有多个登录账户，一个登录账户可以有多个支付账户，比如零钱账户，储值卡账户等。
一般来说，支付账户不会在多个登录账户之间共用。
如果没有特殊说明，下文中的账户，都默认指支付账户。
账户的设计需求在支付系统中，账户的设置，主要是从如下几个方面来考虑：1.交易的需求，比如检查账户是否被锁定、余额是否足够、是否有效等。
2.记账的需求，按照公司会计需求记录账户上的所有行为，包括支出、充值、转账等。
3.对账的需求，包括和支付渠道、商户、个人的对账需求，核对交易和账户余额是否正确。
4.风控的需求，如反洗钱、反欺诈等，都需要依赖于账户体系来提供核心数据。
本文暂不分析这个内容，将在《支付风控》、《支付反洗钱》这两篇文章中详细分析5.信用的需求，对用户、资产、商户等主体进行信用评估时，也需要依赖账户体系来提供的核心数据。
本文也暂不分析这内容，将在《信用与支付》一文中分析。
这五个需求，按照其设计的优先级，也是从支付、记账、对账、风控来进行。
支付系统根据其发展所处的阶段，逐步将新增需求纳入设计中。
账户设置，一般是从交易开始的。
交易的实现必须有账户的支持，账户是交易的基本构成元素。
从支付系统的角度，交易中涉及到的资金流是资金从一个账户流向另一个账户。
发起交易的一方，被称之为交易主体，他可以是个人，也可以是一个机构。
资金从该主体所拥有的账户中流出。
而接收交易的一方，被称为交易对手，他也可以是个人，或者机构。
和第三方支付或者金融机构的交易不同，电商系统中，交易还会涉及到渠道。
由于电商系统本身并无清结算的资质，所有资金从交易主体到交易对手的账户的流动，在大部分情况下，并没有经过电商系统，而是由电商系统调用支付渠道提供的接口，由它来完成真正的支付过程。
当然，渠道也不是活雷锋，在这过程中，渠道要收取费用。
所以，在电商系统中，一次交易会涉及到三个账户：交易主体账户、交易对手账户以及支付渠道账户。
如何在这三个账户中完成一次交易，我们将在后续的《交易和记账》一文中详细分析。
记账与账户公司的会计需要对每一笔交易都要做详细的记录，即记账。
公司每天都产生大量的交易行为，为了便于管理和统计，一个简单的方法是对交易进行分类，比如食品、带宽、办公用品等等。
这个分类，按照公司的规模和业务复杂度，可以有一级，二级，三级或者更多级的结构，这被称之为会计科目。
记账时，除了交易明细，还需要在每个级别上对交易额进行汇总。
一般来说，一级科目上汇总称为总帐科目，而详细记录称为明细科目。
在电商系统中，由于涉及到的参与方较多，记账也相对复杂，但基本方法也是类似的。
电商的参与者可以分为商户、买家和渠道，对这三类参与者，都需要分别建立总帐账户和明细账户。
当用户使用银行卡来支付时，电商支付系统需要和银行对接，从用户银行卡所代表的账户上扣除资金。
对接了银行，第三方支付等机构的电商支付系统，它需要连接到用户在这些机构的账户来执行扣款或者充值操作，这些账户或称为外部账户。
对外部账户，支付系统只能记录账户在本系统的明细以及累计消费额，无法得知账户真正余额。
不少电商在玩零钱的概念，也就是让用户充值到零钱，使用的时候就直接从零钱中扣除。
这就需要零钱账号。
这是电商系统中自己设立的账号，所以也叫内部账号，可以知道账号的全部消费明细和余额。
当然，除了零钱账号，也可以有储值卡账号，信用账号等。
那问题来了，什么时候需要建立账户，比如优惠券，需要账户吗？一次消费的储值卡和可以充值的储值卡，需要建立账户吗？这里先埋个雷，后续介绍支付和记账时，给出答案。
当电商要对接银行时，往往都会被要求开设一个收款账户。
用户通过这个银行来支付时，钱就被转到这个账户上。
对第三方支付也是一样。
收款账户是开设在银行或者第三方支付这边的，即渠道侧。
一般来说，渠道每天都可以提供这个账户的交易流水供电商对账用。
这样在电商这边，渠道就成为一个收单机构。
所以在电商这边，建立这个收款账户对应的对账用的收单账号，用来记录通过这个渠道进行的各项交易流水。
账户建模说了这么多，目的是为了对账户建模。
账户模型是和公司业务密切相关的，公司不同规模，发展的不同阶段需要不同的模型。
账户建模本身包括三大核心模型：实体模型、账户模型和交易模型。
从交易模型中可以衍生出针对各个角色的账户流水，即明细模型，用于支持对账。
实体模型和用户、商户模型有重叠的地方，这里专门针对支付而设置的各个实体属性。
一般来说，支付相关的实体模型需要包括如下的属性：∙用户ID，一般直接映射到登录账户的ID；∙是否允许执行支付；∙支付密码；∙用于设置或者重置支付密码的手机号；∙用户设置或者重置支付密码的邮箱；∙用户的安全等级，根据业务需要来设置。
根据业务需要，可以设置多种账户，如支付账户、预付卡账户、代扣账户、零钱账户、结算账户等。
从类别上来说，这里的账户，一般指总账账户。
一般来说电商系统中涉及的账户类型有：∙虚拟币账号：用户和使用奇点奇豆的商户都需要建立虚拟币账户。
∙代扣账号：用来支持订阅类型的定期代扣；∙零钱账号：即电商的内部账号，用户、商户、清算单位需要建立零钱账户∙第三方支付账号：用户在第三方支付机构建立的账户。
∙银行卡账号：用户的银行卡信息，每个卡对应一个账户。
∙结算账号：用来支持和第三方支付公司、银行进行结算用。
第三方支付需要为每个商户号建立结算账号；银行需要为借记卡、贷记卡分别建立结算账号（有必要吗？银行卡直连时使用）。
∙代扣代缴账户：用来支持代扣税款业务。
对这些账户，需要设置如下属性：基本属性，包括：∙账户号，或称为账户ID，一般是系统自动生成。
特别注意的是，要事先约定好账户ID的规则。
比如头三位用来表示账户类型，后几位用来表示账户编号等。
务必保证根据账号号能够快速确定账户类型，并且保证账户号是不重复的。
∙账户名称，一般是由用户自己设置的，显示用。
∙账户使用的货币类型，注意虽然一张银行卡可以支持多个币种，实际在内部，还是针对每个币种建立独立的子账户。
涉及到多币种的账户，也可以采用类似的建模方案。
∙会计科目代码，一般是一级会计科目的代码。
账户控制相关：∙是否允许充值；∙是否允许提现；∙是否允许透支；∙是否允许支付；∙是否允许转账进入；∙是否允许转账转出；∙是否有安全保障；∙是否激活；∙是否冻结。
资金相关：∙当前账户余额：等于可用余额+冻结余额；∙当前账户可用余额；∙当前账户冻结的余额。
冻结余额指在账户上暂不能使用的额度。
在支付的时候，往往是先冻结，商品出库后，再实际执行扣款。
银行卡、第三方支付信息：∙第三方实体的ID；∙第三方账号，如银行卡号或者在第三方支付的open_id等；∙第三方的app_id；∙账号的失效日期，该账号什么时候失效。
注意，有些第三方信息是不能保存的，如用户的账号密码、信用卡的CV号等。
为了避免账户信息被爬库或者数据库信息意外泄露，一般还需要对敏感字段，如密码等，进行加密保存，甚至保存到另外的表中。
更进一步，为了避免账户信息被意外修改，还可以增加一个校验字段，在写入数据时设置该字段，在读取数据时做校验，一旦发现数据有问题，则关闭该账号。
交易记录，交易流水，账户流水，交易台账，这三个容易混淆的概念，从数据上来说，却并不复杂，它们的核心是交易流水，账户流水是从账户视角的交易流水。
那对一笔交易，涉及到的方方面面内容很多，有哪些需要记录的呢？考虑到交易记录将被用于风控和信用分析，能收集到的信息是越全面越好。
∙流水号：每一笔交易的流水号都不一样。
需要根据业务情况详细设计流水号。
这个号往往也是对交易表做分表分库的依据。
∙交易记录创建时间；∙交易记录最后修改时间；∙会计科目代码∙关联的订单号，由商户提供；∙订单名称、描述、关联的地址等信息；∙费用信息，包括：结算货币类型、原始费用、实际费用等；∙交易主体信息，记录主体ID、类型、名字、账号、账号类型、使用的IP地址、手机号、平台、通知邮箱、当前位置等。
这些信息虽然可以从主体表中获取，但考虑主体表信息随时会被修改，所以这里需要记录详细的各原始信息。
∙交易对手信息，记录对手主体的ID，类型，名字，账号，账号类型，手机号，平台，通知邮箱等。
∙交易渠道信息，记录所使用的交易渠道的实体id，渠道账户，渠道执行支付的时间、渠道侧返回的订单号等。
如果有错误发生，还需要记录从渠道接收到的错误信息和错误码。
总结如上内容，不管是账户还是交易，模型都很复杂。
是否有必要记录这么多信息，如何在交易中使用这些模型，请关注后续文章。
作者：凤凰牌老熊，程序员&架构师，来自中科大的本科，研究生在软件所学习。
先后在中科辅龙、三星（中国）研究院和国内一些大型的互联网公司呆过。
在中科辅龙公司负责电子政务内容管理系统建设，负责研发龙驭系列产品的研发，这款产品最终实施到2000多个电子政务网站上，期间也参与了一些支付反洗钱以及支付系统的建设。
之后在三星中国研究院，负责自然语言处理（NLP）以及智能家居相关项目。
智能家居项目在2014CES消费电子展上作为三星重点项目推介。
2014年开始加入爱奇艺公司，负责数据仓库和支付系统的建设。