2024年网页支付详细设计(共8篇)

网页支付详细设计 第1篇

我们需要来一个订单表，订单详情表，以及订单的自动化序列表

--订单表

create table orders(

ordernum varchar(100) primary key,

price float(8,2),

number int,

status int,   --支付成功状态位会改变

customerId VARCHAR(100),

CONSTRAINT customerId_fk FOREIGN KEY (customerId) REFERENCES customers(id) 

)

)

--订单详情表

create table orderitems(

id varchar(100) primary key,

number int,

price float(8,2),

ordernum varchar(100),

bookid varchar(100),

CONSTRAINT ordernum_fk FOREIGN KEY (ordernum) REFERENCES orders(ordernum),

CONSTRAINT bookid_fk FOREIGN KEY (bookid) REFERENCES books(id)   

)

--订单编号表

create table ordernum(

prefix date,

num int

)

网页支付详细设计 第2篇

跳过几个支付公司，这些基础的概念在几家公司都差不太多，区别是底层技术实现。比如RPC框架，数据库，业务流程，部署架构等。

说明：

说明：

主要对接商户，比如下单、支付等接口入口。通常要求有比较高的安全性。部分公司可能会把移动端网关、PC门户网关、商户通知等能力集成在开放网关，也可能会单独拆出部署。

负责把商户的单收下来，并给商户发起结算。承担的收单产品包括有：线上收单，线下收单，担保交易、即时到账等，每个公司的商业策略不同，开出的收单产品会有差异。

有些公司把结算划到出款中心，对接银企直连的渠道。

承担无买卖标的的纯资金转移能力。典型的有：充值、转账、提现、代发。和支付的区分在于支付是有买卖标的，而资金产品没有。也就是在系统中没有买卖记录发生，但在线下可能有。

资金产品一般需要独立的牌照。

渲染可用支付方式。包括查询账户是否有余额，查询营销是否有营销券，查询渠道网关是否有可用的外部渠道，最后组合成可用支付方式，供前端渲染。

收银核心就像一个大内总管，收到请求后，找商户平台核实身份，找合约平台核实权限，找会员平台核实用户身份，找收单看一下这笔单是否可以继续支付，找账务中心获取余额信息，营销看看有没有可用的券，找渠道网关看看没有可用的渠道，找额度中心看看是否超限额了，找风控问一下当前支付是否安全，找会员平台校验支付密码 … …

负责真正的扣款或转账。有些公司叫支付核心。

如果是余额就调账务扣减余额，如果是红包就调营销做核销，如果是外部银行通道就调渠道网关。

负责去外部渠道扣款。通常还会提供渠道路由、渠道咨询等能力，做得细的公司可能会把渠道核心和报文/文件网关单独拆出来。其中渠道核心就提供渠道路由、渠道咨询、渠道开关等服务，报文/文件网关负责报文转换、签名验签等。

管理会员的生命周期，比如注册、注销、登录等。同时还提供核身服务（比如登录密码，支付密码，短信验证码等）、实名认证服务等。

管理商户的入驻签约、KYB、交易管理等。

管理对外提供的产品能力，比如快捷支付，代扣等。一般大的支付系统才会独立成一个子系统。

负责账户开立，记账等。

会计科目管理、分录管理、日切管理等。

监管报表有时候也放在这里，有些公司也会独立出去。

很多集团公司往往有一套独立的专业财务系统，这个时候往往需要会计中心做完日切后，要把记账信息合并到集团公司的财务系统中去，简称并账。

负责明细对账和资金对账。

提供满减、红包等营销工具。

针对账户和交易，提供实时、离线风控，控制交易的风险。反_、反欺诈是基本要求。

通常各公司对风控规则看成是机密，研发也可能看不到运营配置的规则。经常看到有网友问：“有xx公司的人在吗？我有xxx场景下的支付总是提示风控不过，是否知道是什么原因，怎么才能通过？”，完全是浪费口舌，谁会对外公布自己的风控规则，让人去钻空子呢？

订单管理、渠道管理、产品管理等综合运营工具。

主要用于数据汇总和分析。当前各支付公司基本都是分布式部署N多个应用，数据都在散落在各子系统中，需要汇总到数据平台用于经营分析。

负责管理用户的绑卡信息。需要经过PCI认证。

累计用户、商户的额度，通常有日、月、年，单卡等各种分类。

负责外汇报价和兑换。

一些跨境支付公司，在多个国家多个银行有头寸，各头寸之间经常需要做流动性管理，提高资金利用率。

毕竟在国外不需要把备付金强制存到央行还不给利息。当资金量大的时候，这笔收益可不少。

负责差错处理。比如渠道退款失败（银行账号销户，过了银行的退款有效期等），需要通过其它的方式退给用户。

处理用户的拒付和举证。在跨境支付场景下，信用卡用户联系发卡行说卡被盗刷或商品没有收到，或商品有问题等，拒绝支付给商户。

国内基本没有看到拒付场景。

网页支付详细设计 第3篇

设计订单的实体类

public interface OrderDao {

void save(Order order);

Order findByNum(String ordernum);

void update(Order order);

//订单号降序排序

List findByCustomerId(String customerId);

List findOrderItem(String ordernum);

}

接口的实现

public class OrderDaoImpl implements OrderDao {

private QueryRunner qr=new QueryRunner(());

//保存订单

@Override

public void save(Order order) {

try {

(_insert into orders (ordernum,price,number,status,customerId) values (?,?,?,?,?)_,

(),(),(),(),

()==null?null:().getId());

List items = ();

for(OrderItem item:items){

(_insert into orderitems (id,number,price,ordernum,bookid) values (?,?,?,?,?)_,

(),(),(),(),()==null?null:().getId());

}

} catch (SQLException e) {

throw new RuntimeException(e);

}

}

public Order findByNum(String ordernum) {

try {

Order order = (_select * from orders where ordernum=?_, new BeanHandler(Order.class), ordernum);

if(order!=null){

Customer customer = (_select * from customers where id=(select customerId from orders where ordernum=?)_, new BeanHandler(Customer.class), ordernum);

(customer);

}

return order;

} catch (SQLException e) {

throw new RuntimeException(e);

}

}

public void update(Order order) {

try {

(_update orders set price=?,number=?,status=? where ordernum=?_, (),(),(),());

} catch (SQLException e) {

throw new RuntimeException(e);

}

}

@Override

public List findByCustomerId(String customerId) {

try {

List orders=(_select * from orders where customerId=?  order by ordernum desc _, new BeanListHandler(Order.class),customerId);

if(orders!=null){

Customer customer=(_select * from customers where id=? _,new BeanHandler(Customer.class),customerId);

for (Order order : orders) {

(customer);

}

}

return orders;

} catch (SQLException e) {

throw new RuntimeException(e);

}

}

@Override

public List findOrderItem(String ordernum) {

try {

List items = (_select * from orderitems where ordernum=?_, new BeanListHandler(OrderItem.class), ordernum);

if(items!=null){

for(OrderItem o:items){

Book book = (_select * from books where id=(select bookId from orderitems where id=?)_, new BeanHandler(Book.class), ());

(book);

}

}

return items;

} catch (SQLException e) {

throw new RuntimeException(e);

}

}

}

网页支付详细设计 第4篇

一般来说，技术风险主要包含稳定性和资损两个方面。其中稳定性风险就是大家经常说的几个9，比如可用，就是5个9。资损风险就是平台或用户的资金损失。

虽然资损也是技术风险的一种，但是因为对于专业的持牌支付公司来，资损是一种非常严重的事故，容易引发客诉、网络事件、甚至监管介入，所以又较一般的风险更为严重，常常把资损防控单独拿出来说。

技术风险体系过于庞大，这里只谈几点通用知识。

识别风险来自哪里

我们通常先需要知道风险来自哪里，才知道如何去防控。而风险往往来自变化。举几个例子，抛砖引玉：

应对风险

根据变化去应对风险。比如大促引入了流量变化，那就做压测、扩容、限流、降级非核心业务等应对。比如原来只有支付，这些有了用户提现，针对用户提现，内部多个子域可能状态/金额不一致，和银行渠道的状态/金额也可能不一致，那就加入各种对账手段，以及对应的应急预案。

内部系统实时与离线对账

对账是资损防控中最效的手段之一。

前面讲过的三层对账主要是和银行渠道对账，除了这个之外，一般的支付平台还会有内部系统之间的两两核对，这种核对主要是信息流层面的核对，主要核对状态、金额的一致性。

说明：

幂等是针对重复请求的，支付系统一般会面临以下几个重复请求的场景：

幂等解决方案

所谓业务幂等，就是由各域自己把唯一性的交易ID作为数据库唯一索引，这样可以保证不会重复处理。

在数据库前面可以加一层缓存来提高性能，但是缓存只用于查询，查到数据认为就返回幂等成功，但是但不到，需要尝试插入数据库，插入成功后再刷新数据到缓存。

为什么要使用数据库的唯一索引做为兜底，是因为缓存是可能失效的。

在面临时经常有同学只回答到“使用redis分布式锁来实现幂等”，这是不对的。因为缓存有可能失效，分布式锁只是用于防并发操作的一种手段，无法根本性解决幂等问题，幂等一定是依赖数据库的唯一索引解决。

大部分简单的支付系统只要有业务幂等基本也够用了。

当数据量大的时间，分库分表是再所难免的。一个经典的面试题是：如果分了100张表，按商户来分表，还是按商户订单号来分表？如果按商户分表怎么解决各表流水数据量平衡问题？如果是按商户订单号来分表，商户想按时间段查询怎么办？

解法有很多种。一种典型的解法，就是线上数据库按商户订单号分表，同时有一个离线库冗余一份按商户号分表的数据，甚至直接使用离线数据平台的能力，把商户的按时间段查询需求从在线库剥离出来。

分布式事务是个好东西，但是复杂度也高，还经常出现所谓的事务悬挂问题，且虽然各家都号称简单易用，对业务代码侵入少，但事实并非如此。

所以我个人更倾向于避免使用分布式事务解决方案，而是采用最终一致性来解决。对大部分中小公司来说，最终一致性已经够用。

对于研发经验不足的团队而言，经常会犯以下几种错误：

带来的后果，通常就是资金损失，再细化一下，最常见的情况有下面3种：

最佳实践：

数据库一般都会设计一个自增ID作为主键，同时还会设计一个能唯一标识一笔业务的ID，这就是所谓的业务ID（也称业务键）。比如收单域的收单单号。

也有人采用所谓雪花算法，但其实不适用于支付场景。

下面以32位的支付系统业务ID生成为例说明。实际应用时可灵活调整。

第1-8位：日期。通过单号一眼能看出是哪天的交易。

第9位：数据版本。用于单据号的升级。

第10位：系统版本。用于内部系统版本升级，尤其是不兼容升级的时候，老业务使用老的系统处理，新业务使用新系统处理。

第11-13位：系统标识码。支付系统内部每个域分配一段，由各域自行再分配给内部系统。比如010是收单核心，012是结算核心。

第14-15位：业务标识位。由各域内部定，比如00-15代表支付类业务，01支付，02预授权，03请款等。

第16-17位：机房位。用于全球化部署。

第18-19位：用户分库位。支持百库。

第20-21位：用户分表位。支持百表。

第22位：预发生产标识位。比如0代表预发环境，1代表生产环境。

第23-24位：预留。各域根据实际情况扩展使用。

第24-32位：序列号空间。一亿规模，循环使用。一个机房一天一亿笔是很大的规模了。如果不够用，可以扩展到第24位，到十亿规模。

状态机，也称为有限状态机（FSM, Finite State Machine），是一种行为模型，由一组定义良好的状态、状态之间的转换规则和一个初始状态组成。它根据当前的状态和输入的事件，从一个状态转移到另一个状态。

下图就是收单子域设计中交易单的状态机设计。

从图中可以看到，一共4个状态，每个状态之间的转换由指定的事件触发。

常见代码实现误区

经常看到工作几年的同事实现状态机时，仍然使用if else或switch case来写。这是不对的，会让实现变得复杂，且容易出现问题。

甚至直接在订单的领域模型里面使用String来定义，而不是把状态模式封装单独的类。

还有就是直接调用领域模型更新状态，而不是通过事件来驱动。

限于篇幅，这里就不给正确的示例了。有兴趣的可以去网上看看，良好的示例有很多。

只要在公司写过代码，就一定打印过日志，但经常发现一些工作多年的工程师打印的日志也是乱七八糟的。我曾经在一家头部互联网公司接手过一个上线一年多的业务，相关日志一开始就没有设计好，导致很多监控无法实现，出了线上问题也不知道，最后只能安排工程师返工改造相关的日志。

我们要明白日志是用来做什么的。只是先弄明白做事的目的，我们才能更好把事情做对。在我看来，日志有两个核心的作用：1）监控，诊断系统或业务是否存在问题；2）排查问题。

对于监控而言，我们需要知道几个核心的数据：业务/接口的请求量、成功量、成功率、耗时，系统返回码、业务返回码，异常信息等。对于排查问题而言，我们需要有出入参、中间处理数据的上下文、报错的上下文等。

接下来，基于上面的分析，我们就清楚我们应该有几种日志：

支付安全核心关注点

支付安全是一个很大的范畴，但我们一般只需要重点关注以下几个核心点就够：

1）敏感信息安全存储。

对个人和商户/渠道的敏感信息进行安全存储。

个人敏感信息包括身份证信息、支付卡明文数据和密码等，而商户/渠道的敏感信息则涉及商户登录/操作密码、渠道证书密钥等。

2）交易信息安全传输。

确保客户端与支付系统服务器之间、商户系统与支付系统之间、支付系统内部服务器与服务器之间、支付系统与银行之间的数据传输安全。这包括采用加密技术等措施来保障数据传输过程中的安全性。

3）交易信息的防篡改与防抵赖。

确保交易信息的完整性和真实性，防止交易信息被篡改或者被抵赖。一笔典型的交易，通常涉及到用户、商户、支付机构、银行四方，确保各方发出的信息没有被篡改也无法被抵赖。

4）欺诈交易防范。

识别并防止欺诈交易，包括套现、_等违规操作，以及通过识别用户信息泄露和可疑交易来保护用户资产的安全。这一方面通常由支付风控系统负责。

5）服务可用性。

防范DDoS攻击，确保支付系统的稳定运行和服务可用性。通过部署防火墙、入侵检测系统等技术手段，及时发现并应对可能的DDoS攻击，保障支付服务的正常进行。

极简支付安全大图

支付安全是一个综合性的系统工程，除了技术手段外，还需要建立健全的安全制度和合规制度，而后两者通常被大部分人所忽略。

下图是一个极简版的支付安全大图，包含了支付安全需要考虑的核心要点。

说明：

1）制度是基础。

哪种场景下需要加密存储，加密需要使用什么算法，密钥长度最少需要多少位，哪些场景下需要做签名验签，这些都是制度就明确了的。制度通常分为行业制度和内部安全制度。行业制度通常是国家层面制定的法律法规，比如《网络安全法》、《支付业务管理办法》等。内部安全制度通常是公司根据自身的业务和能力建立的制度，小公司可能就没有。

2）技术手段主要围绕四个目标：

对应的技术手段有：

网页支付详细设计 第5篇

所谓提纲挈领，就是先掌握核心主干，有了这个前提，再去深入了解细节，才不至于“乱花渐欲迷人眼”，解决问题时才能如庖丁解牛，行云流水。伟人邓公提倡的“抓住主要矛盾”，也是这个道理。

本文主要讲了一些支付核心系统相关的基本概念，希望能为大家在学习在线支付系统相关知识时能提供一些有益的参考。

犹记得N年前那天早上，我穿上最帅的衬衣、笔挺的西装裤、贼亮的皮鞋，推开房门，清风徐来，朝阳灿烂，一如我的心情，意气风发。那是我进入正值蓬勃发展的第三方支付行业的第一天。

入职当天老板扔了很多文档给我，看了一周，没看懂。想起老祖宗说的“读书百遍，其义自见”，继续苦读一周，仍然是雾里看花。不幸中的万幸，是挺过了试用期。直到多年后的一天，整理老旧硬盘的资料，才发现一方面是自己愚钝，另一方面也是那些资料写得过于晦涩难懂。于是萌发一个念头：要不我自己也总结总结？这是其中的一篇。

斗转星移，外面的阳光依然灿烂，衬衣、西装裤、皮鞋却已不知何处去了。

题图来自Unsplash，基于CC0协议

网页支付详细设计 第6篇

所谓产品架构图，简单的理解，就是站在产品角度，提供什么样的服务能力。下面是一个典型的支付系统的产品架构图。实际实现时差异会很大，尤其是上面的产品或应用层，有很多机构为特殊的行业提供一些特殊的能力，比如携程的支付就会有航空方面的B2B业务。但基础的能力基本也就这些。

说明：

网页支付详细设计 第7篇

看一下十年前各大互联网公司支付系统架构图，就会发现最基础的偏底层的那部分到现在也很有参考价值，但是性能、可用性、基础架构等已经发生了天翻地覆的变化。

比如根据公开资料，2019 年双11 支付宝的支付峰值为 万笔/秒，真实承载能力应该远高于此。创新的业务也发生了极大的变化，比如京东白条的横空出世，在海外旅游可以直接用支付宝或微信扫码付款等。

某团的：

某Q旅游的：

某东金融的：

某蚁金服的：

网页支付详细设计 第8篇

//生成订单

void genOrder(Order order);

//根据订单号查找订单

Order findOrderByNum(String ordernum);

//更新订单信息

void updateOrder(Order order);

//更新订单状态

void changeOrderStatus(int status,String ordernum);

//

List findOrdersByCustomerId(String customerId);

List findOrderItemByCustomerId(String ordernum);

实现其接口

//生成订单

@Override

public void genOrder(Order order) {

if(order==null)

throw new RuntimeException(_订单不能为空_);

if(()==null)

throw new RuntimeException(_订单的客户不能为空_);

(order);

}

@Override

public Order findOrderByNum(String ordernum) {

return (ordernum);

}

@Override

public void updateOrder(Order order) {

(order);

}

@Override

public void changeOrderStatus(int status, String ordernum) {

Order order=findOrderByNum(ordernum);

(status);

updateOrder(order);

}

@Override

public List findOrdersByCustomerId(String customerId) {

return (customerId);

}

@Override

public List findOrderItemByCustomerId(String ordernum) {

return (ordernum);

}

生成订单

//订单详情

private void showOrders(HttpServletRequest request,

HttpServletResponse response) throws IOException, ServletException {

//检测是否登录；

HttpSession session=();

Customer customer=(Customer) (_customer_);

if(customer==null){

().write(_请先登录_);

(_Refresh_, _2;URL=_+());

return ;

}

List  orders=(());

(_orders_, orders);

(_/_).forward(request, response);

}

//生成订单

private void genOrder(HttpServletRequest request,

HttpServletResponse response) throws IOException, ServletException  {

//检测是否登录；

HttpSession session=();

Customer customer=(Customer) (_customer_);

if(customer==null){

().write(_请先登录_);

(_Refresh_, _2;URL=_+());

return ;

}

Cart cart=(Cart) ().getAttribute(_cart_);

Order order=new Order();

(());

(());

(());

(customer);

List  oItems=new ArrayList();

//设置订单项

for(__>  me:().entrySet()){

OrderItem item=new OrderItem();

(().toString());

(().getNumber());

(().getPrice());

(().getBook());

(item);

}

//建立和订单的关系

(oItems);

(order);

(_order_, order);

(_/_).forward(request, response);

}

接下来就是支付功能的实现了。我们要为上面生成的订单来支付。