存款确认 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

存款确认交易
当终端在限定时间内接收不到存款交易请求的应答时，必须产生存款确认交易。
它似乎用于存款交易的异常处理。
疑问：
存款确认交易发生的前提条件？个人认为这个前提条件是在终端方控制(即存款机)，
是不是存款机在吃到钱之后，如果终端在交易处理超时后没有接到交易回应，就发送
存款确认呢？如果没有吃到钱，就不会发送存款确认？
存款确认应该是存储转发的。在正常流程中也有，由终端发起。同理还有一个为了避免吐钞可以的确认交易
原帖由 littlepigabu 于 2008-1-7 10:46 发表

如果没有吃到钱，就不应该发送存款交易吧，没有存款交易，又哪里来的存款确认。
存款确认应该是存储转发的。在正常流程中也有，由终端发起。同理还有一个为了避免吐钞可以的确认交易
有道理啊，看来我是昏头了，


那存款确认是为了确保大家都能够记到账了。 (受理方、处理中心、发卡方)
受理方发动存款交易的时候已经吃了钱，如果受理方的存款请求没有接受到回应，
终端发送存款确认，但是被CUPS拒绝了，会怎么样，是不是终端会把钱吐出？
原帖由 sd6345319 于 2008-1-7 15:09 发表

受理方发动存款交易的时候已经吃了钱，如果受理方的存款请求没有接受到回应，
终端发送存款确认，但是被CUPS拒绝了，会怎么样，是不是终端会把钱吐出？
既然没有接受到回应的话，终端怎么发送存款确认？
原帖由 flf21 于 2008-1-7 15:53 发表

既然没有接受到回应的话，终端怎么发送存款确认？
存款确认交易
当终端在限定时间内接收不到存款交易请求的应答时，必须产生存款确认交易。
当存款交易发生以下异常时
CUPS不能向受理方转发对请求的应答 -- CUPS不能向受理方转发发卡方对请求的应答
异常处理
CUPS处理1：     CUPS直接丢弃该应答。若为承兑交易则参与对账，否则不参与对账。对账不平时通过差错处理解决
受理方处理1：     向终端发超时应答，含义为受理方收不到CUPS的应答。
终端处理：          发送存款确认。
受理方处理2：     先给终端返回批准的应答，含义为“有缺陷的成功交易”，同时向CUPS发送存款确认通知。
CUPS处理2：     若原存款请求已承兑，返回受理方应答，RspCode为00；若原存款请求为拒绝，返回受理方应答，RspCode为原拒绝码。
此时出现我上面说的那种情况：
受理方发动存款交易的时候已经吃了钱，如果受理方的存款请求没有接受到回应，
终端发送存款确认，但是被CUPS拒绝了，会怎么样，是不是终端会把钱吐出？
哥们，看了你开了两个帖子讨论银联的存款确认，你到底遇到啥问题了呀，应者寥寥呀，这个坛子里讨论技术和业务历来不是特别的热烈，讨论形而上的东西得比较热烈，比如架构了、银行发展了、核心系统理念了、公司排名了等等
你把银联2。0那个蓝本的标准多看看，可能就有你的答案了
回答一下你最后的问题，存款交易除非收到明确的拒绝错误码，否则一律吞钞，如果都已经触发了存款确认了，那就更不用想了，必须吞钞，无论存款确认交易的应答错误码是什么。事实上存款确认是逐级应答，逐级转发的，终端收到了存款确认的任何应答，都不意味着这是发卡方的真实应答，更何况银联的标准里清晰地描述了：存款确认交易不能拒绝，必须逐级转发，若原交易，即存款交易是明确失败，存款确认交易也要回“有缺陷的成功交易”，至于最终发卡方如何处理这笔交易，有很多种，我这里就不多说了，因为看你问的主要是机具如何处理
[ 本帖最后由 moutainshore 于 2008-1-8 12:27 编辑 ]
原帖由 moutainshore 于 2008-1-8 12:24 发表

哥们，看了你开了两个帖子讨论银联的存款确认，你到底遇到啥问题了呀，应者寥寥呀，这个坛子里讨论技术和业务历来不是特别的热烈，讨论形而上的东西得比较热烈，比如架构了、银行发展了、核心系统理念了、公司排名了等等
你把银联2。0那个蓝本的标准多看看，可能就有你的答案了
回答一下你最后的问题，存款交易除非收到明确的拒绝错误码，否则一律吞钞，如果都已经触发了存款确认了，那就更不用想了，必须吞钞，无论存款确认交易的应答错误码是什么。事实上存款确认是逐级应答，逐级转发的，终端收到了存款确认的任何应答，都不意味着这是发卡方的真实应答，更何况银联的标准里清晰地描述了：存款确认交易不能拒绝，必须逐级转发，若原交易，即存款交易是明确失败，存款确认交易也要回“有缺陷的成功交易”，至于最终发卡方如何处理这笔交易，有很多种，我这里就不多说了，因为看你问的主要是机具如何处理
我在研究存款的异常处理部分，主要的困惑是 在存款异常处理原则下，银联，入网机构之间的账务处理(也包括人工处理)。如何拉平账
我在逐个察看存款异常处理原则后，推敲出一种异常的处理方式(特别是异常处理中的记账问题)
在碰到上面描述的异常情况时，没有想明白(或是推测出)银行与处理中心、客户之间如何解决问题的过程。
上面描述的异常过程，让我不清楚的地方：假设发卡方处理原始存款交易时是拒绝交易的。
我按交易流程描述一下：
1.终端发送存款交易 -- 受理方(受理方吃钱)
2.受理方发送存款交易 -- 处理中心
3.处理中心发送存款交易 -- 发卡方
4.发卡方拒绝存款交易 -- 处理中心 (发卡方没有记账，账户存款失败)
5.处理中心无法发送存款交易回应 -- 异常
6.受理方发现存款交易处理超时，发送拒绝回应 -- 终端
7.终端发送存款确认 -- 受理方
8.受理方发送存款确认 -- 处理中心
9.处理中心发现原始存款交易被拒绝，则拒绝存款确认 -- 受理方
我的疑问：在这种异常情况下
1.受理方存款确认要不要记账(请注意存款确认被拒绝了)，如果不记账的话，就变成了
受理方吃了客户钱，然后没有记账，而且CUPS,发卡方都没记账；也就是说入网机构与
处理中心的账平了，但是客户与受理方之间，客户短钱了，受理方长钱了。而且，还不好找
到客户，因为是存款交易！
2.如果受理方存款确认不记账，是不是有这种可能：终端收到存款确认的拒绝交易，然后在
终端画面上提示客户，存款失败，让客户把钱拿回去。(客户需要等终端的存款成功画面)
另外，moutainshore，“存款确认交易不能拒绝，必须逐级转发，”这个说法有些问题，
银联技术规范中，只有强调发卡方不能够拒绝存款确认交易，但是受理方、CUPS都可以拒绝存款确认
moutainshore谢谢你的回复
以ATM为例，收到存款确认的任何应答，都要吞款，而且吞款就要记现金账，否则钱箱长款，至于这个调度，可以由P端负责，也可由银联前置负责，也可以由行内某个大前置负责，当然存在记现金账失败的可能，这样受理行可以设置本行记现金账也有重发机制，当然最后仍然存在记现金账失败的可能，那么ATMP对帐的时候会与核心对出帐不平，也就是长款，至于客户联系不到，这个你不用担心，除非客户疯了，否则客户会拿着ATM的小票找这个ATM所属银行的，因为ATM在不能100%肯定交易是否成功时，给客户提示的通常是：“交易超时，请查询交易结果”，客户一查余额发现不对，或者查余额也是超时，自然会去找银行
这个时候，即便当天与CUPS的清算对帐没有问题，也不代表就不进行差错处理，这笔交易最终行内自己发现长款，就要通过银联的差错处理平台进行调整，或者直接给客户退钱
至于你说得让客户在当时就直接把钱拿走，在绝对理论的情况下是可以的，比如存款确认CUPS给受理方返回的是25错误码，但是，但是呀。。。。。这样做何必呢，风险大大的。。。。交易处理起来也麻烦，还要去判断具体的错误码，所以我所知道的是大多数银行ATM一旦发起了存款确认，就立即吞钞
[ 本帖最后由 moutainshore 于 2008-1-8 15:01 编辑 ]
原帖由 moutainshore 于 2008-1-8 14:58 发表

以ATM为例，收到存款确认的任何应答，都要吞款，而且吞款就要记现金账，否则钱箱长款，至于这个调度，可以由P端负责，也可由银联前置负责，也可以由行内某个大前置负责，当然存在记现金账失败的可能，这样受理行可以设置本行记现金账也有重发机制，当然最后仍然存在记现金账失败的可能，那么ATMP对帐的时候会与核心对出帐不平，也就是长款，至于客户联系不到，这个你不用担心，除非客户疯了，否则客户会拿着ATM的小票找这个ATM所属银行的，因为ATM在不能100%肯定交易是否成功时，给客户提示的通常是：“交易超时，请查询交易结果”，客户一查余额发现不对，或者查余额也是超时，自然会去找银行
这个时候，即便当天与CUPS的清算对帐没有问题，也不代表就不进行差错处理，这笔交易最终行内自己发现长款，就要通过银联的差错处理平台进行调整，或者直接给客户退钱
至于你说得让客户在当时就直接把钱拿走，在绝对理论的情况下是可以的，比如存款确认CUPS给受理方返回的是25错误码，但是，但是呀。。。。。这样做何必呢，风险大大的。。。。交易处理起来也麻烦，还要去判断具体的错误码，所以我所知道的是大多数银行ATM一旦发起了存款确认，就立即吞钞
Hoho，我明白你的意思了。
基本上受理方银行的CDM发送了存款确认，则必定是吃了钱。(能够确认这一点，很重要，我就是吃不准这一点，现在了解了)
至于入网机构、银联、客户的账目怎么拉平，就看具体银行采用了什么处理方式了。
感谢！moutainshore