请问目前供应商提供二代支付系统的技术架构是哪些？ - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

据说已经选择二代支付系统供应商的甲方明细如下：
    山东城商行联盟——上海华腾；
    成都农商行——高伟达；
    智控国际（吉林银行、柳州银行）——上海华腾；
    南充商行——上海华腾；
    重庆农商行——先进数通；
    北京农商行——神码；
请问目前这些供应商提供二代支付系统的技术架构是什么？ J2EE B/S ，    dotnet C/S？
老厂商系统前端有的还是只支持字符？
有谁了解？ 谢谢了！
有的厂商把支付单独做，包括账务处理，生成多级清算会计分录，然后把支付账务信息与核心进行合并。这样是否可行？ 需要注意哪些关键点？
原帖由 down2011 于 2011-9-10 15:42 发表

有的厂商把支付单独做，包括账务处理，生成多级清算会计分录，然后把支付账务信息与核心进行合并。这样是否可行？ 需要注意哪些关键点？
唉,如果你的核心厂商没有二代产品,就只能这样做了.
这样做个人觉得是可行的.
个人觉得要注意:
1,前台的操作是否独立出来,还是整合到现有的前台中
2,核心接口的设计
3,第三方业务,电票,网银等接口的设计.
4,对现有一代的兼容
这个很让人头痛呀.
原帖由 down2011 于 2011-9-9 09:55 发表

据说已经选择二代支付系统供应商的甲方明细如下：
    山东城商行联盟——上海华腾；
    成都农商行——高伟达；
    智控国际（吉林银行、柳州银行）——上海华腾；
    南充商行——上海华腾；
    重庆农商行——先进数通；
    北京农商行——神码；
请问目前这些供应商提供二代支付系统的技术架构是什么？ J2EE B/S ，    dotnet C/S？
老厂商系统前端有的还是只支持字符？
有谁了解？ 谢谢了！
一般都是BS结构的吧.
然后,提供对字符界面的支持,看了几个厂家的演示都是这样说的.
有些是提供接口.你行内现有字符前端可以接入.
我觉得柜面系统的接口方式比较合理,都知道二代支付系统是人行弄的一个项目,
跟商业银行业务没有啥太大关系,难道上一个系统就弄个新柜面,想把柜员折腾到IT人员的学习水平?呵呵
原帖由 down2011 于 2011-9-10 15:42 发表

有的厂商把支付单独做，包括账务处理，生成多级清算会计分录，然后把支付账务信息与核心进行合并。这样是否可行？ 需要注意哪些关键点？
这种模式非常不现实！
去年底在我们的某家银行客户经历过这种模式，IBPS前置用的雁联，只提供报文转发处理，其它的比如：交易异常处理（冲正或重发）、与网银接口、与核心接口、柜面操作界面开发、交易审批控制（包括权限和限额控制等）、手续费处理、行内清算处理等，都还是需要我们作为综合前置或核心厂商配合开发，系统交易的完整性极难保证，业务需求的变动修改也很困难。加上这种独立的支付系统厂商，只是重点掌握报文处理方法，对行内账务的设计一窍不通，最终问题一大堆。
如果想选独立厂商系统的银行，建议慎重选择。至少是能够与核心厂商有紧密合作经验，本身也了解核心账务处理的公司为佳。
[ 本帖最后由 CountOnMyself 于 2011-9-16 10:50 编辑 ]
原帖由 CountOnMyself 于 2011-9-16 10:49 发表

这种模式非常不现实！
去年底在我们的某家银行客户经历过这种模式，IBPS前置用的雁联，只提供报文转发处理，其它的比如：交易异常处理（冲正或重发）、与网银接口、与核心接口、柜面操作界面开发、交易审批控制（包括权限和限额控制等）、手续费处理、行内清算处理等，都还是需要我们作为综合前置或核心厂商配合开发，系统交易的完整性极难保证，业务需求的变动修改也很困难。加上这种独立的支付系统厂商，只是重点掌握报文处理方法，对行内账务的设计一窍不通，最终问题一大堆。
如果想选独立厂商系统的银行，建议慎重选择。至少是能够与核心厂商有紧密合作经验，本身也了解核心账务处理的公司为佳。
我觉得模式不重要，因为人行系统无论一二代，对于商业银行来说都是个结算业务通道。小行可以采用外挂式，只支持有限的业务，大一点的就要和行内系统结合，在大前置上做相应的开发。不管怎么做，核心是不应该与外围系统紧耦合的。