当前位置: 首页 > backend >正文

支付域——支付与交易概念

摘要

本文详细阐述了支付域中支付与交易的核心概念及其相互关系。交易是商品或服务交换的过程,包含多个要素并产生订单或合同。支付则是资金流转的过程,是交易的资金结算环节。支付交易结合了两者,根据不同场景提供多样化的支付产品和服务。文中还探讨了支付过程、支付资金、支付场景、支付产品等多个方面,并分析了支付与交易在不同维度上的关联,强调了支付信息流中信息流、支付流和资金流的重要性。

1. 交易基本概念

1.1. 交易定义

交易是个非常庞大的概念,几乎涵盖了人类经济贸易中所有买卖和交换行为。因此为了便于理解我们这里讨论的交易是“支付交易”,支付交易通俗的理解就是完成交易双方买卖和资金转移。交易强调的是商品/服务交换关系的确立其中交易的核心点

  • 对象:商品/服务
  • 要素:买方、卖方、交易标的、交易金额、数量、交付方式
  • 结果:形成一笔订单或合同

支付交易在其中起到了承上启下的“调度者”的作用。他向上服务于各行各业,为各种支付场景提供综合性的交易服务;向下它调度支付产品的收款、付款、转账等支付指令,让资金按照业务的要求进行有效的流动。所以我们经常说的支付产品实际是交易产品,因为只有经过交易化的包装支付产品才会更加的安全和好用。

支付是与交易相伴而生的,在我们看到收银台、支付产品之前需要通过交易的调度才呈现出来的。可能有人会说平时用网上消费、POS机消费、商家收银台上我还没有下单支付就能看到收银台呀。其实这些在支付中属于终端页面和交易的前导页面,

从“支付和交易关系”的逻辑图中我们可以看到,支付负责资金流动和转移,支付交易可以根据不同的场景去提供产品的不同包装形态。比如面向电商、社交、门店类收款场景我们可以把收单和分账包装在一起形成“分账交易”;对于企业大额支付场景,我们可以把网银支付、银企直联、虚拟账户包装在一起形成“企业支付产品”;对于消费金融场景,我们可以把快捷支付、转账汇款产品包装在一起成为“消金支付产品”。我们所见到的一些行业性解决方案的支付产品本质上是“交易产品”

1.2. 交易场景

一般是站在金融、支付、互联网电商等业务角度,来描述“交易”在不同场景下的表现。

  1. 资金流向不同:有的是从用户到商户(消费),有的是用户之间(转账),有的是平台到用户(提现/退款)。
  2. 参与方不同:可能是用户到商户,也可能是用户到平台,或者多方(跨境交易涉及清算机构)。
  3. 时效性不同:消费交易实时性强;理财、跨境交易可能存在清算周期。
  4. 风险差异:交易场景不同,对风控要求也不同,比如跨境交易、分期付款、虚拟商品交易风险更高。

场景类别

场景说明

典型例子

消费交易

用户在商户/电商平台购买商品或服务

淘宝买衣服、美团点外卖、京东买手机

转账交易

用户之间资金转移

微信转账、支付宝转账、银行手机银行转账

充值交易

向账户/钱包/卡片注入资金

手机充值话费、往余额宝转钱、往游戏账户充值

提现交易

从账户/钱包/卡片取出资金

提现到银行卡、微信零钱提现

还款交易

清偿债务,尤其是信贷类

信用卡还款、花呗还款、消费贷还款

投资理财交易

资金进入理财产品或投资标的

购买基金、购买银行理财、证券交易买卖

保险交易

投保、续费或理赔相关资金流

购买健康险、缴纳车险、保险理赔到账

跨境交易

涉及外币结算、国际支付

亚马逊跨境电商购物、PayPal 跨境支付

缴费交易

用户对公共事业类费用支付

水电煤缴费、学费缴纳、罚款缴纳

特殊场景交易

结合行业定制化的交易

拼团购、分期付款、会员充值、保证金冻结与解冻

网上购物消费可能是我们平时接触的最多的支付场景了,在顺畅的购物体验过程中让你很难区分哪些是交易、哪些是支付。这就是交易的功劳,通过不同场景的良好适配为你提供丝滑的支付体验。

从上图中我们可以看到“支付交易”在电商平台和支付平台之间贯穿始终通过对支付产品的调度来适配各种不同场景。

1.2.1. 消费流程

从你选购一件商品开始下单后,交易引导你完成支付或撤销,把你的支付结果推送给电商平台,电商平台进行派单、发货、送货将商品配送到你的手中。

1.2.2. 售后流程

如果你对商品不满意,在电商平台发起售后退货,支付交易匹配订单给你完成退款。

1.2.3. 履约结算

当商家履约完成没有退款之后,电商平台将商品、交易单、支付单进行核对,按照服务协给商家生成账单后完成资金的结算。

1.2.4. 交易订单匹配

从上图我们可以看到支付系统提供的订单在电商平台交易中起到了承上启下的重要作用。支付系统提供的“支付订单”串联了商品、仓储、物流订单;支付系统提供的“资金订单”则为电商平台收款方的履约结算提供了结算最为关键的资金和余额数据。从这里的分析我们可以体会到,为什么会有那么多大厂对支付牌照趋之若鹜,要“构建平台模式”实现“线上化交易”、“跨银行交易结算”支付交易是一个平台的核心能力。

1.3. 支付交易功能

1.3.1. 支付交易

这类交易产品是最常见的交易产品,我们接入微信、支付宝、云闪付等平台的支付产品普遍用的都是这类交易产品。

1.3.2. 分账交易

分账主要服务于电商场景,因为在电商平台上有商家、经销商、供应商、物流配送、代理商等角色,因此收款后需要给多个收款方进行分润。同时通过持牌机构的清分可以规避二清的合规风险;另一方面在收款、开票上资金、回单、发票关系也更加清晰。这类产品主要包装的B2C支付产品,包括扫码支付、小程序支付、公众号支付、POS刷卡、快捷支付、B2C网银等支付产品。

1.3.3. 企业交易

这类产品又叫“B2B支付”主要应用于企业场景,因为他主要是解决两家B端企业之间的应收账款的票款同步问题。这种场景下除了“B2B支付”解决上下游支付需求以外;也不能完全把C端排除在外,因此他也应该兼容“C2B2B”的交易模式。这类产品主要包装“银企直联”、“虚拟账户”等企业端支付产品,完成企业间应收账款的线上下单,线下付款,订单核销的交易需求。

1.3.4. 消金交易

这类产品面向个人用户的信贷产品使用居多,主要应用在银行、消费金融、网络小贷、金融助贷平台的支付场景中。提供小额信用贷款、现金贷款中借款人、出借人之间的账户充值、提现;用信放款、债权还款;以及出借人与资金方、担保方之间费用结算。这类产品主要包装“快捷支付”、“钱包账户”产品;因为要对借款人的身份进行实名认证,并且对借款人的信用、资质进行背景调查。

2. 支付基本概念

2.1. 支付定义

官方定义就是“付款人和收款人之间的资金的流转,以及应收应付债权的核销”。简单来说支付是交易完成后,买方向卖方转移资金的过程。它是交易的资金结算环节。支付强调的是资金如何转移、清算、结算。其中支付的核心点

  • 对象:资金流转
  • 要素:付款方、收款方、资金渠道、支付方式
  • 结果:完成货币转移、清算和结算

我们所说的支付包含了交易、清分、结算三个过程,其目的就是实现付款方与收款方之间的资金和债权债务(应收/应付)的转移。从图中我们可以看到这个三个过程是以“套娃”的形式来实现的,当付款方将一个支付请求发给银行或支付机构后,后面交易、清分、结算就开始层层传递,最终实现资金的转移并通知收款人资金到账。

2.2. 支付过程

2.2.1. 交易记账过程

交易过程我们之前已经介绍过,他是支付和结算的调度者,他根据支付请求去调度支付流程、账务处理,为资金转移登记可供结算的订单和账务结果。

2.2.2. 清分算账过程

清分是发生在结算前的一个算账的过程,它需要根据不同的结算对象计算如何来分配资金。我们知道一笔支付订单很多情况下并不是全额结算给收款人的,例如两人间的跨行转账场景需要计算手续费;点外卖需要计算手续费、配送费、服务费、商家外卖款等多种结算项目,只有算清楚这些账目后才能结算资金给实际的收款人。

2.2.3. 结算结账过程

结算是资金的最终转移的过程,资金的转移自然要通过账户来进行处理。这个过程包含对资金在账户间的转移,以及应收/应付账务的核销。

2.3. 支付资金

要实现资金和债权的流转,需要由“付款人、收款人、支付方式、清结算”这几部分组成。

2.3.1. 支付方式

支付业务说到底是一个通道生意,需要通过各种通道去链接人和资金,支付方式就是这些资金来源工具化表现。从系统设计层面来看,支付方式就是收银台上包装的支付工具,他代表了你可以用来支付的资金来源有哪些,这些资金来源通常需要支付渠道去链接打通,才能实现跨行收付款。

2.3.2. 收付款方

支付是服务与交易,支付从付款人开始,到收款人结束完成一笔交易。由于支付的敏感性和风险性要求,这里的收付款人都要开通资金账户,并且开通过程要接受实名认证、身份审核后才能进行支付行为。

2.3.3. 清结算

支付的第一需求就是资金的跨银行的转移,我们知道如果在一个银行、一个三方机构内账户间互转是可以实时到账的,这就是“支付即结算”。数字人民币能够实现跨行互转也是因为对公、对私的钱包账户开在数研所的缘故。而大多数情况下,我们要实现跨行支付时资金并不能做到这么及时到账,需要通过多个持牌机构之间清结算来实现最终的资金转移。因此清结算效率的高低,代表了一个平台上用户获得资金时间的长短。所以,如果说支付方式代表生产关系的话,清结算就代表了生产力。

2.4. 支付场景

支付产品最直观的感受就是以各种支付终端、收银台形态呈现在你面前,支付终端就是支付方式的一个可视化载体,他分为软件和硬件两种类型。

2.4.1. 支付软件

包括聚合银台、商家收银台、钱包账户、小程序、H5页面,API接口等。

2.4.2. 支付硬件

包括POS、刷脸设备、自助设备、扫码枪/盒等。

不管是硬件还是软件,最终支付指令都是通过背后的支付系统完成收款、付款和资金转移的。从上图我们可以看到,硬件设备由于安全和设备管理的需要,因此往往需要一个“设备服务端”来接收你的收款情况,支付软件则较为简单,可以直接接入交易系统完成支付。最终你的支付请求都是通过支付核心、支付渠道接入不同的银行、支付机构完成最终的收款和付款。

2.5. 支付产品

支付终端毕竟只能展示支付产品的冰山一角,完整的支付产品远比终端展现出来的要丰富的多。我们常说的支付产品主要包括四类,支付终端、收款产品、付款产品,以及产品背后的支撑能力。

2.5.1. 支付终端

支付终端我们前面也介绍过了,是支付产品外在表现,他的作用是尽可能接近付款人,并用最简单的方式让付款人完成支付,给商家带来源源不断的收入和生意。支付终端的也有很多的表现形式,也是为了满足不同的场景需求,我简单把它们分为三类。

2.5.2. 网络接口

典型的代表就是API接口,他以网络接口的形式提供给平台和商家进行对接,支付指令通过安全加密的报文传输。支付的收银台、交易界面、支付场景的适配都需要接入平台来开发。这类支付产品需要接入平台有比较完整的技术团队,自己能去适配各种支付场景为用户提供更好的体验;

对于提供接口的持牌机构来说,可以减少定制化需求的开发,同时这类接口对外提供资质审核要求也更高,因为这类接口直接暴露了持牌机构的支付能力,也很容易被撸接口产生合规风险。

这类接口在清算机构、银行、中小支付机构对外提供的产品比较常见,另外对于优质场景、交易场景复杂的企业/平台合作中也经常采用这种方式。

2.5.3. 终端接口

这类也需要技术对接的支付接口,只是在终端适配方面做了包装。常见的有小程序、H5、SDK、APP等,这类支付接口对于交易平台所用的支付终端进行了适配。

这种做法的好处是商家技术接入更加简单,也不需要非常专业的技术团队。同时持牌机构也能限定了商家的交易终端,这样一方面可以更好的防范风险,另一方也可以有效的保护自己的支付结算能力和通道,防止被撸接口。

2.5.4. 支付设备

这里一类支付产品以POS机、码牌、自助终端、刷脸设备等形式提供。商家几乎不需要任何技术对接能力,开箱即用。当然这类实体设备本身有比较高成本,并且这些设备推广、仓储、管理也会占用人力、物力和财力。因此这类支付产品的销售,首先要想明确谁来买单、谁来管理、谁来推广。

2.6. 收款产品

收款产品是移动支付的主力军,毕竟收款是支付的第一需求嘛。通常把收款产品分为两类“充值、收单”。

充值:就是付款账户和收款银行卡是同一个人(同名账户),我们平时在各类钱包中经常使用。与之相对应的提现,他也是需要收付款账户是同一个人。

收单:收单中的“单”原本指的是POS刷卡时消费者确认收款的小票,这种支付方式与通过银行汇款、转账方式进行付款的最大区别,就是收付款方对于订单的确认过程。收单是收付款双方可以同步确认订单,而汇款、转账这个过程全靠线下完成。后来收单这个概念被推广到了移动场景,我们平时通过扫码支付、刷卡支付、网银支付、钱包余额等方式向商家付款都是收单交易。

2.7. 付款产品

这类产品在账户提现、跨行转账、企业汇款中较为常见。付款产品可以说它既简单也不简单。付款产品的简单在于他的产品形态较为单一,付款到卡为汇款、付款到户为转账,同时为适应不同场景还分为单笔付款、批量付款、文件付款等。付款产品操作起来也不复杂,只要账户上有钱,选好收款银行、收款账户想付给谁都可以,无需收款方确认。

没有后悔药吃:付款产品属于没有后悔药吃的产品,特别是企业间付款金额一般都较大,如果选错账号、输错金额付出那就直接到账了,没有撤销、退款可以用。唯二的办法就是打电话给收款方让他打回来,或者祈祷对方收款人入账失败银行给你退票。如果这两招都不行就只能报警了。所以企业付款一般都比较谨慎,由专业的出纳来负责打款,并且原始协议/合同、付款申请单据、付款金额都要进行多级审核,最终才会进行付款。

付款即结算:付款通道同时也是清结算通道,拥有了付款能力实际就等于拥有了清结算能力。因此在持牌机构对于付款的审核是非常严格的,不仅要审核付款给谁,还要审核钱从哪里来,贸易背景是什么,与收款人的协议关系是什么,付款的周期和额度是多少等等。(有句老话,收款投诉多,付款案件多)

支付过程中数字化问题:由于线上化收款普遍只能在5w以下,因此企业间收付款都是通过跨行汇款来完成的。但是汇款背后的贸易背景往往是一份合同、协议或者债权债务关系,而付款产品仅能通过“附言”几十个字来传达,因此对企业来说账户上一堆钱如何认领,一直是每个企业实现数字化的瓶颈之一。

支付系统的能力:支付产品需要一套完整的支付系统来支撑其运转。面向消费者需要有各种支付终端来支撑;面向商家需要通过交易系统、支付渠道、结算系统来完成资金的结算到账。

3. 支付与交易关联

维度

交易(Transaction)

支付(Payment)

定义

买卖双方就商品/服务达成交换的过程,生成订单或合同

买方将资金转移给卖方的过程,实现结算

关注对象

商品 / 服务

资金

参与方

买方、卖方(交易撮合平台可作为中介)

付款方、收款方、支付机构、银行/清算机构

核心要素

标的物、数量、价格、交付方式

金额、支付渠道、支付方式、账户体系

产出结果

订单 / 合同

资金划转 / 结算完成

是否可独立存在

可以交易但暂不支付(赊账、分期、违约)

支付一般依托于交易,但也可独立存在(如转账、充值)

典型场景

电商下单、证券买卖、贷款签约

电商付款、POS 刷卡、线上转账

领域属性

业务域(业务逻辑为主)

资金域(金融结算为主)

前面分别介绍了支付、交易、支付交易三个比较接近的概念,这也是大家平时比较容易混淆的概念,因为他们之间的边界并不是很清晰。我们主要通过订单、资金两个纬度来进行区分的。

3.1. 交易以订单为主

虽然大多数交易都会与支付相伴,但依然有很多的特殊场景,只有交易没有支付,或者交易与支付方式没有必然匹配关系;例如:为了降低库存用制造的商品抵付原材的费用的,以货易货模式;还有交易过程中由于无力支付货款需要通过折价、拍卖欠款人的资产来支付货款这里抵押付款的方式。

这类交易的主要特征是只有订单、合同、协议,但没有实际资金转移,当然这种情况就不在我们此次的讨论范围了。

3.2. 支付以资金为主

这种行为比较容易产生混淆的,只有纯支付行为,并没有订单;比如自己账户的充值、提现;款项汇款、代付等;纯支付的的主要特点是只有支资金的转移,没有可匹配的订单。

这种无场景的支付行为在支付“风控审核”中是最为敏感的。因为持卡人的真实性、付款场景的真实性完全依靠审核人员对于用户身份的识别是否准确,背景调查是否充分,商户资质审核是否严格有很大的关系。

这部分场景是支付产品经理要去不断深入行业,通过数字化手段来实现订单与资金的匹配,最终进行线上化的业务。

3.3. 支付交易既有订单又有资金

这是我们最常见的场景,既有交易订单,又有资金的支付行为。这类交易也是非常适合实现线上化和数字化的业务,因为订单和资金可以通过规则计算能够匹配起来。这部分场景也是支付产品经理日常工作中要去把体验做的越来越好的地方。

3.4. 支付信息流

我们对支付的习惯理解是“信息流与资金流”的二流合一,这个概念起源于电商和企业领域的四流合一“商流、物流、信息流、资金流”,从宏观领域来说这么理解没问题,但对支付产品经理来说则略显粗糙了;实际工作中很多产品经理受此局限性,在与结算人员、企业财务人员沟通中经常聊不到一起去被人质疑专业能力。

3.4.1. 信息/资金/账单流

支付完整的理解应该是三流合一,这里需要把信息流再次细分为“信息流、支付流”,这里的支付流是指账务层面的应收应付与实际到账资金的核销,这样细分之后你才能打通宏观到微观的完整思考逻辑。

为什么要这么划分呢?因为不管是订单还是资金,发生支付行为最终都要在账务层面进行登记核销之后才能进行结算,否则后续的行为就挂起了。我们以下图的收单支付机构的三流合一图为例来介绍下这个过程。

3.4.2. 收单机构

收单机构也叫第三方支付公司(例如我们常用的微信、支付宝产品),第三方支付能如此流行在于它具有“清结算”能力,把订单、资金都能在线上完成转移。如上图所示,“付款方”在线向“收款方”下单,三方机构收款成功后由于该笔资金不能马上到账,因此将这笔账务登记为“应收”,此时收款方的账户余额内有一笔“待结算”资金。当资金到账后,三方机构进行结算,将这笔“实收”账务与“应收”进行核销,这时候收款人账户上的“待结算”资金变成了“可用余额”。这就是收单机构的三流合一,他的特点就是“订单、账务、资金”在一个完整的闭环内完成,实现资金的线上转移。

3.4.3. 企业/四方支付

现在企业正是由于不能在线上实时完成账务处理,因此财务更加依赖订单明细和资金回单进行内部会计核算与税务处理。因此在企业财务管理、业财一体化过程中最棘手、最突出的就是结算对账与账务核算问题,这些问题严重影响企业存货与资金的周转效率。

从上图我们可以看到,企业在电商平台、收单机构快速的完成了收款和结算过程,但是资金到了企业账户中,这些资金如何与合同、订单匹配,最终实现财务入账呢?这就需要企业去“下载流水”与合同/订单对应的“应收账款”进行匹配与核对,然后根据下载“余额明细或者资金到账明细”去“核销应收账款”,企业财务才能更好的使用资金盘活库存和现金的周转。

博文参考

  • 《白话支付》
  • 《支付域》
  • 《交易支付》
http://www.xdnf.cn/news/20024.html

相关文章:

  • 龙虎榜——20250904
  • 深度剖析:智能驾驶到底给2025带来了什么
  • 用服务器搭 “私人 AI 助手”:不用联网也能用,支持语音对话 / 文档总结(教程)
  • Hoppscotch:开源轻量API测试工具,秒启动高效解决临时接口测试需求
  • git基础命令 git基础操作
  • PyTorch DDP 随机卡死复盘
  • < 自用文 OS 有关 > (续)发现正在被攻击 后的自救 Fail2ban + IPset + UFW 工作流程详解
  • 十四、STM32-----低功耗
  • 【前端教程】JavaScript DOM 操作案例解析与代码优化
  • 不用服务器也能监控网络:MyIP+cpolar让中小企业告别昂贵方案
  • 【全网最全】《2025国赛/高教杯》C题 思路+代码python和matlab+文献 一到四问 退火算法+遗传算法 NIPT的时点选择与胎儿的异常判定
  • Qt 系统相关 - 1
  • 大整数乘法实现日志:从查表法到逐位运算
  • 基于深度掩码的动态模糊处理
  • 《Html泛型魔法学院:用霍格沃茨风格网页教授集合框架》
  • SpringBoot 集成 MyBatis-Plus 的使用指南
  • 学习PaddlePaddle--环境配置-Windows 11 + RTX 4060
  • 优质技术博客分享(第1期)
  • Beautiful.ai:AI辅助PPT工具高效搞定排版,告别熬夜做汇报烦恼
  • maven settings.xml文件的各个模块、含义以及它们之间的联系
  • 阿瓦隆 A1146 Pro 63T:性能与设计详解,探索区块链挖矿新高度
  • 【网工基础】20+常用网络协议介绍
  • 水下管道巡检机器人结构设cad+三维图+设计说明书
  • 2508C++,skia动画
  • 【iOS】对象复制与属性关键字
  • 同步安卓手机的照片到NAS的方案(完美)
  • 人工智能学习:鸢尾花数据获取
  • qwen-code 功能分析报告
  • 软件安装教程(四):在 Windows 上安装与配置 MATLAB(超详细)
  • 【2025企业建站推荐指南】深度解析十大顶尖网站建设公司:从品牌设计到技术落地的全维度解决方案