支付系统

补充一下，大小额既然是人行发布的系统，本身就做了接口规范，实际业务逻辑和接口的多样化应该只存在于银行业务涉及的第三方。
而中间业务不一样，对各个银行来说，没有哪个外部系统帮助规范接口，第三方业务的接口规范和业务逻辑都必须由银行自身开发的中间业务平台来提供规范。
其实说白了，是中间业务平台将第三方支付业务收拢，再对跨行转账交易视情况选择通过人行大小额完成支付(当然还有银联金卡)，当然也包括其它一些非第三方业务也需要走大小额，但很明显，大小额只涉及支付，而中间业务却多了许多纷繁复杂的业务逻辑。

其实支付系统有很多，大小额，同城，全国支票影响，等等，相对来说 大小额，甚至后期的人行2代支付系统目前来说虽然业务多一些但是在人行接口上基本统一。但是对于同城，由于各地差异较大，交换模式有手工，电子，批量等等，在交易范围上各地差异较大，如 代收费，缴费通，支票圈存等等。而且从后期发展来看，比如2代支付系统如果业务不懂人行接口都看不明白。其实这些支付类系统 基本在行内都是 清算户，暂收 暂付户，退票户，临时存欠等相互账务关系。个人觉得在对公业务上比较重要的有2点，
1.行内账务关系，尤其是退票
2.账务合法性验证 如 使用支付密码 一票一密 印鉴 票号 重控管理等等

我们公司专门做支付的，这里确实业务逻辑比较复杂，因为为了不同的客户不同的需求，比如我们还涉及到给用户信用额度计算的，都是根据不同条件变化的，另外给商家也是大客户的条件不一样，都有特殊处理的，尽管我不知道这些在java中怎么实现，但大同小异总是要处理这些问题的。企业架构模式里边也谈到这个了，一个mortage系统，为了赢得客户，business的人，都是乱定规则，让软件去实现。

主要是你发报文和所在行的前置系统打教道，然后前置和核心系统通讯，核心和银联通讯，就是这么交易的，有的交易需要走银联，有的不需要，看什么交易了，具体问题，具体对待。。。

现在正在做央行的第二代支付系统。 刚开始， 还在学习之中。