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

wangjia

我认为，在上面两种错误发生的情况，则报文基本可以认定为 无效/非合法 交易报文；
而在 技术规范中，发生以上两种异常时的标准处理如下：
1.发现报文语法错误，若为通知/请求类报文，回应报文(拒绝的CUPS报文头+原始报文)至发送方
    发现报文语义错误，若为通知/请求类报文，拒绝报文请求/通知
2.发现报文不匹配，若为通知/请求类报文，拒绝报文请求/通知
所以，当不能拒绝存款确认通知的发卡方，碰到这两种异常时
应该按照 技术规范的 异常处理标准 处理吧？
该拒绝的拒绝。
请DX们，根据实际情况指点一下，感谢！
其实存款确认可以当作一种冲正。
终端发起后，报文的下一站（也许是POSP,也许是其他前置)收到后就要给出回应，走的是小圈，而不是走大圈绕道发卡行后台。这个回应如果是Positive，终端认为存款成功，后面这个存款确认报文就一切按照冲正的方式走，存储转发，银行收到后会记账。如果因为语法或语义错误返回终端一个Neg回应，那么终端的应视为存款失败，具体行为根据不同所属主体所决定。
实际处理中，发卡方如果真的收到了一个无法处理的存款确认，可以严格按照规范走，也可以给回复一个接受，然后等着调账，因为这是小概率事件，所以具体来说一般各发卡行怎么处理得都有
原帖由 thunderm 于 2008-1-14 16:47 发表

其实存款确认可以当作一种冲正。
终端发起后，报文的下一站（也许是POSP,也许是其他前置)收到后就要给出回应，走的是小圈，而不是走大圈绕道发卡行后台。这个回应如果是Positive，终端认为存款成功，后面这个存款确认报文就一切按照冲正的方式走，存储转发，银行收到后会记账。如果因为语法或语义错误返回终端一个Neg回应，那么终端的应视为存款失败，具体行为根据不同所属主体所决定。
首先，感谢回复！
我了解你的意思，存款确认不是转发式的通知，在受理方收到通知后就要回应通知，所以可以看为一个小圈。
然后目的是将存款确认发往发卡方，告知受理方承认存款交易；
发卡方收到存款确认通知，进行报文检查，
我的想法是， 受理方和CUPS，可能都同意了存款确认交易，那么受理方和CUPS的账平了。
发卡方检查到报文语法、语义错误等，(认定是报文不合法，出于安全考虑)，按标准异常处理，拒绝交易(Reject RspCode)或拒绝报文(+RejectCode)。
到时候，CUPS和发卡方对账，账目不平，再通过差错处理或人工调账解决。(个人人文，这样的错误在排查的时候更显性一些)
原帖由 moutainshore 于 2008-1-14 17:16 发表

实际处理中，发卡方如果真的收到了一个无法处理的存款确认，可以严格按照规范走，也可以给回复一个接受，然后等着调账，因为这是小概率事件，所以具体来说一般各发卡行怎么处理得都有
感谢回复
了解！就是在处理方面可能各家银行有各自的处理原则/或不强定用哪种处理方式。