聊天记录2017-05-13未整理版

Posted by PaymentGroup on May 13, 2017

8:09:51 Fintech早餐会 2017/5/13
8:44:53 @XXX你们是要接银行借记卡的充值吗?
9:27:48 爬楼看完,获益匪浅
10:31:36 通知:中美达成共识,美支付公司获允申牌!支付牌照或重新开闸!
10:34:36 签合同,但是还没开始接了,具体的还不是太清楚
10:36:28 新版银联卡bin,供参考
10:43:58 好东西!
10:44:45 2017-05-09聊天记录整理版
10:45:08 5.5-5.9聊天记录整理
10:45:26 感谢@XXX北京?
10:46:05 赞赏收入将分给整理人员。
10:48:50 今天早上看到了
10:48:52 感谢
10:51:12 已赞赏,辛苦了
10:53:02 [强][强][强]辛苦了
10:55:30 银联的卡bin表在银联的平台上可以下载的吧
10:55:49 我印象中应该是公开的数据
10:56:37 不管在哪能下载到,可贵的是分享精神
10:56:49 是的
10:57:13 对的
10:57:24 [强]
10:58:07 [强]
10:58:18 稍微问一下,大家记账的时候是先记流水还是先记余额的变化
10:59:16 也就是先处理流水还是直接处理用户的余额
11:00:05 这个没什么关系吧
11:00:07 一般是先流水
11:00:16 这是一个事务吧……
11:00:22 一个事务里面
11:00:30 非热点账户
11:00:58 她说的是业务问题
11:01:00 如果正常来说,余额变化驱动流水记录。这是一个事务场景,应该没有关系
11:01:11 先落个凭证,然后记明细,然后改余额。
11:01:34 哦哦
11:01:50 没有流水,就没有余额变动
11:02:22 流水即日志
11:02:32 [动画表情]
11:02:59 当然,再深一点还分借贷处理了
11:03:59 嗯嗯,我觉得应该是先流水,后余额。我们的先处理借贷方余额,再在流水表里头记录一条记录
11:04:23 热点账户我们是先记流水后余额
11:04:48 根据流水可以检验余额,先余额就不好追溯了
11:05:07 流水登记是余额的依据
11:05:34 热点其实落凭证 或者 简单的分录
11:05:57 一般是商户 平台或者应收什么的
11:06:32 凭证类型请问分类的依据大概会考虑哪些呢?
11:06:45 不同的凭证对应不同的分录规则?
11:07:08 收支转三类
11:07:11 凭证你当做发票就好
11:07:32 就跟财务线下类型一样?
11:07:33 也可以用通用凭证就好了
11:07:37 收支转是大类吧
11:07:52 嗯
11:08:38 [动画表情]
11:08:45 举例比如某通路的一笔支付确认可以算是一笔?还是说这笔的备付金入金流水算作一笔么
11:09:01 凭证会计上分原始凭证 记账凭证,我们说的是记账凭证
11:09:05 收支转的粒度比较大啊
11:10:04 对 上述那两条哪个可以作为原始凭证呢?支付确认就可以了吧
11:10:13 收支转是基本分类
11:10:42 原始凭证就是交易记录
11:11:30 先有原始凭证,再有会计凭证
11:11:31 你说的确认是担保么?
11:14:19 不是就是通路接口返回成功
11:14:36 交易是商户发起的支付交易吧
11:14:49 这个存在支付失败的可能啊
11:15:02 做原始凭证有问题吧
11:15:12 一个记账凭证就是一笔交易流水对应的会计账务处理的方法吧
11:15:39 大家的交易流水指的是?
11:16:35 比如说一个淘宝买买卖的成功记录?
11:17:08 这个是业务交易吧
11:17:39 记账流水
11:18:00 账务系统的记账流水。
11:19:01 一笔电商交易对应一笔交易订单
11:19:43 回到上面那个问题,交易和记账的问题:支付交易先处理订单,成功后再记账,退款交易先记账后更新订单。
11:19:50 流水分为订单流水与交易流水,支付成功了写入交易流水表,支付状态未知的写入临时表用于冲正等,成功交易流水后期用于清分对账使用
11:20:57 流水每个系统都有
11:22:16 嗯
11:23:00 交易系统有交易流水即交易订单,支付系统有支付流水即支付订单,账务有记账流水,清算有清分流水
11:23:02 订单流水是业务的吧,只要订单发起了就有,但交易流水是成功了的订单才有的。根据交易流水来记账是吧
11:24:10 准确的说是记账流水
11:24:13 哦哦
11:25:49 会计系统是中立性系统,只要有请求就会记,支付只是一个分支请求
11:27:31 支付成功后支付核心系统请求账务记账,是支付核心的业务
11:28:02 交易系统给支付发请求,支付给账务系统发请求
11:28:15 是的
11:41:51 回答下理房通的问题: 假设担保交易不走银行或通道的预授权接口,即担保和即时走相同的通道接口 支付成功后,通道账记入通道待清算,商户侧分两种:即时交易通道侧记入商户待清算,担保交易记入公司过渡账。这样能保证备付金都对上,商户只结算即时交易,等用户收货确认后,资金从公司过渡账流入商户待清算账户,然后就和即时交易一同清算了
12:12:47 嗯 我消化下~
12:22:21 吃饭呢吧~我还有一点小问题 支付成功后通道侧记入了 通道待清算 (这是算资产吧借记?)这里是根据交易逐笔登记分录的吧 我的问题是T+1 日 首先我拿到对账文件核对 之后通道方给我们结算时是一笔入账的 我应该通道待清算贷记一笔总和(我理解登记备付金实际入金数,但是有问题 如果对象文件总和同入金数不一致,还要不要登记分录呢 不登记怎么处理呀)然后对应的银行科目下借记一笔? 方便时候帮看下啊 谢啦哈 @XXX北京?
12:43:26 1.待清算都是资产负债共同类,因为一笔账里有应收应付 2. 通道对账:理论上说通道对账里不仅有交易对账还有结算对账,即交易,本金,手续费,所以在对账前应先进行通道清分,算出本金手续费。 因为对账和结算都是以通道的对账单为主,所以通道待清算转到备付金资金也是以通道侧为主,对账的差异形成差错挂账,记入应收应付科目,后续通过差错处理进行平账。 处理原则是重事实轻形式,真实反映实际资金流动
12:49:00 通道侧清分,不仅是备付金,还要核算通道成本支出,通过和商户清分的手续费收入相减,核算出利润
13:02:47 嗯 有一点差异 我们这的实现备付金科目记账时 是按照实际入金来登记的
13:03:25 这样目的就是尽可能保证备付金科目的分录同网银要一致
13:03:43 受教了啊~多谢@XXX北京?
13:04:02 其实是一样的,入金也是按对账单入的。
13:05:17 我们还真经常遇到……
13:05:30 对账单总数同网银不一致 哈哈
13:05:57 然后跟通道方沟通后……再提供份对账单
13:06:23 还有一层对账要做,账实核对,也就是结算单和银行账单对账
13:06:24 所以我们对账要有批次 支持当日重复对账
13:06:42 嗯对 这个一致了才能算到账
13:08:27 业务多了不能这样重复对账了,对不上的下次处理
13:09:01 哎,现在通道系统水平太差
15:06:03 问下大家。你们支付交易的order id生成规则是什么, guid?
15:08:15 Leaf——美团点评分布式ID生成系统
15:08:56 @XXX这篇可以借鉴一下
15:14:41 我说的可能还不是这个,我从支付系统调用方角度去说,比如我现在调用支付宝的转账借款,业务方会给支付宝传递order_id,这个order_id是唯一的,并且回调的时候也是依赖这个order_id来区分订单,我说的是这个order_id是随机生成的,还是要和某笔业务有关,比如和电商商品订单有关
15:19:53 有没有关联属于关系映射,和生成规则无关
15:22:52 我理解 只要内外单号有关联即可 没有特别的要求
15:24:20 对,如果定单号是电商生成的,应该有规则
15:25:06 谁生成的单号规则在谁那
15:26:25 只要能保证唯一性
15:28:15 当然通常转账表里面会有一个业务相关的唯一索引的id, 我比较想知道你们现在我说的那个order_id是怎么造出来的,我们现在就是简单的uuid
15:31:26 数据库主键不要用uuid,对索引影响大,一般都是前面几位有规则,后面跟一段seq
15:40:42 不是主键 ok
19:46:26 @XXX上海?wood哥,你的公众号哪个,推荐一下呗,上次讲的很好,多学习下
19:46:40 我没有公众号啊
19:47:32 一文看懂二维码支付的前世、今生与未来!
19:47:45 这是我昨天写的
19:47:59 也给大家分享一下
19:48:33 以前很少写,以后慢慢的写一点
19:48:40 像群主学习
19:48:46 写的很好,昨天看到了
19:48:48 分享给大家
19:48:49 哈哈
19:49:46 [强]
19:50:33 区块链和人工智能会颠覆传统金融?
19:51:22 今天没人分享吗啊
19:51:51 今天周末呐
19:51:57 @XXX上海?,周末休息一下吧
19:52:09 抱歉,应该提前通知大家。
19:52:24 周末休息,暂不安排分享。
19:52:30 虚拟化被包装成云也才两年时间 区块链就来了
19:53:08 好的,没有主要是刚刚看完电影然后习惯性看了一下群
19:56:12 我倒是想弄个轻量版的支付系统 支持at就行 但是财务会计那块不熟悉 对分布式事务有些想法也想验证一下
20:16:34 什么情况,一下这么多人[发呆]
20:35:38 这里基本集结了支付行业的大咖们??
20:53:44 最新公安部通报中心重要通知,wana 新型恶意软件爆发预警:本次爆发的勒索软件是一个名称为“wannacry”的新家族,目前无法解密该勒索软件加密的文件。该勒索软件迅速感染全球大量主机的原因是利用了基于445端口传播扩散的SMB漏洞,微软在今年3月份发布了该漏洞的补丁MS17-010。 该漏洞的相关说明、补丁: https://technet.microsoft.com/zh-cn/library/security/ms17-010.aspx 安全建议: 1.及时更新最新的操作系统补丁。 2.关闭操作系统不必要开放的端口如445、135、137、138、139等,关闭网络共享。 3.定期备份重要文件数据。 请各位以微信等适当形式尽快通告各银行业金融机构,谢谢!
21:07:49 windows就是个间谍软件

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。