除了从事账务系统研发的工程师外，大部分支付研发工程师对账务都了解甚少，主要原因仍然是账务系统的业务门槛往往大于技术门槛，比如很多支付研发工程师甚至不了解复式记账。所以有必要从研发工程师的角度来介绍一些账务系统入门的知识。需要说明的是，不同支付公司内部设计的账务系统必然存在差异，但有些基本原则大家都会遵守，比如复式记账、账户管理、记账、对账、会计中心、日切等。

本文描述的概念大部分做了极致简化，只是用于入门，对于理解概念应该是够用的。真实的实现会复杂非常多。这些概念如同支付核心系统拼图的一些小碎片，串起这些小碎片，就是一个完整的支付系统大图。另：后面的描述中，经常混着用“支付系统”、“支付平台”，“支付机构”，“收单机构”，本质是一个东西。在内部来说，就是一个支付系统，但从和外部机构交互来说，就是一个支付平台。对用户来说是支付，对商户来说就是帮商户收单。

本文主要讲清楚支付系统中拒付涉及的基本概念，产品架构、系统架构，以及一些核心的流程和相关领域模型、状态机设计等。拒付在中国比较少见，但是在海外非常普遍，只要做跨境收单支付系统，就无法绕开拒付。拒付涉及到冻结收单单据，并扣减商户的结算款，所以拒付经常和收单、结算一起讲。下面这个图第三次出现，只是想强调三者之间的紧密关系。

本文主要讲清楚支付系统中商户结算涉及的基本概念，产品架构、系统架构，以及一些核心的流程和相关领域模型、状态机设计等。收单结算是支付系统最重要的子域之一，行业内经常把有牌照的支付平台称为“收单机构”就可见一斑。我们在上一篇文章讲了收单如何帮忙商户收钱，收完钱还得转给商户，用户支付100块钱，那么到底给商户多少钱，什么时候给，这都是结算平台干的工作。谓之“结算”

收单结算是支付系统最重要的子域之一，行业内经常把有牌照的支付平台称为“收单机构”就可见一斑。有些监管严格的国家地区，没有收单牌照就不能碰收单和结算，商户必须入驻到有收单牌照的支付机构。本文主要讲清楚支付系统中收单涉及的基本概念，产品架构、系统架构，以及一些核心的流程和相关领域模型、状态机设计。

支付系统无论需求文档还是技术方案文档，都充斥着专业词汇和行业通用词语，这些术语有的直观易懂，有的则晦涩难解。在这篇文章中，我将揭开支付系统中常用术语的神秘面纱，用最通俗的语言解释这些专业词汇。需要说明的是：这些术语是我个人从业10来年经验的总结，多用于聊需求或设计时使用，严谨性可能不及一些权威书籍，但是足够实用，起码在中国绝大部分的支付大厂是通用的。此外，一些术语在不同的领域有不同含义，下面的定义只适用在线支付系统场景下。

下面描述的概念大部分做了极致简化，只是用于入门，对于理解概念应该是够用的。真实的实现会复杂非常多，后面的系列文章会展开做详细说明。后面的描述中，经常混着用“支付系统”、“支付平台”，本质是一个东西。在内部来说，就是一个支付系统，但从和外部机构交互来说，就是一个支付平台。

给站点图片来个升级，因为站点图片大量使用PNG格式图片，PNG格式文件较大，对网站加载有一定影响。 搜索发现了一个好玩儿工具。 WebP-Server工具，可将您的 JPG/PNG (有损压缩与无损压缩以及常用图片格式) 即时压缩为 WebP 格式，非常高效可以大幅度的减少图片体积，减少出口带宽，提高用户体验。目前支持的图片格式：JPEG、PNG、BMP、GIF（暂时为静态图片。

回顾 JavaScript 的发展历程，从最初的简单浏览器脚本语言，到如今构建互联网应用程序的现代编程语言，模块化技术在这一演变中发挥了关键作用。本篇文章将从 JavaScript 的模块化探索及模块化规范的持续演进两部分，回顾 JavaScript 模块化的演进历程。

在Go语言的丰富特性中，反射（reflection）以其独特的能力脱颖而出，它允许程序在运行时检查和修改变量的类型和值。这种动态特性为编写灵活、适应性强的代码提供了广阔的可能性。本文将深入剖析Go中的反射机制，从基础概念到实际应用，逐步揭示反射的强大功能及其在实际编程中的使用技巧和注意事项。