1、支付行业现状和出路如何？
卖源代码是个出路，之后收维护费用
支付牌照很难申请，可以收购公司把牌照买过来
资金托管协议银行也不乐意办理
卖源代码是个出路，之后收维护费用
支付牌照很难申请，可以收购公司把牌照买过来
资金托管协议银行也不乐意办理
AT、非AT的支付公司、非支付公司这3类公司，得做到什么规模，才需要自建支付系统，比直接用AT的系统划算？
【交易规模】
每年交易流水1000亿
貌似支付宝，跟财付通这种大公司才能达到，中央结算公司一天好像是4万亿）
【团队规模】
得养个至少30人团队
看系统不同吧，同样是支付系统，支付宝这种，300人也搞定不了。但是如果是机构间的，每天往来不过几千笔，每笔几百亿的话，30个人应该也够了。
【小道消息】
要真的做支付系统的清结算业务其实挺困难的；大部分支付公司其实都是做信息的清分，好像只有支付宝、银联有做资金的清分；
支付系统是分级的，所有支付和资金系统也只能做自己内部的账务清算（不知道理解对不对）
除了支付宝系统是自己建设的，其他的都是银联交易系统复制出来的，只不过是改的多改的少的问题
【网友回应】
支付是底层功能，要么抱大腿，要么像at覆盖全入口，否则怎么赚钱？
只有金融公司这种大腿才需要自己开发支付，量小金额大
【交易规模】
每年交易流水1000亿
貌似支付宝，跟财付通这种大公司才能达到，中央结算公司一天好像是4万亿）
展开全文
每年交易流水1000亿
貌似支付宝，跟财付通这种大公司才能达到，中央结算公司一天好像是4万亿）
【团队规模】
得养个至少30人团队
看系统不同吧，同样是支付系统，支付宝这种，300人也搞定不了。但是如果是机构间的，每天往来不过几千笔，每笔几百亿的话，30个人应该也够了。
得养个至少30人团队
看系统不同吧，同样是支付系统，支付宝这种，300人也搞定不了。但是如果是机构间的，每天往来不过几千笔，每笔几百亿的话，30个人应该也够了。
【小道消息】
要真的做支付系统的清结算业务其实挺困难的；大部分支付公司其实都是做信息的清分，好像只有支付宝、银联有做资金的清分；
支付系统是分级的，所有支付和资金系统也只能做自己内部的账务清算（不知道理解对不对）
除了支付宝系统是自己建设的，其他的都是银联交易系统复制出来的，只不过是改的多改的少的问题
要真的做支付系统的清结算业务其实挺困难的；大部分支付公司其实都是做信息的清分，好像只有支付宝、银联有做资金的清分；
支付系统是分级的，所有支付和资金系统也只能做自己内部的账务清算（不知道理解对不对）
除了支付宝系统是自己建设的，其他的都是银联交易系统复制出来的，只不过是改的多改的少的问题
【网友回应】
支付是底层功能，要么抱大腿，要么像at覆盖全入口，否则怎么赚钱？
只有金融公司这种大腿才需要自己开发支付，量小金额大
支付是底层功能，要么抱大腿，要么像at覆盖全入口，否则怎么赚钱？
只有金融公司这种大腿才需要自己开发支付，量小金额大
【官方简介】
中央国债登记结算有限责任公司是为全国债券市场提供国债、金融债券、企业债券和其他固定收益证券的登记、托管、交易结算等服务的国有独资金融机构，是财政部唯一授权主持建立、运营全国国债托管系统的机构，是中国人民银行指定的全国银行间债券市场债券登记、托管、结算机构和商业银行柜台记账式国债交易一级托管人。from百度百科
中央国债登记结算有限责任公司（简称“中央结算公司”）是经国务院批准设立的中央登记托管结算机构，属于国有独资的中央金融企业，承载国家的意志，代表市场的诉求，是我国核心金融市场基础设施。承载国家意志。
【内部描述】
国务院批准，号称是直属，但其实是银监会管辖；人事权在银监会，业务上归央行、财政部、银监会、发改委、证监会、保监会多头监管。
每年交易笔数1万笔以内，业务是机构对机构
央行的公开市场操作都是中央结算公司在做，比如放水之类的
某部门一共30多人，负责全公司40多个业务系统。开发商团队200号人，基本上是每个人负责一个业务条线吧。我们负责了央行的公开市场操作，逆回购，正回购等一些宏观调控的职责。
【官方简介】
中央国债登记结算有限责任公司是为全国债券市场提供国债、金融债券、企业债券和其他固定收益证券的登记、托管、交易结算等服务的国有独资金融机构，是财政部唯一授权主持建立、运营全国国债托管系统的机构，是中国人民银行指定的全国银行间债券市场债券登记、托管、结算机构和商业银行柜台记账式国债交易一级托管人。from百度百科
中央国债登记结算有限责任公司是为全国债券市场提供国债、金融债券、企业债券和其他固定收益证券的登记、托管、交易结算等服务的国有独资金融机构，是财政部唯一授权主持建立、运营全国国债托管系统的机构，是中国人民银行指定的全国银行间债券市场债券登记、托管、结算机构和商业银行柜台记账式国债交易一级托管人。from百度百科
中央国债登记结算有限责任公司（简称“中央结算公司”）是经国务院批准设立的中央登记托管结算机构，属于国有独资的中央金融企业，承载国家的意志，代表市场的诉求，是我国核心金融市场基础设施。承载国家意志。
中央国债登记结算有限责任公司（简称“中央结算公司”）是经国务院批准设立的中央登记托管结算机构，属于国有独资的中央金融企业，承载国家的意志，代表市场的诉求，是我国核心金融市场基础设施。承载国家意志。
【内部描述】
国务院批准，号称是直属，但其实是银监会管辖；人事权在银监会，业务上归央行、财政部、银监会、发改委、证监会、保监会多头监管。
每年交易笔数1万笔以内，业务是机构对机构
央行的公开市场操作都是中央结算公司在做，比如放水之类的
某部门一共30多人，负责全公司40多个业务系统。开发商团队200号人，基本上是每个人负责一个业务条线吧。我们负责了央行的公开市场操作，逆回购，正回购等一些宏观调控的职责。
国务院批准，号称是直属，但其实是银监会管辖；人事权在银监会，业务上归央行、财政部、银监会、发改委、证监会、保监会多头监管。
每年交易笔数1万笔以内，业务是机构对机构
央行的公开市场操作都是中央结算公司在做，比如放水之类的
某部门一共30多人，负责全公司40多个业务系统。开发商团队200号人，基本上是每个人负责一个业务条线吧。我们负责了央行的公开市场操作，逆回购，正回购等一些宏观调控的职责。
资金风控系统如何评级？什么标准？资料不够细，是否有经验可分享？
【资料共享】
第三方支付赔本赚吆喝的现状
【资料共享】
第三方支付赔本赚吆喝的现状
第三方支付赔本赚吆喝的现状
有没有风控系统设计相关的非密级的产品方案可以共享？
【类似问题】
有一些防资金损失的 风控或资金管理的资料&流程吗？
求教：如果公司现在的风控系统薄弱，如何搭建？
大家风控系统，都会从哪些方面考虑？风控在哪个环节介入？
【网友回应】
监控哪些信息，也要看能拿到哪些信息，如何辨识先分析有哪些风险，分析风险特征，根据特征制定监控策略；分析维度客户，账户，商户，设备，地区，交易频次，交易金额，行为习惯
先防黑产，各种黑白灰名单，各种限额限次
专业模型（机器学习）参考支付宝、财付通，更多的是通过规则来做线性防范
【关联问题】
一般的公司，支付时如何拿到更多的用户信息？有限的信息中如何做监控？一般企业的支付渠道只有微信，支付宝，这俩又不会提供银行卡号，如何做风控？
黑产是什么？防黑产？通过自建SRC？反欺诈怎么做？
黑产：比如说非法数据的窃取与交易，网络攻击与敲诈勒索，网络诈骗，手机木马、挂马与人海战术、打马产业等等。黑产其实是一个很讨厌的事情，但从事金融的每天都在和钱、和黑产打交道，所以每个平台也都为此努力着。
设备指纹（sdk/js）、击键行为（支付宝可采集到键盘数据）
是否能采集取决于用户授权；授权更多的是SDK、针对硬件设备,不提供银行卡号，那就从交易频次，金额，商户分析
准确度取决于能采集到的信息项，信息项取决于系统授权；js准确率不高，依赖浏览器，换一个浏览器，就相当于一台新设备
手机系统现在对app授权越收越窄，不过好的用户体验和授权是和授权结合在一起的
做风控，拿到的信息越多越好。但拿不到，就已拿到的信息，尽可能的把相应的风险特征分析全
【资料共享】
在线支付之风控系统架构选型
【类似问题】
有一些防资金损失的 风控或资金管理的资料&流程吗？
求教：如果公司现在的风控系统薄弱，如何搭建？
大家风控系统，都会从哪些方面考虑？风控在哪个环节介入？
有一些防资金损失的 风控或资金管理的资料&流程吗？
求教：如果公司现在的风控系统薄弱，如何搭建？
大家风控系统，都会从哪些方面考虑？风控在哪个环节介入？
【网友回应】
监控哪些信息，也要看能拿到哪些信息，如何辨识先分析有哪些风险，分析风险特征，根据特征制定监控策略；分析维度客户，账户，商户，设备，地区，交易频次，交易金额，行为习惯
先防黑产，各种黑白灰名单，各种限额限次
专业模型（机器学习）参考支付宝、财付通，更多的是通过规则来做线性防范
监控哪些信息，也要看能拿到哪些信息，如何辨识先分析有哪些风险，分析风险特征，根据特征制定监控策略；分析维度客户，账户，商户，设备，地区，交易频次，交易金额，行为习惯
先防黑产，各种黑白灰名单，各种限额限次
专业模型（机器学习）参考支付宝、财付通，更多的是通过规则来做线性防范
【关联问题】
一般的公司，支付时如何拿到更多的用户信息？有限的信息中如何做监控？一般企业的支付渠道只有微信，支付宝，这俩又不会提供银行卡号，如何做风控？
黑产是什么？防黑产？通过自建SRC？反欺诈怎么做？
黑产：比如说非法数据的窃取与交易，网络攻击与敲诈勒索，网络诈骗，手机木马、挂马与人海战术、打马产业等等。黑产其实是一个很讨厌的事情，但从事金融的每天都在和钱、和黑产打交道，所以每个平台也都为此努力着。
一般的公司，支付时如何拿到更多的用户信息？有限的信息中如何做监控？一般企业的支付渠道只有微信，支付宝，这俩又不会提供银行卡号，如何做风控？
黑产是什么？防黑产？通过自建SRC？反欺诈怎么做？
黑产：比如说非法数据的窃取与交易，网络攻击与敲诈勒索，网络诈骗，手机木马、挂马与人海战术、打马产业等等。黑产其实是一个很讨厌的事情，但从事金融的每天都在和钱、和黑产打交道，所以每个平台也都为此努力着。
黑产：比如说非法数据的窃取与交易，网络攻击与敲诈勒索，网络诈骗，手机木马、挂马与人海战术、打马产业等等。黑产其实是一个很讨厌的事情，但从事金融的每天都在和钱、和黑产打交道，所以每个平台也都为此努力着。
设备指纹（sdk/js）、击键行为（支付宝可采集到键盘数据）
是否能采集取决于用户授权；授权更多的是SDK、针对硬件设备,不提供银行卡号，那就从交易频次，金额，商户分析
准确度取决于能采集到的信息项，信息项取决于系统授权；js准确率不高，依赖浏览器，换一个浏览器，就相当于一台新设备
手机系统现在对app授权越收越窄，不过好的用户体验和授权是和授权结合在一起的
做风控，拿到的信息越多越好。但拿不到，就已拿到的信息，尽可能的把相应的风险特征分析全
【资料共享】
在线支付之风控系统架构选型
在线支付之风控系统架构选型
大家支付平台的同城双活和异地多活是怎么做的？
深圳两个中心，交易通过消息中间件切了部分流量发往两个中心
数据库本身就是腾讯的tdsql分布式数据库，数据库直接保证数据备份
set即数据库服务单位，一个set单个节点，1主2备
【网友追问】
Q:两个机房的交易通过消息中间件来分流，那中间件本身不还是单点吗？怎么保证消息系统在两个数据中心双活？
A:主流消息系统都有高可用的方案；这个消息系统说是高可用的，但怎么实现高可用的得找人再了解下。
Q：多活需要无力的虚拟路由支持吧？
A：是的。
深圳两个中心，交易通过消息中间件切了部分流量发往两个中心
数据库本身就是腾讯的tdsql分布式数据库，数据库直接保证数据备份
set即数据库服务单位，一个set单个节点，1主2备
【网友追问】
Q:两个机房的交易通过消息中间件来分流，那中间件本身不还是单点吗？怎么保证消息系统在两个数据中心双活？
A:主流消息系统都有高可用的方案；这个消息系统说是高可用的，但怎么实现高可用的得找人再了解下。
Q：多活需要无力的虚拟路由支持吧？
A：是的。
Q:两个机房的交易通过消息中间件来分流，那中间件本身不还是单点吗？怎么保证消息系统在两个数据中心双活？
A:主流消息系统都有高可用的方案；这个消息系统说是高可用的，但怎么实现高可用的得找人再了解下。
Q：多活需要无力的虚拟路由支持吧？
A：是的。
大家APP收银台一般放在交易系统还是支付网关（支付系统），还是单独放？
【系统隔离】
建议与交易系统做分隔。是否放在支付网关视情况而定
是分开的，收银台属于基础组，收银台与账务、通道网关、结算是分开的；收银台主要考虑绑卡、验段验密、支付、优惠选择、回调等流程
的收银台作为独立的应用对外提供服务
【技术选型】
支付网关采用异步架构较多，同步性能跟不上
异步架构中，消息队列的使用主要看公司选型，activemq、rocketmq都有
kafka一般还是作为日志传输用，主要是能容忍消息可能会丢失
自研了一套mq
用过rocketmq之前的版本，app在接受消息通知的时候，需要做幂等控制；mq最少通知一次和只通知一次，在实现上有较大的区别
【职责划分】
的收银台、交易记录、订单系统是3波人，分别有各自PM；收银台属交易底层，订单是包装在交易上面的结构
【资料共享】
基础架构设计
“三活”数据中心实践经验
【系统隔离】
建议与交易系统做分隔。是否放在支付网关视情况而定
是分开的，收银台属于基础组，收银台与账务、通道网关、结算是分开的；收银台主要考虑绑卡、验段验密、支付、优惠选择、回调等流程
的收银台作为独立的应用对外提供服务
建议与交易系统做分隔。是否放在支付网关视情况而定
是分开的，收银台属于基础组，收银台与账务、通道网关、结算是分开的；收银台主要考虑绑卡、验段验密、支付、优惠选择、回调等流程
的收银台作为独立的应用对外提供服务
【技术选型】
支付网关采用异步架构较多，同步性能跟不上
异步架构中，消息队列的使用主要看公司选型，activemq、rocketmq都有
kafka一般还是作为日志传输用，主要是能容忍消息可能会丢失
自研了一套mq
用过rocketmq之前的版本，app在接受消息通知的时候，需要做幂等控制；mq最少通知一次和只通知一次，在实现上有较大的区别
支付网关采用异步架构较多，同步性能跟不上
异步架构中，消息队列的使用主要看公司选型，activemq、rocketmq都有
kafka一般还是作为日志传输用，主要是能容忍消息可能会丢失
自研了一套mq
用过rocketmq之前的版本，app在接受消息通知的时候，需要做幂等控制；mq最少通知一次和只通知一次，在实现上有较大的区别
【职责划分】
的收银台、交易记录、订单系统是3波人，分别有各自PM；收银台属交易底层，订单是包装在交易上面的结构
【资料共享】
基础架构设计
“三活”数据中心实践经验
基础架构设计
“三活”数据中心实践经验
对接网联平台的计划和进度？
【网友回应】
网联系统四大行都没接入呢……首批联调时间是6.30……
其实现在网联平台上没接入几家银行
==财付通==接了，==支付宝==好像还没没接，即使接入，刚开始也是只切1%交易过去
==百度==接了，还没投产
作为银行接入方参与过需求讨论和方案设计，联初期只接入有支付牌照的第三方支付机构，没有支付拍照的还是保持和银行直连模式
网联的官网还没出
【小编补充】
网联平台是在中国人民银行指导下，由中国支付清算协会组织共同发起筹建，旨在为支付机构提供统一、公共的资金清算服务。2017年3月31日启动试运行，试运行期间，将验证网联平台的系统功能、业务规则和风控措施的完整性和有效性。试运行结束后，将按计划、分批次安排其他银行和支付机构陆续接入系统。 from 百度百科
【网友回应】
网联系统四大行都没接入呢……首批联调时间是6.30……
其实现在网联平台上没接入几家银行
==财付通==接了，==支付宝==好像还没没接，即使接入，刚开始也是只切1%交易过去
==百度==接了，还没投产
作为银行接入方参与过需求讨论和方案设计，联初期只接入有支付牌照的第三方支付机构，没有支付拍照的还是保持和银行直连模式
网联的官网还没出
网联系统四大行都没接入呢……首批联调时间是6.30……
其实现在网联平台上没接入几家银行
==财付通==接了，==支付宝==好像还没没接，即使接入，刚开始也是只切1%交易过去
==百度==接了，还没投产
作为银行接入方参与过需求讨论和方案设计，联初期只接入有支付牌照的第三方支付机构，没有支付拍照的还是保持和银行直连模式
网联的官网还没出
【小编补充】
网联平台是在中国人民银行指导下，由中国支付清算协会组织共同发起筹建，旨在为支付机构提供统一、公共的资金清算服务。2017年3月31日启动试运行，试运行期间，将验证网联平台的系统功能、业务规则和风控措施的完整性和有效性。试运行结束后，将按计划、分批次安排其他银行和支付机构陆续接入系统。 from 百度百科
网联平台是在中国人民银行指导下，由中国支付清算协会组织共同发起筹建，旨在为支付机构提供统一、公共的资金清算服务。2017年3月31日启动试运行，试运行期间，将验证网联平台的系统功能、业务规则和风控措施的完整性和有效性。试运行结束后，将按计划、分批次安排其他银行和支付机构陆续接入系统。 from 百度百科
可否分享一些清分、对账、报表的架构思路？
【对账】
对账三大模块处理各不一样：内部，渠道，业务方
【清分】
暂无回应
【对账】
对账三大模块处理各不一样：内部，渠道，业务方
对账三大模块处理各不一样：内部，渠道，业务方
【清分】
暂无回应
暂无回应
微信支付商户平台中看不到订单中的商品详情列表，只有每个订单总金额，财务想每一种商品单独对账，大家有遇到过类似需求的吗？
微信商户后台，只有商户订单号是可以和自己的交易系统记录中的商户订单号匹配的，可以加备注字段
正统做法应该还是渠道对账和内部对账来保证的，渠道方面只关注金额状态正确；外部对账对流水，内部对账对细节；还有就是核对每个通道每日的待清算科目余额变动是否与实际发生额一致。
银行类似场景的处理方式是三方对账：
（1）支付流水和通道流水对，以通道为准同步状态。
（2）支付记账流水和核心流水对，以核心记账流水为准。
（3）三方流水记入应收应付流水表对，检查单边账记录。
微信商户后台，只有商户订单号是可以和自己的交易系统记录中的商户订单号匹配的，可以加备注字段
正统做法应该还是渠道对账和内部对账来保证的，渠道方面只关注金额状态正确；外部对账对流水，内部对账对细节；还有就是核对每个通道每日的待清算科目余额变动是否与实际发生额一致。
银行类似场景的处理方式是三方对账：
（1）支付流水和通道流水对，以通道为准同步状态。
（2）支付记账流水和核心流水对，以核心记账流水为准。
（3）三方流水记入应收应付流水表对，检查单边账记录。
我们准备采用微服务重构一下支付平台，问一下模块怎么划分比较合理？
暂无回应
暂无回应
借鉴老熊文章的一些思路，请教一下大家，我的app业务后台产品架构这样规划是否合理？
【场景描述】
用户充话费，弹出收银台，用户选择微信和支付宝付款。我是准备构建一下业务后台，顺便把收银台做成公共支付应用。
收银台的支付方式，对应网关的支付渠道；收银台展示可支付的渠道，用户选择后，提交，先过交易系统，校验没有问题再走支付网关给上游
【网友回应】
这个问题的涵盖范围有点大吧…单从这张图来看，个人觉得没毛病，不过似乎没法给出答案……感觉还是要结合产品定位与业务场景…
泛泛来说的话，app的订单管理、用户管理、查询统计等这些服务，应该是在没截全的图里面，问题有点大，不清楚背景，无从下手
收银台方面作为公共支付应用的话，鉴权和安全性方面，需要考虑
收银台和支付网关不和谐；从业务流程看，应该是从订单页面到收银台，客户在收银台确认订单信息，然后选择支付方式。这里能稍微说说你的收银台和支付网关的职责么？如果网关只对接通道，负责通道接口通讯，和做支付路由，这个划分是没有问题。就怕收银台和网关有重叠的功能，==深圳优讯==之前就是这样，到后面代码改的一团乱；这边理想的网关是把各个支付通道进行对接，然后按照业务场景进行包装提供给收银台，比如网关提供，绑卡，充值，支付，提现，查询，对账这些业务场景；收银台不需要知道我提现是走的代付还是二代，还是超网，业务角度肯定是成本优先，客户角度是结果效应。
【场景描述】
用户充话费，弹出收银台，用户选择微信和支付宝付款。我是准备构建一下业务后台，顺便把收银台做成公共支付应用。
收银台的支付方式，对应网关的支付渠道；收银台展示可支付的渠道，用户选择后，提交，先过交易系统，校验没有问题再走支付网关给上游
用户充话费，弹出收银台，用户选择微信和支付宝付款。我是准备构建一下业务后台，顺便把收银台做成公共支付应用。
收银台的支付方式，对应网关的支付渠道；收银台展示可支付的渠道，用户选择后，提交，先过交易系统，校验没有问题再走支付网关给上游
【网友回应】
这个问题的涵盖范围有点大吧…单从这张图来看，个人觉得没毛病，不过似乎没法给出答案……感觉还是要结合产品定位与业务场景…
泛泛来说的话，app的订单管理、用户管理、查询统计等这些服务，应该是在没截全的图里面，问题有点大，不清楚背景，无从下手
收银台方面作为公共支付应用的话，鉴权和安全性方面，需要考虑
收银台和支付网关不和谐；从业务流程看，应该是从订单页面到收银台，客户在收银台确认订单信息，然后选择支付方式。这里能稍微说说你的收银台和支付网关的职责么？如果网关只对接通道，负责通道接口通讯，和做支付路由，这个划分是没有问题。就怕收银台和网关有重叠的功能，==深圳优讯==之前就是这样，到后面代码改的一团乱；这边理想的网关是把各个支付通道进行对接，然后按照业务场景进行包装提供给收银台，比如网关提供，绑卡，充值，支付，提现，查询，对账这些业务场景；收银台不需要知道我提现是走的代付还是二代，还是超网，业务角度肯定是成本优先，客户角度是结果效应。
这个问题的涵盖范围有点大吧…单从这张图来看，个人觉得没毛病，不过似乎没法给出答案……感觉还是要结合产品定位与业务场景…
泛泛来说的话，app的订单管理、用户管理、查询统计等这些服务，应该是在没截全的图里面，问题有点大，不清楚背景，无从下手
收银台方面作为公共支付应用的话，鉴权和安全性方面，需要考虑
收银台和支付网关不和谐；从业务流程看，应该是从订单页面到收银台，客户在收银台确认订单信息，然后选择支付方式。这里能稍微说说你的收银台和支付网关的职责么？如果网关只对接通道，负责通道接口通讯，和做支付路由，这个划分是没有问题。就怕收银台和网关有重叠的功能，==深圳优讯==之前就是这样，到后面代码改的一团乱；这边理想的网关是把各个支付通道进行对接，然后按照业务场景进行包装提供给收银台，比如网关提供，绑卡，充值，支付，提现，查询，对账这些业务场景；收银台不需要知道我提现是走的代付还是二代，还是超网，业务角度肯定是成本优先，客户角度是结果效应。
收银台对优惠折扣券如何处理？
【场景描述】
我们自己给客户提供支付平台，用户订场后，顺便买水收银台结算，优惠就直接平摊到明细中，导致明细很多
目前平摊不靠谱，需要拆单且不准确，订单明细数据增多也很麻烦，部分退的时候要退无限次直到退完
我们之前约定，部分退款时，先退红包卡券，最后退现金，这么做是为了不让现金流失（做的是实物交易）
交易逆流程（退款）时客户需要通过明细来核账，想了解是否有优化方案
【网友回应】
使用营销账户（退款之后无法知道一个订单明细具体在当次交易中优惠了多少）
商户有结算账户和权益资金账户。优惠都走权益账户的资金。分开即可。有营销平台管理优惠券。 2个订单做关联，对账就不乱
要么平摊进去，退的时候扣除优惠退，有的是必须整体退，不能单独退一部分
卡券很复杂的，没有高招。一点一点梳理。先梳理能力结构，再看权益类型。然后想交互和后台
==钱通==的收银台只有付款信息，优惠信息，引导用户选择支付方式。用户提交后，交易系统会做检验，校验通过的生成订单，之后调起支付网关，完成支付后收起收银台，展示支付结果。
优惠都是前置的，下单时金额已经扣减了
【资料共享】
==百度金融== 卡券包字段架构图
==百度金融== 卡券包业务框架图
【场景描述】
我们自己给客户提供支付平台，用户订场后，顺便买水收银台结算，优惠就直接平摊到明细中，导致明细很多
目前平摊不靠谱，需要拆单且不准确，订单明细数据增多也很麻烦，部分退的时候要退无限次直到退完
我们之前约定，部分退款时，先退红包卡券，最后退现金，这么做是为了不让现金流失（做的是实物交易）
交易逆流程（退款）时客户需要通过明细来核账，想了解是否有优化方案
我们自己给客户提供支付平台，用户订场后，顺便买水收银台结算，优惠就直接平摊到明细中，导致明细很多
目前平摊不靠谱，需要拆单且不准确，订单明细数据增多也很麻烦，部分退的时候要退无限次直到退完
我们之前约定，部分退款时，先退红包卡券，最后退现金，这么做是为了不让现金流失（做的是实物交易）
交易逆流程（退款）时客户需要通过明细来核账，想了解是否有优化方案
【网友回应】
使用营销账户（退款之后无法知道一个订单明细具体在当次交易中优惠了多少）
商户有结算账户和权益资金账户。优惠都走权益账户的资金。分开即可。有营销平台管理优惠券。 2个订单做关联，对账就不乱
要么平摊进去，退的时候扣除优惠退，有的是必须整体退，不能单独退一部分
卡券很复杂的，没有高招。一点一点梳理。先梳理能力结构，再看权益类型。然后想交互和后台
==钱通==的收银台只有付款信息，优惠信息，引导用户选择支付方式。用户提交后，交易系统会做检验，校验通过的生成订单，之后调起支付网关，完成支付后收起收银台，展示支付结果。
优惠都是前置的，下单时金额已经扣减了
使用营销账户（退款之后无法知道一个订单明细具体在当次交易中优惠了多少）
商户有结算账户和权益资金账户。优惠都走权益账户的资金。分开即可。有营销平台管理优惠券。 2个订单做关联，对账就不乱
要么平摊进去，退的时候扣除优惠退，有的是必须整体退，不能单独退一部分
卡券很复杂的，没有高招。一点一点梳理。先梳理能力结构，再看权益类型。然后想交互和后台
==钱通==的收银台只有付款信息，优惠信息，引导用户选择支付方式。用户提交后，交易系统会做检验，校验通过的生成订单，之后调起支付网关，完成支付后收起收银台，展示支付结果。
优惠都是前置的，下单时金额已经扣减了
【资料共享】
==百度金融== 卡券包字段架构图
==百度金融== 卡券包业务框架图
==百度金融== 卡券包字段架构图
==百度金融== 卡券包业务框架图
交易风控有啥高招？比如，评级风控的标准是什么？不同阶段/敏感场景的评级风控策略如何判断和评估？如何升级降级（比如交易激增、信用卡套现等）
【网友回应】
看用户的消费习惯、金额、地点
地点通过IP获取（网络IP造假不可避免，黑名单也不能完全解决问题）
对于一般用户，运营商分配的ip是不固定的，所以才会有识别代理IP的
网银充值给客户风控很难做，因为网银支付不知道是否盗卡，==赵艺璇==提出网银银行不授权、不赔付，但每个公司可能不一样
【网友回应】
看用户的消费习惯、金额、地点
地点通过IP获取（网络IP造假不可避免，黑名单也不能完全解决问题）
对于一般用户，运营商分配的ip是不固定的，所以才会有识别代理IP的
网银充值给客户风控很难做，因为网银支付不知道是否盗卡，==赵艺璇==提出网银银行不授权、不赔付，但每个公司可能不一样
看用户的消费习惯、金额、地点
地点通过IP获取（网络IP造假不可避免，黑名单也不能完全解决问题）
对于一般用户，运营商分配的ip是不固定的，所以才会有识别代理IP的
网银充值给客户风控很难做，因为网银支付不知道是否盗卡，==赵艺璇==提出网银银行不授权、不赔付，但每个公司可能不一样
有什么建议？
16 银行卡签约
关于绑卡/签约/授权，银行卡一步式和两步式签约的区别和意义是什么（安全）？
【网友回应】
第三方存管业务签约方式有两种：一种是一步式，一种是两步式支付平台做的都是快捷四要素签约，不存在这种一步式两步式
这是二要素签约不安全，存在盗刷；建议用4、6要素签约；储蓄卡用4要素：姓名、身份证号、银行卡号、银行预留手机号；信用卡用6要素：储蓄卡的4个+cvn/cvv 有效期
cvn是card verification number,cvv/cvc是card verification value/code，都是信用卡隐藏密码和安全码
绑卡就是用户授权平台从其账户扣款，故绑卡就可以理解为用户、银行、平台三方签约
【周边问题】
信用卡出了大额授权接口，需要了解人行222号文件
渠道充值取现是否收费，取决于商务谈判；若压缩成本，则性能是否稳定，又很头疼。
超级网银V1.6版本有单笔实时客户信息查询报文，今年各行陆续会上线。已经有一些行4月上线了。四川有银行已经拿到，==深圳优讯==正在改造
之前261那个文件，转账提供实时到账，延迟到账，次日到账，有些银行怕被人行谈话，差点也把支付平台的提现交易也纳入其中。。。后来再三与人行确认，人行说先不管支付平台了，只做atm。。。才放过我们==深圳优讯==
【网友回应】
第三方存管业务签约方式有两种：一种是一步式，一种是两步式支付平台做的都是快捷四要素签约，不存在这种一步式两步式
这是二要素签约不安全，存在盗刷；建议用4、6要素签约；储蓄卡用4要素：姓名、身份证号、银行卡号、银行预留手机号；信用卡用6要素：储蓄卡的4个+cvn/cvv 有效期
cvn是card verification number,cvv/cvc是card verification value/code，都是信用卡隐藏密码和安全码
绑卡就是用户授权平台从其账户扣款，故绑卡就可以理解为用户、银行、平台三方签约
第三方存管业务签约方式有两种：一种是一步式，一种是两步式支付平台做的都是快捷四要素签约，不存在这种一步式两步式
这是二要素签约不安全，存在盗刷；建议用4、6要素签约；储蓄卡用4要素：姓名、身份证号、银行卡号、银行预留手机号；信用卡用6要素：储蓄卡的4个+cvn/cvv 有效期
cvn是card verification number,cvv/cvc是card verification value/code，都是信用卡隐藏密码和安全码
cvn是card verification number,cvv/cvc是card verification value/code，都是信用卡隐藏密码和安全码
绑卡就是用户授权平台从其账户扣款，故绑卡就可以理解为用户、银行、平台三方签约
绑卡就是用户授权平台从其账户扣款，故绑卡就可以理解为用户、银行、平台三方签约
【周边问题】
信用卡出了大额授权接口，需要了解人行222号文件
渠道充值取现是否收费，取决于商务谈判；若压缩成本，则性能是否稳定，又很头疼。
超级网银V1.6版本有单笔实时客户信息查询报文，今年各行陆续会上线。已经有一些行4月上线了。四川有银行已经拿到，==深圳优讯==正在改造
之前261那个文件，转账提供实时到账，延迟到账，次日到账，有些银行怕被人行谈话，差点也把支付平台的提现交易也纳入其中。。。后来再三与人行确认，人行说先不管支付平台了，只做atm。。。才放过我们==深圳优讯==
信用卡出了大额授权接口，需要了解人行222号文件
渠道充值取现是否收费，取决于商务谈判；若压缩成本，则性能是否稳定，又很头疼。
超级网银V1.6版本有单笔实时客户信息查询报文，今年各行陆续会上线。已经有一些行4月上线了。四川有银行已经拿到，==深圳优讯==正在改造
之前261那个文件，转账提供实时到账，延迟到账，次日到账，有些银行怕被人行谈话，差点也把支付平台的提现交易也纳入其中。。。后来再三与人行确认，人行说先不管支付平台了，只做atm。。。才放过我们==深圳优讯==
各位遇到过这种问题么，消费者首先在A店扫码支付，成功，再去B店扫码支付，出现扫B店的码显示A店商户信息？
【网友回应】
A的码是银联商务，B的码是银行聚合生成，消费者用支付宝扫码支付
一类户绑定的问题，一类户绑定鉴权需要走小额鉴权接口，小额鉴权接口是非实时接口，7个工作日类异步通知。这个时候，当客户首次绑卡，第三方通道鉴权成功，小额鉴权还没返回的时候，二类户开户就存在风险。。。改死了
【网友回应】
A的码是银联商务，B的码是银行聚合生成，消费者用支付宝扫码支付
一类户绑定的问题，一类户绑定鉴权需要走小额鉴权接口，小额鉴权接口是非实时接口，7个工作日类异步通知。这个时候，当客户首次绑卡，第三方通道鉴权成功，小额鉴权还没返回的时候，二类户开户就存在风险。。。改死了
A的码是银联商务，B的码是银行聚合生成，消费者用支付宝扫码支付
一类户绑定的问题，一类户绑定鉴权需要走小额鉴权接口，小额鉴权接口是非实时接口，7个工作日类异步通知。这个时候，当客户首次绑卡，第三方通道鉴权成功，小额鉴权还没返回的时候，二类户开户就存在风险。。。改死了
哪个银行的超级网银系统较稳定，请推荐？
【网友回应】
都稳定
【网友回应】
都稳定
都稳定
一个支付代理公司资金做餐饮市场的订单支付，不想过度依赖支付公司，想自己做一套系统，不知道群里有做支付OEM(有售后服务）的吗？
OEM(Original Equipment Manufacturer）即原始设备制造商，ODM（Original Design Manufacturer）即原始设计制造商，OBM（Original Brand Manufacturer），即原始品牌制造商。A方看中B方的生产能力，让B方生产A方设计的产品，用A方商标。对B方来说，这叫OEM；A方的技术和设计，被B方看中，B方引进生产，贴上B方标签。对A方来说，这叫ODM；A自行创立A品牌，B生产、销售拥有A品牌的产品。对A来说，称为OBM。from百度百科
OEM(Original Equipment Manufacturer）即原始设备制造商，ODM（Original Design Manufacturer）即原始设计制造商，OBM（Original Brand Manufacturer），即原始品牌制造商。A方看中B方的生产能力，让B方生产A方设计的产品，用A方商标。对B方来说，这叫OEM；A方的技术和设计，被B方看中，B方引进生产，贴上B方标签。对A方来说，这叫ODM；A自行创立A品牌，B生产、销售拥有A品牌的产品。对A来说，称为OBM。from百度百科
【网友回应】
淘宝有源码
==Charle-跨境通-清结算PM== 算开发商，==交通银行==可以先接触
有专门的公司可以做OEM
【网友回应】
淘宝有源码
==Charle-跨境通-清结算PM== 算开发商，==交通银行==可以先接触
有专门的公司可以做OEM
淘宝有源码
==Charle-跨境通-清结算PM== 算开发商，==交通银行==可以先接触
有专门的公司可以做OEM
==老熊==能否举办线上/线下有关账户、账务、会计、结算主题的分享？
【老熊回应】
在规划这个事情。 场地什么的都好说，就得有人愿意分享。
总不能一堆人嗑瓜子聊天，效果就差了，得有个主题，大家分头分享下各自的工作。
这两个周还在陆续邀请大牛人入群。
下周开始规划这个事情。
微信群有上限限制，也需要控制群的质量；微信群有500的限制。目前收到的报名有1000多，现在是优先邀请 技术负责人、产品经理及以上的人员参与。
打算首先建立一个”居委会”，制定群管理制度，推动线上线下活动。
有兴趣同学私聊报名。
【网友回应】
我们还是保持纯粹的知识分享，刻意的严肃一些，保持内容的克制。 很多群后来又成吹水群了。
真正的大神是不吹水的。我们目前里面大神太多。好现象
收费是最好的机制，付费知识的意识需要培养。老师也不要不好意思。
版权很重要
金融的知识太碎了。每个环节的人知识结构都不一样。这几天我在这个群里看到的 偏底层和技术的知识比较多。==降峰-百度金融==偏金融前端金融场景多些。群主的知识偏核心底层。可以互补。
【资料分享】
金融类产品经理必知的设计原则
【老熊回应】
在规划这个事情。 场地什么的都好说，就得有人愿意分享。
总不能一堆人嗑瓜子聊天，效果就差了，得有个主题，大家分头分享下各自的工作。
这两个周还在陆续邀请大牛人入群。
下周开始规划这个事情。
微信群有上限限制，也需要控制群的质量；微信群有500的限制。目前收到的报名有1000多，现在是优先邀请 技术负责人、产品经理及以上的人员参与。
打算首先建立一个”居委会”，制定群管理制度，推动线上线下活动。
有兴趣同学私聊报名。
在规划这个事情。 场地什么的都好说，就得有人愿意分享。
总不能一堆人嗑瓜子聊天，效果就差了，得有个主题，大家分头分享下各自的工作。
这两个周还在陆续邀请大牛人入群。
下周开始规划这个事情。
微信群有上限限制，也需要控制群的质量；微信群有500的限制。目前收到的报名有1000多，现在是优先邀请 技术负责人、产品经理及以上的人员参与。
打算首先建立一个”居委会”，制定群管理制度，推动线上线下活动。
有兴趣同学私聊报名。
【网友回应】
我们还是保持纯粹的知识分享，刻意的严肃一些，保持内容的克制。 很多群后来又成吹水群了。
真正的大神是不吹水的。我们目前里面大神太多。好现象
收费是最好的机制，付费知识的意识需要培养。老师也不要不好意思。
版权很重要
金融的知识太碎了。每个环节的人知识结构都不一样。这几天我在这个群里看到的 偏底层和技术的知识比较多。==降峰-百度金融==偏金融前端金融场景多些。群主的知识偏核心底层。可以互补。
我们还是保持纯粹的知识分享，刻意的严肃一些，保持内容的克制。 很多群后来又成吹水群了。
真正的大神是不吹水的。我们目前里面大神太多。好现象
收费是最好的机制，付费知识的意识需要培养。老师也不要不好意思。
版权很重要
金融的知识太碎了。每个环节的人知识结构都不一样。这几天我在这个群里看到的 偏底层和技术的知识比较多。==降峰-百度金融==偏金融前端金融场景多些。群主的知识偏核心底层。可以互补。
【资料分享】
金融类产品经理必知的设计原则
金融类产品经理必知的设计原则
是否可以交流共享苹果IAP支付解决方案？
暂无回应
暂无回应
今年7月，中国IT项目管理大会，==安宇-丰瑞祥-北京==有推荐演讲名额，有感兴趣的讲师吗？
【背景描述】
资格：PMO
主题：去年讲敏捷项目管理，主要是项目管理的发展现状、特点、框架、敏捷落地等主题
【网友回应】
暂无回应
【背景描述】
资格：PMO
主题：去年讲敏捷项目管理，主要是项目管理的发展现状、特点、框架、敏捷落地等主题
资格：PMO
主题：去年讲敏捷项目管理，主要是项目管理的发展现状、特点、框架、敏捷落地等主题
【网友回应】
暂无回应
暂无回应
大限将至，群里有需求吗？
现在距离《网络借贷资金存管业务指引》的正式发布已过2个多月，而指引中所要求的8月大限也即将到来。网贷之家最新发布的《P2P平台银行存管进度报告》显示，截至5月8日，总计205家P2P网贷平台与银行完成直接存管系统对接并上线，占总平台数的比重不到10%。from凤凰网银行“高门槛”设阻P2P平台资金存管上线 第三方支付“搭桥”助提速
【网友回应】
现在银行都主动找p2p商户啊
领导想开了吧，银行也是帮大户们数钱而已啦??
支付公司服务的p2p平台账户体系整体部署到银行，量大从优？
现实版，当年对我爱理不理，现在让你高攀不起？
资金存管到银行，银行根据资金池规模收费，1000万以上每增一个梯度加钱的；大部分银行是这么收费的，也有是打包收费，根据规模收取不同的保证金~
现在距离《网络借贷资金存管业务指引》的正式发布已过2个多月，而指引中所要求的8月大限也即将到来。网贷之家最新发布的《P2P平台银行存管进度报告》显示，截至5月8日，总计205家P2P网贷平台与银行完成直接存管系统对接并上线，占总平台数的比重不到10%。from凤凰网银行“高门槛”设阻P2P平台资金存管上线 第三方支付“搭桥”助提速
【网友回应】
现在银行都主动找p2p商户啊
领导想开了吧，银行也是帮大户们数钱而已啦??
支付公司服务的p2p平台账户体系整体部署到银行，量大从优？
现实版，当年对我爱理不理，现在让你高攀不起？
资金存管到银行，银行根据资金池规模收费，1000万以上每增一个梯度加钱的；大部分银行是这么收费的，也有是打包收费，根据规模收取不同的保证金~
【网友回应】
现在银行都主动找p2p商户啊
领导想开了吧，银行也是帮大户们数钱而已啦??
支付公司服务的p2p平台账户体系整体部署到银行，量大从优？
现实版，当年对我爱理不理，现在让你高攀不起？
资金存管到银行，银行根据资金池规模收费，1000万以上每增一个梯度加钱的；大部分银行是这么收费的，也有是打包收费，根据规模收取不同的保证金~
现在银行都主动找p2p商户啊
领导想开了吧，银行也是帮大户们数钱而已啦??
支付公司服务的p2p平台账户体系整体部署到银行，量大从优？
现实版，当年对我爱理不理，现在让你高攀不起？
资金存管到银行，银行根据资金池规模收费，1000万以上每增一个梯度加钱的；大部分银行是这么收费的，也有是打包收费，根据规模收取不同的保证金~
有没有支付渠道比直接对接微信和支付宝便宜的？
【网友回应】
兴业银行好像便宜点，用他们的通道对接支付宝和微信
各个银行的微信支付宝通道成本价格都是一样的，给的政策和风控策略不一样而已。 看跑什么业务，选择不同的银行。
==李刚-芯火科技CEO==兴业福州和中信总银几家的移动支付系统是我们开发的，具体的可以私信聊
【网友回应】
兴业银行好像便宜点，用他们的通道对接支付宝和微信
各个银行的微信支付宝通道成本价格都是一样的，给的政策和风控策略不一样而已。 看跑什么业务，选择不同的银行。
==李刚-芯火科技CEO==兴业福州和中信总银几家的移动支付系统是我们开发的，具体的可以私信聊
兴业银行好像便宜点，用他们的通道对接支付宝和微信
各个银行的微信支付宝通道成本价格都是一样的，给的政策和风控策略不一样而已。 看跑什么业务，选择不同的银行。
==李刚-芯火科技CEO==兴业福州和中信总银几家的移动支付系统是我们开发的，具体的可以私信聊
业务BUG导致的资损，这个有啥策略可以在线上及时报警吗？
举个具体例子：比如100元的消费，由于平台打折实收95元，然后用户选择退款，平台按照100退款给用户。这时就资损了5元。
举个具体例子：比如100元的消费，由于平台打折实收95元，然后用户选择退款，平台按照100退款给用户。这时就资损了5元。
-【网友回应】
退款流程、逻辑和记账
业务bug导致的资损，balance检测，付多少退多少，实退金额是不可能大于实收金额的
退款流程有问题吧，不是按实际支付退啊？退款退的时候严格按照支付组成来，原路退回不就好了
这类的解决办法在于数据库字段的设计：数据库里记应付金额（总金额）和实际支付金额，记账，对账，退款都按照实际金额来做，应付金额只是保留用户支付时的快照信息
防资损失系统化工程，包括（1）事前、事中风控规则；（2）事中系统监控报警，（3）事后资金对账，财务核算
订单的金额，记录的肯定是抛到银行的金额 也就是最后扣用户的多少钱 那么退款肯定也是以这个金额为准；所以肯定是要设计一个字段记录实际交易金额 因为如果你直接记录100的 对账都会出问题
100元是业务订单记录，由于打折优惠券等原因，实际对应的支付订单金额95元，用户如果是用支付宝支付这95元，发起退款的时候填写大于95元的金额是会报错的，所以不会出现资损5元的情况
这5块应该是有一个营销活动账户进行补贴的，不然你在清算的时候，会计账务不平的。。。所以最后退款肯定也是退95，这5块钱营销费用看是否需要退还
如果是打折，退款退95，如果是优惠券，那就是优惠券的逻辑，全额退款的时候是否把优惠券退回到用户的账户里
如果要退优惠券，那设计逻辑就是：记录实际交易金额+优惠券类型+优惠券金额，当用户发起全额退款的时候，所有东西原路退回，应该是这个逻辑
如果支持部分退款，肯定需要分拆单退吧~
建议体验京东、淘宝的流程
营销账户出账，退款的时候须退回营销账户的钱，这属于支付驱动账会机制。 但是，是否再发放优惠券，属于营销的业务逻辑范畴
退款手续费、恶意退款风控
退款扣手续费没节操
退款一般都退手续费，竟然还有扣费的？
退款不能扣手续费，必须退回
淘宝当年出现的拍了退，算是恶意的吧，后来到没听说过
扣手续肯定是要的。就看谁出这个钱，目前一般都是平台出的，也有扣商家的
超过通道退款周期限制，没法自动退款的，一般走转账接口给用户发起一笔转账，支付宝微信银联都有对应的B2C转账接口；银联代付，2块钱一笔
我接触的，第三方支付平台在没有结算之前退款是不收手续费的
退款收手续费，要看他退款实现方式，到底是原路退回的退款，还是通过提现。比如用户分多个渠道（微信、支付宝、线下打款等）支付多笔的充值，退款的时候如果一笔退，一般来说会是统一走提现代付，就会收手续费
【资料共享】
风控核心知识点
退款流程、逻辑和记账
业务bug导致的资损，balance检测，付多少退多少，实退金额是不可能大于实收金额的
退款流程有问题吧，不是按实际支付退啊？退款退的时候严格按照支付组成来，原路退回不就好了
这类的解决办法在于数据库字段的设计：数据库里记应付金额（总金额）和实际支付金额，记账，对账，退款都按照实际金额来做，应付金额只是保留用户支付时的快照信息
防资损失系统化工程，包括（1）事前、事中风控规则；（2）事中系统监控报警，（3）事后资金对账，财务核算
订单的金额，记录的肯定是抛到银行的金额 也就是最后扣用户的多少钱 那么退款肯定也是以这个金额为准；所以肯定是要设计一个字段记录实际交易金额 因为如果你直接记录100的 对账都会出问题
100元是业务订单记录，由于打折优惠券等原因，实际对应的支付订单金额95元，用户如果是用支付宝支付这95元，发起退款的时候填写大于95元的金额是会报错的，所以不会出现资损5元的情况
这5块应该是有一个营销活动账户进行补贴的，不然你在清算的时候，会计账务不平的。。。所以最后退款肯定也是退95，这5块钱营销费用看是否需要退还
如果是打折，退款退95，如果是优惠券，那就是优惠券的逻辑，全额退款的时候是否把优惠券退回到用户的账户里
如果要退优惠券，那设计逻辑就是：记录实际交易金额+优惠券类型+优惠券金额，当用户发起全额退款的时候，所有东西原路退回，应该是这个逻辑
如果支持部分退款，肯定需要分拆单退吧~
建议体验京东、淘宝的流程
营销账户出账，退款的时候须退回营销账户的钱，这属于支付驱动账会机制。 但是，是否再发放优惠券，属于营销的业务逻辑范畴
业务bug导致的资损，balance检测，付多少退多少，实退金额是不可能大于实收金额的
退款流程有问题吧，不是按实际支付退啊？退款退的时候严格按照支付组成来，原路退回不就好了
这类的解决办法在于数据库字段的设计：数据库里记应付金额（总金额）和实际支付金额，记账，对账，退款都按照实际金额来做，应付金额只是保留用户支付时的快照信息
防资损失系统化工程，包括（1）事前、事中风控规则；（2）事中系统监控报警，（3）事后资金对账，财务核算
订单的金额，记录的肯定是抛到银行的金额 也就是最后扣用户的多少钱 那么退款肯定也是以这个金额为准；所以肯定是要设计一个字段记录实际交易金额 因为如果你直接记录100的 对账都会出问题
100元是业务订单记录，由于打折优惠券等原因，实际对应的支付订单金额95元，用户如果是用支付宝支付这95元，发起退款的时候填写大于95元的金额是会报错的，所以不会出现资损5元的情况
这5块应该是有一个营销活动账户进行补贴的，不然你在清算的时候，会计账务不平的。。。所以最后退款肯定也是退95，这5块钱营销费用看是否需要退还
如果是打折，退款退95，如果是优惠券，那就是优惠券的逻辑，全额退款的时候是否把优惠券退回到用户的账户里
如果要退优惠券，那设计逻辑就是：记录实际交易金额+优惠券类型+优惠券金额，当用户发起全额退款的时候，所有东西原路退回，应该是这个逻辑
如果支持部分退款，肯定需要分拆单退吧~
建议体验京东、淘宝的流程
营销账户出账，退款的时候须退回营销账户的钱，这属于支付驱动账会机制。 但是，是否再发放优惠券，属于营销的业务逻辑范畴
退款手续费、恶意退款风控
退款扣手续费没节操
退款一般都退手续费，竟然还有扣费的？
退款不能扣手续费，必须退回
淘宝当年出现的拍了退，算是恶意的吧，后来到没听说过
扣手续肯定是要的。就看谁出这个钱，目前一般都是平台出的，也有扣商家的
超过通道退款周期限制，没法自动退款的，一般走转账接口给用户发起一笔转账，支付宝微信银联都有对应的B2C转账接口；银联代付，2块钱一笔
我接触的，第三方支付平台在没有结算之前退款是不收手续费的
退款收手续费，要看他退款实现方式，到底是原路退回的退款，还是通过提现。比如用户分多个渠道（微信、支付宝、线下打款等）支付多笔的充值，退款的时候如果一笔退，一般来说会是统一走提现代付，就会收手续费
退款扣手续费没节操
退款一般都退手续费，竟然还有扣费的？
退款不能扣手续费，必须退回
淘宝当年出现的拍了退，算是恶意的吧，后来到没听说过
扣手续肯定是要的。就看谁出这个钱，目前一般都是平台出的，也有扣商家的
超过通道退款周期限制，没法自动退款的，一般走转账接口给用户发起一笔转账，支付宝微信银联都有对应的B2C转账接口；银联代付，2块钱一笔
我接触的，第三方支付平台在没有结算之前退款是不收手续费的
退款收手续费，要看他退款实现方式，到底是原路退回的退款，还是通过提现。比如用户分多个渠道（微信、支付宝、线下打款等）支付多笔的充值，退款的时候如果一笔退，一般来说会是统一走提现代付，就会收手续费
【资料共享】
风控核心知识点
风控核心知识点
跨境支付的扣率一般是多少？
暂无回应
暂无回应
谁家接入银联支付的wap，点击返回键无法跳转回来？
【背景描述】
正常支付的时候可以跳转回来，如果用户没正常进行支付，点击微信的返回键，无法返回。
H5页面，没有页头，走的银联wap支付通道。用微信打开，付款时跳银联wap支付页面，支付成功正常返回。若没支付，点击微信的返回，无效。 求解。。
【网友回应】
同步返回URL是不是没传？
【背景描述】
正常支付的时候可以跳转回来，如果用户没正常进行支付，点击微信的返回键，无法返回。
H5页面，没有页头，走的银联wap支付通道。用微信打开，付款时跳银联wap支付页面，支付成功正常返回。若没支付，点击微信的返回，无效。 求解。。
正常支付的时候可以跳转回来，如果用户没正常进行支付，点击微信的返回键，无法返回。
H5页面，没有页头，走的银联wap支付通道。用微信打开，付款时跳银联wap支付页面，支付成功正常返回。若没支付，点击微信的返回，无效。 求解。。
【网友回应】
同步返回URL是不是没传？
同步返回URL是不是没传？
没有规矩不成方圆，我们聊一聊群规吧？ ==老熊== 我们需要先讨论下版规。没有规矩，不成方圆。有意见请提出来做修正，如无意见即视为赞同。
本群建设目标是为从事互联网支付的产品经理、开发工程师、管理人员提供交流平台。
群中禁止发表政治言论、广告以及和支付无关的话题。 禁止灌水行为，禁止谩骂，禁止发表人身攻击言论。 有上述违规行为，群主有权将该账号移出本群。
所有人员必须将昵称修改为 姓名/花名-公司-岗位-地区。对不合规人员，经1次提醒后，仍未修改者，群主有权将该账号移出本群。
新入群要求：采用推荐制，必须得到群里至少一位成员的推荐才可以入群。 每人可以推荐的人数上限为2人。
第4条，让大家珍惜推荐权; 考虑每个月移除不发言的人员2人
有了解天猫店铺和支付宝之间关系的吗？
比如一个公司有两个天猫店铺，一个企业支付宝账户，店铺在用支付宝余额支付时，需要店铺的主账户和支付宝进行绑定吗？
比如一个公司有两个天猫店铺，一个企业支付宝账户，店铺在用支付宝余额支付时，需要店铺的主账户和支付宝进行绑定吗？
【网友回应】
在支付宝存在管理员和操作员的逻辑吗？管理员能够操作这两个店铺的钱吗？
【网友回应】
在支付宝存在管理员和操作员的逻辑吗？管理员能够操作这两个店铺的钱吗？
在支付宝存在管理员和操作员的逻辑吗？管理员能够操作这两个店铺的钱吗？
请问公司开展聚合支付是否需要什么资质呀？央行是否有相关要求
聚合支付也称“融合支付”，是指只从事“支付、结算、清算”服务之外的“支付服务”，依托银行、非银机构或清算组织，借助银行、非银机构或清算组织的支付通道与清结算能力，利用自身的技术与服务集成能力，将一个以上的银行、非银机构或清算组织的支付服务，整合到一起，为商户提供包括但不限于“支付通道服务”、“集合对账服务”、“技术对接服务”、“差错处理服务”、“金融服务引导”、“会员账户服务”、“作业流程软件服务”、“运行维护服务”、“终端提供与维护”等服务内容，以此减少商户接入、维护支付结算服务时面临的成本支出，提高商户支付结算系统运行效率的，并收取增值收益的支付服务。from 百度百科
聚合支付也称“融合支付”，是指只从事“支付、结算、清算”服务之外的“支付服务”，依托银行、非银机构或清算组织，借助银行、非银机构或清算组织的支付通道与清结算能力，利用自身的技术与服务集成能力，将一个以上的银行、非银机构或清算组织的支付服务，整合到一起，为商户提供包括但不限于“支付通道服务”、“集合对账服务”、“技术对接服务”、“差错处理服务”、“金融服务引导”、“会员账户服务”、“作业流程软件服务”、“运行维护服务”、“终端提供与维护”等服务内容，以此减少商户接入、维护支付结算服务时面临的成本支出，提高商户支付结算系统运行效率的，并收取增值收益的支付服务。from 百度百科
【类似问题】
各位大神。请教下有支付牌照，但业务是在互联网支付和预付卡发行的资质，能做聚合支付线下扫码支付吗？
【网友回应】
聚合支付就是把多家的支付能力聚合在一个产品上，不需要为了多个支付工具，使用多个收款产品，比如一码多付、一机多付
聚合好像不需要什么资质 就是不要做二清就好
聚合 央妈看的紧
目前最大的聚合就是拉卡拉的收钱吧
聚合支付线下核心就是代理商，没有强大地推团队，别玩了
做线下聚合，需要有线下收单资质，就是银行卡收单
有支付牌照能不能做聚合 不讨论包装问题，就说合不合规 因为我隐隐约约记得之前看到过相关文件说，有牌照的第三方支付不能做聚合，就像支付宝不能接微信一样，防止垄断市场
应该说是央行规定第三方支付之间不能直连合作，因为这条的限制第三方支付机构直接做聚合可能涉及违规
聚合支付不做商户清算，我觉得都没有什么意义，不能形成资金池，也没有什么好的盈利模式，单靠手续费差，太少了
聚合支付主要的盈利点，除了微薄的手续费，还有无孔不入的广告，比如，微信公众号的支付结果提醒，有广告；支付成功页有广告
聚合支付只是融合了支付通道并且提供了平台，不涉及清算就不是二清的
如果聚合支付平台的最终支撑方是收单机构或是银行，那是可以涉及到清算，也是合法的；
一般聚合支付会落地到银行清算的，不管实际银行怎么清算，威富通就是对接了银行以后火的
【类似问题】
各位大神。请教下有支付牌照，但业务是在互联网支付和预付卡发行的资质，能做聚合支付线下扫码支付吗？
各位大神。请教下有支付牌照，但业务是在互联网支付和预付卡发行的资质，能做聚合支付线下扫码支付吗？
【网友回应】
聚合支付就是把多家的支付能力聚合在一个产品上，不需要为了多个支付工具，使用多个收款产品，比如一码多付、一机多付
聚合好像不需要什么资质 就是不要做二清就好
聚合 央妈看的紧
目前最大的聚合就是拉卡拉的收钱吧
聚合支付线下核心就是代理商，没有强大地推团队，别玩了
做线下聚合，需要有线下收单资质，就是银行卡收单
有支付牌照能不能做聚合 不讨论包装问题，就说合不合规 因为我隐隐约约记得之前看到过相关文件说，有牌照的第三方支付不能做聚合，就像支付宝不能接微信一样，防止垄断市场
应该说是央行规定第三方支付之间不能直连合作，因为这条的限制第三方支付机构直接做聚合可能涉及违规
聚合支付不做商户清算，我觉得都没有什么意义，不能形成资金池，也没有什么好的盈利模式，单靠手续费差，太少了
聚合支付主要的盈利点，除了微薄的手续费，还有无孔不入的广告，比如，微信公众号的支付结果提醒，有广告；支付成功页有广告
聚合支付只是融合了支付通道并且提供了平台，不涉及清算就不是二清的
如果聚合支付平台的最终支撑方是收单机构或是银行，那是可以涉及到清算，也是合法的；
一般聚合支付会落地到银行清算的，不管实际银行怎么清算，威富通就是对接了银行以后火的
聚合支付就是把多家的支付能力聚合在一个产品上，不需要为了多个支付工具，使用多个收款产品，比如一码多付、一机多付
聚合好像不需要什么资质 就是不要做二清就好
聚合 央妈看的紧
目前最大的聚合就是拉卡拉的收钱吧
聚合支付线下核心就是代理商，没有强大地推团队，别玩了
做线下聚合，需要有线下收单资质，就是银行卡收单
有支付牌照能不能做聚合 不讨论包装问题，就说合不合规 因为我隐隐约约记得之前看到过相关文件说，有牌照的第三方支付不能做聚合，就像支付宝不能接微信一样，防止垄断市场
应该说是央行规定第三方支付之间不能直连合作，因为这条的限制第三方支付机构直接做聚合可能涉及违规
聚合支付不做商户清算，我觉得都没有什么意义，不能形成资金池，也没有什么好的盈利模式，单靠手续费差，太少了
聚合支付主要的盈利点，除了微薄的手续费，还有无孔不入的广告，比如，微信公众号的支付结果提醒，有广告；支付成功页有广告
聚合支付只是融合了支付通道并且提供了平台，不涉及清算就不是二清的
如果聚合支付平台的最终支撑方是收单机构或是银行，那是可以涉及到清算，也是合法的；
一般聚合支付会落地到银行清算的，不管实际银行怎么清算，威富通就是对接了银行以后火的
【小编补充】
关于聚合支付的合规性和边界性问题，大家争议较多；由于小编并未对细节进行校对，仅供参考，希望大家校订完善
【资料共享】
【小编补充】
关于聚合支付的合规性和边界性问题，大家争议较多；由于小编并未对细节进行校对，仅供参考，希望大家校订完善
【资料共享】
关于聚合支付的合规性和边界性问题，大家争议较多；由于小编并未对细节进行校对，仅供参考，希望大家校订完善
【资料共享】
31 聚合产品积分抵扣
聚合产品谁有做积分抵扣的？
【网友回应】
聚合做这个不太好做，联动很多的
群里有ping++的同学
【网友回应】
聚合做这个不太好做，联动很多的
群里有ping++的同学
聚合做这个不太好做，联动很多的
群里有ping++的同学
有谁了解什么情况使用过渡户、什么情况使用冻结解冻吗？ 想评估下两种方案优劣，不一定要走过渡户~
账务层面的， 例如商家提现场景，有两种解决方案：
冻结商家余额账户（资金从可用余额到不可用余额）-》调用第三方-》解冻商家余额账户
商家余额账户转账给提现过渡户（内部户，类似余额账户）->调用第三方，如果第三方失败，则提现过渡户转账给商家余额账户
-【网友回应】
先有业务再冻结，调用第三方接口返回最终状态再解冻下账。
是资金记录，如果走过渡户，我可以通过过渡户发现问题以及通过过渡户中资金余额，判断是否可以进行其他业务，例如资金调拨
你的业务场景需要走过渡户？需要分类的话，那就把每个业务分一个类型，每种类型的冻结、解冻等分开。 那就先冻结发起方，然后调用你们系统内部的转账，转账到过渡户成功、过渡户马上冻结，然后调用第三方接口，返回最终结果后，过渡户再冻结下账
先有业务再冻结，调用第三方接口返回最终状态再解冻下账。
是资金记录，如果走过渡户，我可以通过过渡户发现问题以及通过过渡户中资金余额，判断是否可以进行其他业务，例如资金调拨
你的业务场景需要走过渡户？需要分类的话，那就把每个业务分一个类型，每种类型的冻结、解冻等分开。 那就先冻结发起方，然后调用你们系统内部的转账，转账到过渡户成功、过渡户马上冻结，然后调用第三方接口，返回最终结果后，过渡户再冻结下账
支付宝有代分润，微信有代分润能力吗
这个是代理商的分润，只有你是总代理或者支付机构才需要的系统，多级分销
也是避免二清（二次清算，现在的代付业务），不碰钱
不二请，其实就是个技术服务商，最多做做云服务saas，没啥意义
没有支付牌照，但有资金沉淀的，所谓的大商户模式，都可以叫二清
这个是代理商的分润，只有你是总代理或者支付机构才需要的系统，多级分销
也是避免二清（二次清算，现在的代付业务），不碰钱
不二请，其实就是个技术服务商，最多做做云服务saas，没啥意义
没有支付牌照，但有资金沉淀的，所谓的大商户模式，都可以叫二清
关于线上和线下收单的界定和应用？
收单业务from百度百科
银行卡收单业务是指签约银行向商户提供的本外币资金结算服务。 通俗讲就是我们在银行签约商户那里刷卡消费，银行将你刷卡消费的资金在规定周期内结算给商户，并从中扣取一定比例的手续费。
信用卡收单同银行卡收单的过程是一样的。
收单业务from百度百科
银行卡收单业务是指签约银行向商户提供的本外币资金结算服务。 通俗讲就是我们在银行签约商户那里刷卡消费，银行将你刷卡消费的资金在规定周期内结算给商户，并从中扣取一定比例的手续费。
信用卡收单同银行卡收单的过程是一样的。
收单分为： 1)线上收单，即网络收单 2)线下收单，即非网络收单 ① pos收单 ：参与的有各收单行(如工行、建行、交行等)、银联商务、通联支付，数字王府井、广东汉鑫、上海杉德。 ②ATM收单 银行卡收单机构是指经各信用卡组织授权办理特约商店签约事宜，并与特约商店清款时先行垫付持卡人交易账款的金融服务机构。
现在的线下收单，应该有两种吧，银行卡收单和线下扫码收单
牌照来说，有银行卡收单牌照，有第三方支付牌照，有什么预付卡牌照
扫码支付属于线上支付。。
这个是有央行的文件定义的
现在的线下收单，应该有两种吧，银行卡收单和线下扫码收单
牌照来说，有银行卡收单牌照，有第三方支付牌照，有什么预付卡牌照
扫码支付属于线上支付。。
这个是有央行的文件定义的
支付清结算的入门级理解？
【网友回应】
账户系统通常管账户属性。账户类型，账户等级，账户状态，什么账户做什么事～
==纯-随行付-PM== ：我之前的一家支付公司的清算和结算是分开的，清算是各个商户往来算轧差后，由结算这边做付款。
对账只是清结算的一个模块
账户账务会计系统只是清洁算系统的辅助系统啊，和清算系统和结算系统是分开的
会计科目的核对，主要是财务用
我理解的账务就是流水按财务科目分类和统计，清结算按主体分类和统计
清分、清算、结算，每个都是一个过程，不是动作；清分过程就是分类汇总流水分录为清算做准备；清算过程是净额轧差资金调拨；生成清算账单为结算做准备等；结算过程根据清算结果对客户资金进行资金调拨打款
简单说，清洁算可不可以这么理解。字面意思，清算是算平台应该付多少钱，结算是平台实际支付资金。
其实清算不涉及资金划转，结算则涉及到平台资金划拨
清算划转的是自己公司内部备付金账户的资金，结算是给商户划转钱
清算：凡是直接或者间接接入中国清算体系的机构之间资金的划转；结算：指的是 这些机构同其商户直接的资金结转
中国清结算系统，还是参考银联吧，跨行清算很标准
做支付，没有清结算和风控的工作经历很吃亏啊
人人心中都有一套清结算概念，清结算的业务逻辑要根据公司的具体业务决定
其实咱们群里可以引入一些财务专业人士，支付结算都是财务基础知识
电子化的现在反倒不一定都是财务基础知识了
==陈琳中移动PM== ：我以前在银行，记得我们领导说银行的核心就是一本账，我想类金融的业务应该也都是这一本账
【储备】
【清算&结算】
【对账】
【账户】
【资料共享】
凤凰牌老熊的博客
中国支付清算网络体系总体架构图
知乎-网上支付跨行清算系统与大小额支付系统有什么区别？
支付宝账务核心总体业务架构（附件可预览/下载）
网友反馈这个是老版本，目前支付宝架构已调整，仅供参考
【网友回应】
账户系统通常管账户属性。账户类型，账户等级，账户状态，什么账户做什么事～
==纯-随行付-PM== ：我之前的一家支付公司的清算和结算是分开的，清算是各个商户往来算轧差后，由结算这边做付款。
对账只是清结算的一个模块
账户账务会计系统只是清洁算系统的辅助系统啊，和清算系统和结算系统是分开的
会计科目的核对，主要是财务用
我理解的账务就是流水按财务科目分类和统计，清结算按主体分类和统计
清分、清算、结算，每个都是一个过程，不是动作；清分过程就是分类汇总流水分录为清算做准备；清算过程是净额轧差资金调拨；生成清算账单为结算做准备等；结算过程根据清算结果对客户资金进行资金调拨打款
简单说，清洁算可不可以这么理解。字面意思，清算是算平台应该付多少钱，结算是平台实际支付资金。
其实清算不涉及资金划转，结算则涉及到平台资金划拨
清算划转的是自己公司内部备付金账户的资金，结算是给商户划转钱
清算：凡是直接或者间接接入中国清算体系的机构之间资金的划转；结算：指的是 这些机构同其商户直接的资金结转
中国清结算系统，还是参考银联吧，跨行清算很标准
做支付，没有清结算和风控的工作经历很吃亏啊
人人心中都有一套清结算概念，清结算的业务逻辑要根据公司的具体业务决定
其实咱们群里可以引入一些财务专业人士，支付结算都是财务基础知识
电子化的现在反倒不一定都是财务基础知识了
==陈琳中移动PM== ：我以前在银行，记得我们领导说银行的核心就是一本账，我想类金融的业务应该也都是这一本账
【储备】
【清算&结算】
【对账】
【账户】
账户系统通常管账户属性。账户类型，账户等级，账户状态，什么账户做什么事～
==纯-随行付-PM== ：我之前的一家支付公司的清算和结算是分开的，清算是各个商户往来算轧差后，由结算这边做付款。
对账只是清结算的一个模块
账户账务会计系统只是清洁算系统的辅助系统啊，和清算系统和结算系统是分开的
会计科目的核对，主要是财务用
我理解的账务就是流水按财务科目分类和统计，清结算按主体分类和统计
清分、清算、结算，每个都是一个过程，不是动作；清分过程就是分类汇总流水分录为清算做准备；清算过程是净额轧差资金调拨；生成清算账单为结算做准备等；结算过程根据清算结果对客户资金进行资金调拨打款
简单说，清洁算可不可以这么理解。字面意思，清算是算平台应该付多少钱，结算是平台实际支付资金。
其实清算不涉及资金划转，结算则涉及到平台资金划拨
清算划转的是自己公司内部备付金账户的资金，结算是给商户划转钱
清算：凡是直接或者间接接入中国清算体系的机构之间资金的划转；结算：指的是 这些机构同其商户直接的资金结转
中国清结算系统，还是参考银联吧，跨行清算很标准
做支付，没有清结算和风控的工作经历很吃亏啊
人人心中都有一套清结算概念，清结算的业务逻辑要根据公司的具体业务决定
其实咱们群里可以引入一些财务专业人士，支付结算都是财务基础知识
电子化的现在反倒不一定都是财务基础知识了
==陈琳中移动PM== ：我以前在银行，记得我们领导说银行的核心就是一本账，我想类金融的业务应该也都是这一本账
【储备】
【清算&结算】
【对账】
【账户】
【资料共享】
凤凰牌老熊的博客
中国支付清算网络体系总体架构图
知乎-网上支付跨行清算系统与大小额支付系统有什么区别？
支付宝账务核心总体业务架构（附件可预览/下载）
网友反馈这个是老版本，目前支付宝架构已调整，仅供参考
凤凰牌老熊的博客
中国支付清算网络体系总体架构图
知乎-网上支付跨行清算系统与大小额支付系统有什么区别？
支付宝账务核心总体业务架构（附件可预览/下载）
网友反馈这个是老版本，目前支付宝架构已调整，仅供参考
网友反馈这个是老版本，目前支付宝架构已调整，仅供参考
想问下微信和支付宝用户主扫模式，如何判断C端付款是用的贷记卡还是借记卡（因为这个会触碰到微信和支付宝的风控，容易被封通道）？
【网友回应】
卡bin库
微信支付宝会异步通知你的
卡号微信支付宝不会给你的 只给你银行信息
【网友回应】
卡bin库
微信支付宝会异步通知你的
卡号微信支付宝不会给你的 只给你银行信息
卡bin库
微信支付宝会异步通知你的
卡号微信支付宝不会给你的 只给你银行信息
微信可以控制C端只用借记卡，如何实现的？
【网友回应】
支付类型吧，毕竟信用卡不能用于转账等
去看看微信支付的官方接口文档吧
财付通有自己的支付控制的，关于信用卡还是借记卡
卡bin可以区分卡类型是借记还是贷记
【资料共享】
微信支付接口-指定支付方式截图
【网友回应】
支付类型吧，毕竟信用卡不能用于转账等
去看看微信支付的官方接口文档吧
财付通有自己的支付控制的，关于信用卡还是借记卡
卡bin可以区分卡类型是借记还是贷记
支付类型吧，毕竟信用卡不能用于转账等
去看看微信支付的官方接口文档吧
财付通有自己的支付控制的，关于信用卡还是借记卡
卡bin可以区分卡类型是借记还是贷记
【资料共享】
微信支付接口-指定支付方式截图
微信支付接口-指定支付方式截图
账户系统的账户凭证以及分录，导入会计系统的凭证和分录，怎么对应会计科目？
暂无回应（有超过4人表示出强烈期待）
暂无回应（有超过4人表示出强烈期待）
我们在群里是否可以每天划定主题，集中交流讨论一类问题，多维讨论刷不过来？怎么样才能把聊天的精华内容记录下来，让没参与聊天的人回头可以翻看。。 ？
每天一个话题是个好主意。支付的每个模块都是大话题，一聊就容易分散。
论的主题可以提前几天订哈，先预习和准备一下
可以一周两次主题讨论，每天的话估计强度太大，约定一个时间正是开始，然后整理总结
每天信息量好大啊，根本来不及学习
每天一个话题是个好主意。支付的每个模块都是大话题，一聊就容易分散。
论的主题可以提前几天订哈，先预习和准备一下
可以一周两次主题讨论，每天的话估计强度太大，约定一个时间正是开始，然后整理总结
每天信息量好大啊，根本来不及学习
有个问题，对账要求银行和自己业务数据的完整性，实际情况中，双方有一方漏推的情况时有发生。在这种情况下，如何设计对账比较好？
【网友回应】
漏推是你对账之后的结果，只有对账后你才会发现双方的数据是否一致，对账就是要找出这个差异出来
对账其实只要双方都核对成功的流水就可以了，就可以把单边账，多账和少账对出来，一般对账都是t＋1
我们是专门招了一个对账的，每天把银行的数据下载下来，之后和平台对，出现有问题的，以银行为准，勾兑解决 （这种是对于没有实时勾兑功能的，如果银行有实时勾兑，如果调单了 一般是收到用户投诉，再和银行确定）
对账应该分内部对账和外部对账吧
这种情况下需要先挂起，T+1日再对一下，如果还是有，就应该是单边账了吧。
对账每日增加批次号，支持重新对账，然后每次新增记录，记录每条流水各批次的对账结果，以最后一次定义状态吧
最容易出现掉单，就是银行那边升级我们这边没收到通知，之后交易又抛过去了，银行那边处理了，但是又没返回结果，这样平台这边超时了 直接失败，可以银行已经成功扣款
缓冲对账，让正常到了的账单先跑完，最好以渠道方的批次为准核对 下一轮继续核对；对账最繁琐的是，长短款的追偿、暂扣、挂账、释放、退款这些流程
根据发起方流水或者受理方跟踪号对账，每个渠道对账的字段不一样
各个渠道任意时间自己对自己的，清算依据来源于交易的单笔流水查复的状态，这样白天的交易在查复以后就可以清算，对账只是晚上核对流水和记录差错人工服务用的（查复就是在交易完成后，间隔时间去针对流水进行流水状态复查 ），1小时查1次，一般一天差错只有1-2笔，异常交易和平账都要查复，只要查复有结果终态，就可以进入清算流程了；
清算和对账的先后顺序：平台支付垫付，就可以实时清算，T+N日后对账没问题，类似于银行的即时到账，即时清算。（公司垫付模式，需要有银行授信账户或者银行备付金 ）
虚拟商品，会所预付款类的商户，不适合D0，连T0都不适合
【网友回应】
漏推是你对账之后的结果，只有对账后你才会发现双方的数据是否一致，对账就是要找出这个差异出来
对账其实只要双方都核对成功的流水就可以了，就可以把单边账，多账和少账对出来，一般对账都是t＋1
我们是专门招了一个对账的，每天把银行的数据下载下来，之后和平台对，出现有问题的，以银行为准，勾兑解决 （这种是对于没有实时勾兑功能的，如果银行有实时勾兑，如果调单了 一般是收到用户投诉，再和银行确定）
对账应该分内部对账和外部对账吧
这种情况下需要先挂起，T+1日再对一下，如果还是有，就应该是单边账了吧。
对账每日增加批次号，支持重新对账，然后每次新增记录，记录每条流水各批次的对账结果，以最后一次定义状态吧
最容易出现掉单，就是银行那边升级我们这边没收到通知，之后交易又抛过去了，银行那边处理了，但是又没返回结果，这样平台这边超时了 直接失败，可以银行已经成功扣款
缓冲对账，让正常到了的账单先跑完，最好以渠道方的批次为准核对 下一轮继续核对；对账最繁琐的是，长短款的追偿、暂扣、挂账、释放、退款这些流程
根据发起方流水或者受理方跟踪号对账，每个渠道对账的字段不一样
各个渠道任意时间自己对自己的，清算依据来源于交易的单笔流水查复的状态，这样白天的交易在查复以后就可以清算，对账只是晚上核对流水和记录差错人工服务用的（查复就是在交易完成后，间隔时间去针对流水进行流水状态复查 ），1小时查1次，一般一天差错只有1-2笔，异常交易和平账都要查复，只要查复有结果终态，就可以进入清算流程了；
清算和对账的先后顺序：平台支付垫付，就可以实时清算，T+N日后对账没问题，类似于银行的即时到账，即时清算。（公司垫付模式，需要有银行授信账户或者银行备付金 ）
虚拟商品，会所预付款类的商户，不适合D0，连T0都不适合
漏推是你对账之后的结果，只有对账后你才会发现双方的数据是否一致，对账就是要找出这个差异出来
对账其实只要双方都核对成功的流水就可以了，就可以把单边账，多账和少账对出来，一般对账都是t＋1
我们是专门招了一个对账的，每天把银行的数据下载下来，之后和平台对，出现有问题的，以银行为准，勾兑解决 （这种是对于没有实时勾兑功能的，如果银行有实时勾兑，如果调单了 一般是收到用户投诉，再和银行确定）
对账应该分内部对账和外部对账吧
这种情况下需要先挂起，T+1日再对一下，如果还是有，就应该是单边账了吧。
对账每日增加批次号，支持重新对账，然后每次新增记录，记录每条流水各批次的对账结果，以最后一次定义状态吧
最容易出现掉单，就是银行那边升级我们这边没收到通知，之后交易又抛过去了，银行那边处理了，但是又没返回结果，这样平台这边超时了 直接失败，可以银行已经成功扣款
缓冲对账，让正常到了的账单先跑完，最好以渠道方的批次为准核对 下一轮继续核对；对账最繁琐的是，长短款的追偿、暂扣、挂账、释放、退款这些流程
根据发起方流水或者受理方跟踪号对账，每个渠道对账的字段不一样
各个渠道任意时间自己对自己的，清算依据来源于交易的单笔流水查复的状态，这样白天的交易在查复以后就可以清算，对账只是晚上核对流水和记录差错人工服务用的（查复就是在交易完成后，间隔时间去针对流水进行流水状态复查 ），1小时查1次，一般一天差错只有1-2笔，异常交易和平账都要查复，只要查复有结果终态，就可以进入清算流程了；
清算和对账的先后顺序：平台支付垫付，就可以实时清算，T+N日后对账没问题，类似于银行的即时到账，即时清算。（公司垫付模式，需要有银行授信账户或者银行备付金 ）
虚拟商品，会所预付款类的商户，不适合D0，连T0都不适合
电商交易清算金额每笔都很小,想了解大宗交易特别是采购这种大宗商品的时候，供货商，平台，车队，司机，这种多方参与的时候，清算分润咋设计的?
电商交易清算金额每笔都很小,想了解大宗交易特别是采购这种大宗商品的时候，供货商，平台，车队，司机，这种多方参与的时候，清算分润咋设计的?
【网友回应】
拿一笔债券交易来说，主要分为3种情况吧，交易双方都是支付系统直接成员，不是直接成员。A，向B购买债券，系统检查B债券是否足额，如果足额，将B的债券从可用科目，划分到冻结科目。交易处在等款的状态
A通过大额支付系统向A在我们公司的资金账户汇入相应的资金。后台有一个一直运行的守护线程类似的系统。在A的资金到位后，实行债权和资金的划分。资金划拨到B在我们公司的资金账户里头；如果A资金不到位，过期交易失败，债券从冻结变可用。如果B债券不足，A的资金原路退回。
汇路一般由客户自己维护。因为只要券足和款足，我们就直接进行资金和债券的交割。对应也能直接反映到相应银行在央行的帐上。所以交割基本上是T+0 ；如果是个人参与者的话，就必须通过有结算资质的银行来代理相应的资金操作，就是之前债市风暴的丙类户。
我们的对账，主要是内部对账和外部对账。首先借贷双方必相等。其次跟大额支付系统这些外部渠道的账务必相等。流水也得和内部的账务进行对账，基本就是这个流程。大家觉得厉害的公开市场操作，正回购，逆回购也是基于这套业务逻辑衍生出来的。
虚拟账户我们分资产的账务，簿记系统，资金的账户，资金管理系统，出现过汇错款的情况，但是好在银行间市场，款项的追回比较容易。我们的这些架构适合机构间的业务
一个机构在我们这有可能有很多资金账户。个人投资者也有代理的关系在里头，汇路说白了，就是从哪转到哪；汇路就是路径（这是我们的叫法）
我负责的事全国银行业信贷资产登记流转系统的整体系统建设，最近正要做一套资金和支付系统，所以也正想怎么结合公司的资金和支付系统。
在我们类似于交易所的单位里头，资产账务，涉及到的权益，登记的是债券，所以资产里就有发行人和债权人；而且为了支持各种业务，资产的科目比资金的复杂，大概有小20个科目，数据库有150个表
具体业务千变万化，底层科目，比如说冻结，可用，待付，抵押，这些一般不变，具体业务具体自己负责具体的差异
金额过大都走线下的，几十万、几百万你走线上不太可能，你自己也不放心；关键是他们还有一个账期问题，更加困难，这涉及到供应链金融了（线下的话，那支付平台的意义何在 ）
大额的话，线上走银行的二代支付系统就解决了啊
讲解
【资料共享】
网上支付跨行清算系统（第二代支付系统）与大小额支付系统有什么区别？ ==from 郭芬-中央结算公司==
中国支付清算系统总体架构图
【网友回应】
拿一笔债券交易来说，主要分为3种情况吧，交易双方都是支付系统直接成员，不是直接成员。A，向B购买债券，系统检查B债券是否足额，如果足额，将B的债券从可用科目，划分到冻结科目。交易处在等款的状态
A通过大额支付系统向A在我们公司的资金账户汇入相应的资金。后台有一个一直运行的守护线程类似的系统。在A的资金到位后，实行债权和资金的划分。资金划拨到B在我们公司的资金账户里头；如果A资金不到位，过期交易失败，债券从冻结变可用。如果B债券不足，A的资金原路退回。
汇路一般由客户自己维护。因为只要券足和款足，我们就直接进行资金和债券的交割。对应也能直接反映到相应银行在央行的帐上。所以交割基本上是T+0 ；如果是个人参与者的话，就必须通过有结算资质的银行来代理相应的资金操作，就是之前债市风暴的丙类户。
我们的对账，主要是内部对账和外部对账。首先借贷双方必相等。其次跟大额支付系统这些外部渠道的账务必相等。流水也得和内部的账务进行对账，基本就是这个流程。大家觉得厉害的公开市场操作，正回购，逆回购也是基于这套业务逻辑衍生出来的。
虚拟账户我们分资产的账务，簿记系统，资金的账户，资金管理系统，出现过汇错款的情况，但是好在银行间市场，款项的追回比较容易。我们的这些架构适合机构间的业务
一个机构在我们这有可能有很多资金账户。个人投资者也有代理的关系在里头，汇路说白了，就是从哪转到哪；汇路就是路径（这是我们的叫法）
我负责的事全国银行业信贷资产登记流转系统的整体系统建设，最近正要做一套资金和支付系统，所以也正想怎么结合公司的资金和支付系统。
在我们类似于交易所的单位里头，资产账务，涉及到的权益，登记的是债券，所以资产里就有发行人和债权人；而且为了支持各种业务，资产的科目比资金的复杂，大概有小20个科目，数据库有150个表
具体业务千变万化，底层科目，比如说冻结，可用，待付，抵押，这些一般不变，具体业务具体自己负责具体的差异
金额过大都走线下的，几十万、几百万你走线上不太可能，你自己也不放心；关键是他们还有一个账期问题，更加困难，这涉及到供应链金融了（线下的话，那支付平台的意义何在 ）
大额的话，线上走银行的二代支付系统就解决了啊
讲解
拿一笔债券交易来说，主要分为3种情况吧，交易双方都是支付系统直接成员，不是直接成员。A，向B购买债券，系统检查B债券是否足额，如果足额，将B的债券从可用科目，划分到冻结科目。交易处在等款的状态
A通过大额支付系统向A在我们公司的资金账户汇入相应的资金。后台有一个一直运行的守护线程类似的系统。在A的资金到位后，实行债权和资金的划分。资金划拨到B在我们公司的资金账户里头；如果A资金不到位，过期交易失败，债券从冻结变可用。如果B债券不足，A的资金原路退回。
汇路一般由客户自己维护。因为只要券足和款足，我们就直接进行资金和债券的交割。对应也能直接反映到相应银行在央行的帐上。所以交割基本上是T+0 ；如果是个人参与者的话，就必须通过有结算资质的银行来代理相应的资金操作，就是之前债市风暴的丙类户。
我们的对账，主要是内部对账和外部对账。首先借贷双方必相等。其次跟大额支付系统这些外部渠道的账务必相等。流水也得和内部的账务进行对账，基本就是这个流程。大家觉得厉害的公开市场操作，正回购，逆回购也是基于这套业务逻辑衍生出来的。
虚拟账户我们分资产的账务，簿记系统，资金的账户，资金管理系统，出现过汇错款的情况，但是好在银行间市场，款项的追回比较容易。我们的这些架构适合机构间的业务
一个机构在我们这有可能有很多资金账户。个人投资者也有代理的关系在里头，汇路说白了，就是从哪转到哪；汇路就是路径（这是我们的叫法）
我负责的事全国银行业信贷资产登记流转系统的整体系统建设，最近正要做一套资金和支付系统，所以也正想怎么结合公司的资金和支付系统。
在我们类似于交易所的单位里头，资产账务，涉及到的权益，登记的是债券，所以资产里就有发行人和债权人；而且为了支持各种业务，资产的科目比资金的复杂，大概有小20个科目，数据库有150个表
具体业务千变万化，底层科目，比如说冻结，可用，待付，抵押，这些一般不变，具体业务具体自己负责具体的差异
金额过大都走线下的，几十万、几百万你走线上不太可能，你自己也不放心；关键是他们还有一个账期问题，更加困难，这涉及到供应链金融了（线下的话，那支付平台的意义何在 ）
大额的话，线上走银行的二代支付系统就解决了啊
讲解
【资料共享】
网上支付跨行清算系统（第二代支付系统）与大小额支付系统有什么区别？ ==from 郭芬-中央结算公司==
中国支付清算系统总体架构图
网上支付跨行清算系统（第二代支付系统）与大小额支付系统有什么区别？ ==from 郭芬-中央结算公司==
中国支付清算系统总体架构图
拆单如何处理？
卡券如何处理？
支付到第三方，未响应，用户继续付款以及修改价格或在支付方式，那块如何处理？
针对部分退商品，对这块的部分怎么退以及优惠是如何处理？
拆单如何处理？
卡券如何处理？
支付到第三方，未响应，用户继续付款以及修改价格或在支付方式，那块如何处理？
针对部分退商品，对这块的部分怎么退以及优惠是如何处理？
【网友回应】
【资料共享】
胖收银台的架构设计
【网友回应】
【资料共享】
胖收银台的架构设计
胖收银台的架构设计
如果账单有误，且T+1对账，重新对账的方案怎么处理比较合理？
例如：T+1对账，跨日差异T+2消除。假如一方T对账单部分漏掉或有误，一种解决方式是：重新生成T对账单，重新对账，带来问题是T过去几天了，T+N都需要重新对账（因为依赖T+N-1的结果） 问下大家怎么处理。
例如：T+1对账，跨日差异T+2消除。假如一方T对账单部分漏掉或有误，一种解决方式是：重新生成T对账单，重新对账，带来问题是T过去几天了，T+N都需要重新对账（因为依赖T+N-1的结果） 问下大家怎么处理。
【网友回应】
平账的部分需要较强的人工干预，会从交易，账务，第三方/银行这几方面来找出对账不平的根源并解决。挂账分两部分，待查长款和待查短款。短款的问题要严重些
支付机构和银行对账主要是考虑日切点不一致的情况，特别是代收付业务要处理好这件事。 发生在临界点的交易、测试人员在测试环境做的真实资金测试 都会造成存疑账或差异账。
1.每天都去查差异，如果核实是银行/第三方回调信息晚的原因，就记录生成T对账单，如果还是不平，继续生成T对账，一般过2天就能对平了
2.如果是其他问题，先把这笔帐挂起，不再参与对账，人工核实具体问题后，进行销账处理。
==胡圣支付产品经理猪八戒网==
查挂账系统足够强大的话，平一笔差异，需要关注交易和账务的相应记录的状态。
做成幂等，支持重复对账（不知道会不会有问题）
差异都交由另外的系统处理，交易上还要关心么
【网友回应】
平账的部分需要较强的人工干预，会从交易，账务，第三方/银行这几方面来找出对账不平的根源并解决。挂账分两部分，待查长款和待查短款。短款的问题要严重些
支付机构和银行对账主要是考虑日切点不一致的情况，特别是代收付业务要处理好这件事。 发生在临界点的交易、测试人员在测试环境做的真实资金测试 都会造成存疑账或差异账。
1.每天都去查差异，如果核实是银行/第三方回调信息晚的原因，就记录生成T对账单，如果还是不平，继续生成T对账，一般过2天就能对平了
2.如果是其他问题，先把这笔帐挂起，不再参与对账，人工核实具体问题后，进行销账处理。
==胡圣支付产品经理猪八戒网==
查挂账系统足够强大的话，平一笔差异，需要关注交易和账务的相应记录的状态。
做成幂等，支持重复对账（不知道会不会有问题）
差异都交由另外的系统处理，交易上还要关心么
平账的部分需要较强的人工干预，会从交易，账务，第三方/银行这几方面来找出对账不平的根源并解决。挂账分两部分，待查长款和待查短款。短款的问题要严重些
支付机构和银行对账主要是考虑日切点不一致的情况，特别是代收付业务要处理好这件事。 发生在临界点的交易、测试人员在测试环境做的真实资金测试 都会造成存疑账或差异账。
1.每天都去查差异，如果核实是银行/第三方回调信息晚的原因，就记录生成T对账单，如果还是不平，继续生成T对账，一般过2天就能对平了
2.如果是其他问题，先把这笔帐挂起，不再参与对账，人工核实具体问题后，进行销账处理。
==胡圣支付产品经理猪八戒网==
查挂账系统足够强大的话，平一笔差异，需要关注交易和账务的相应记录的状态。
做成幂等，支持重复对账（不知道会不会有问题）
差异都交由另外的系统处理，交易上还要关心么
请教个问题，支付的沙盒环境你们是怎么做的，是一套环境还是分开的呢？
沙盒环境会进行实际支付操作吗？环境分开的话，比如调微信支付，最后对账就会出现微信有订单但是本地没有的情况
分开的,用子域名
支付你搞个一分钱的商品测试呗，直接用正式环境了
支付和退款都是成对的，你测了支付，顺便测退款呗
沙盒环境会进行实际支付操作吗？环境分开的话，比如调微信支付，最后对账就会出现微信有订单但是本地没有的情况
分开的,用子域名
支付你搞个一分钱的商品测试呗，直接用正式环境了
支付和退款都是成对的，你测了支付，顺便测退款呗
分开的,用子域名
支付你搞个一分钱的商品测试呗，直接用正式环境了
支付和退款都是成对的，你测了支付，顺便测退款呗
商品库存怎样处理比较好？
方案1. 跟随订单减库存
方案2. 定期盘点订单售卖的商品
方案1. 跟随订单减库存
方案2. 定期盘点订单售卖的商品
方案1. 跟随订单减库存
方案2. 定期盘点订单售卖的商品
【网友回应】
普通pos的回单是需要定时任务跑的，而且还得及时在系统录凭条，而大额支付不接POS又不行
建议走线下POS的场景尽量保障库存，强依赖库存的场景建议走线上支付
优点：可以实时盘点库存
缺点：银联普通非智能pos不支持，建议统一接微信支付宝
下单减库存，支付设时限，超时就回滚/释放库存
关于线下pos
关于何时减库存这个问题，淘宝十年产品事这本书有一节专门讲这个
我们的场景不一样～票务系统先创建业务系统订单、调用售票系统临时锁座位、调用第三方支付、成功调用售票系统出票、售票系统15分钟释放未支付座位～ 座位就是库存～
【网友回应】
普通pos的回单是需要定时任务跑的，而且还得及时在系统录凭条，而大额支付不接POS又不行
建议走线下POS的场景尽量保障库存，强依赖库存的场景建议走线上支付
优点：可以实时盘点库存
缺点：银联普通非智能pos不支持，建议统一接微信支付宝
下单减库存，支付设时限，超时就回滚/释放库存
关于线下pos
关于何时减库存这个问题，淘宝十年产品事这本书有一节专门讲这个
我们的场景不一样～票务系统先创建业务系统订单、调用售票系统临时锁座位、调用第三方支付、成功调用售票系统出票、售票系统15分钟释放未支付座位～ 座位就是库存～
普通pos的回单是需要定时任务跑的，而且还得及时在系统录凭条，而大额支付不接POS又不行
建议走线下POS的场景尽量保障库存，强依赖库存的场景建议走线上支付
优点：可以实时盘点库存
缺点：银联普通非智能pos不支持，建议统一接微信支付宝
下单减库存，支付设时限，超时就回滚/释放库存
关于线下pos
关于何时减库存这个问题，淘宝十年产品事这本书有一节专门讲这个
我们的场景不一样～票务系统先创建业务系统订单、调用售票系统临时锁座位、调用第三方支付、成功调用售票系统出票、售票系统15分钟释放未支付座位～ 座位就是库存～
2017-05-05
2017-05-06
2017-05-07
2017-05-08
2017-05-09
2017-05-05
2017-05-06
2017-05-07
2017-05-08
2017-05-09