国内和国外的免签支付系统支付平台在为电商企业提供开发文档时，并不提供测试接口，开发人员在开发过程中需使用现金进行线上测试，这大大提高了交易平台的开发成本，降低了开发效率。由于构建真实网络环境的代价过于巨大，所以网络仿真和模拟平台在网络研究中得到普遍应用，作为测试系统功能的重要方法，模拟系统能够模拟支付过程中的各个场景，电商企业需要一个开发测试工具来模拟免签支付系统支付场景。 通过对电商企业开发测试需求的分析，同时，结合免签支付系统支付平台的特点，本文提出互联网免签支付系统支付模拟平台的概念，它忽略了具体的支付处理流程，开发测试人员可以专注于电商平台与免签支付系统的交互，具有较强的集成性、模拟性、可扩展性和可用性，能够模拟支付、参数验证、安全性验证等真实场景，提高了开发测试效率、节约了开发成本。 那么，开发一个免签支付系统支付系统需要哪些流程及所需费是大致多少呢？
　　
　　一、免签支付系统支付系统开发流程
　　
　　模拟平台运行的基本流程是：
　　
　　（1）接收并管理调用请求。模拟平台接口被调用，接收支付请求参数，对参数与签名进行校验，存储请求数据。
　　
　　（2）生成返回参数与签名。根据返回参数生成策略生成返回参数，根据签名策略生成签名，建立回调数据与请求数据的关联，并存储回调数据。
　　
　　（3）展示调用界面。展示请求与返回参数信息，提供回调触发接口，可对返回参数进行修改，以模拟参数被篡改的情形。
　　
　　（4）触发回调接口。以协定方式调用回调接口，返回支付结果信息。
　　
　　设计平台的核心问题是：
　　
　　（1）适应不同调用流程。模拟平台对电商平台屏蔽支付流程，根据电商平台的需求，提供有界面和无界面两种接口供其调用。对于参数的格式，模拟平台会根据不同的渠道需求进行具体处理。
　　
　　（2）集成多个支付渠道。集成各个支付渠道后，对于电商平台的不同支付渠道，模拟平台提供统一的接口。由于涉及参数与签名生成等关键环节，因此，模拟平台内部需要对渠道进行识别，并维护各个渠道的请求与返回参数信息。
　　
　　（3）签名与参数生成算法。模拟平台需要维护回调参数的生成机制，包括自动随机生成、枚举、继承等机制，对于不同机制，需要设计相应的算法实现。模拟平台应能够识别签名方式，并应用相应的签名算法进行签名与验签。同时，如果调用展示界面，需要提供参数与签名的修改机制，使模拟平台能够仿真参数被篡改的情况。
　　
　　（4）适应开发测试环境。如果能把开发测试环境封装为一个模板，在需要的时候快速实例化该模板，生成即配即用的环境，将节省开发测试时间。 因此，需简化对电商平台的修改与配置，电商平台只需调用支付模拟接口，模拟平台能够自动完成其它工作，并能够根据需求修改回调地址，以调用正确的主机地址。 2、平台设计 模拟平台立足于模拟技术的核心关注点，即资源管理、资源再利用和资源配置，通过合理的数据结构设计与高效的服务层实现，搭建起了功能完备的平台框架，平台具有完备性、易用性与可扩展性。
　　
　　2.1平台数据结构的设计。 平台数据结构设计的合理性直接影响平台的功能健壮性与可扩展性，数据层不仅需要对渠道信息进行维护，还需要管理通信信息。 渠道信息中维护各个渠道的渠道名称、请求与返回参数、渠道签名key等，其数据结构如图2所示。数据表由模拟平台维护，根据渠道的接口调用方法，每一个渠道都维护了对应的请求参数和返回参数，其中，返回参数包括前台返回参数和后台返回参数，由“参数类型”进行区分，模拟平台根据“渠道Id”和“用户Id”共同确认渠道的签名key.请求参数表和返回参数表中，“是否参与签名”字段维护了需要参与签名的参数。返回参数表中，“参数格式” 字段维护了参数的自动生成机制，“请求参数Id”与请求参数中的“参数Id”相关联，维护了参数的继承机制。渠道信息的数据结构可以满足对多个支付渠道的集成，适应了开发测试环境，维护了参数与签名的生成机制，为服务层的构建提供了基本支持。
　　
　　通信信息中管理接收请求与发送请求的信息，其数据结构如图3所示。每条发送请求根据“关联请求Id”与一条接收请求相关联，发送请求分为前台发送请求和后台发送请求，由“请求类型”进行区分，发送完成后，系统会根据发送结果对“发送状态”进行更新。在开发测试过程中，可以根据通信信息及时定位问题，如参数问题、签名问题、网络连接问题等。
　　
　　2.2平台服务层的设计。 平台在接收到调用请求之后，根据请求参数，完成渠道识别、请求存储、参数生成等工作，并在触发回调接口时，向指定接口发送回调通知。服务层按功能可以划分为接收请求、生成参数和处理回调3个部分。 不同的支付渠道在请求参数上存在差异，例如，支付宝网页支付和一键支付的请求参数中，service字段的值互不相同，平台据此识别支付渠道。同时，还可以根据发送请求的主机IP地址识别出用户身份。识别渠道后，平台向通信信息中存储接收请求，从渠道信息中获取该渠道的协定请求参数，根据协定请求参数对请求参数进行校验，判断参数是否合法，并根据签名算法验证签名，组装验证结果，完成接收请求部分的功能。如图4所示。
　　
　　利用识别出的渠道，平台从渠道信息中获取返回参数，根据参数生成机制，分别组装出前台返回参数与后台返回参数，结合渠道和用户身份，获取渠道的签名key,将其与需要进行签名的参数根据签名要求进行拼接，生成待签名字符串，利用签名算法生成签名。之后，利用识别出的用户身份，从用户信息中获取回调IP与端口号，修改从请求参数中提取的前台与后台回调接口，将其域名替换为回调IP加端口号。这样可以更好地适应开发测试环境，避免开发测试人员对回调地址进行修改。最后，平台向通信信息中存储发送请求。如图5所示。
　　
　　从通信信息中取出发送请求，以人工或自动的方式发送请求，根据返回的结果更新发送请求的发送状态。交易平台调用不同的模拟平台接口，会使用不同的回调处理方式，回调根据是否需要人工触发分为两类。
　　
　　（1）自动回调。根据请求参数判断通知类型，在生成参数之后主动触发回调接口，发送前台或后台通知。
　　
　　（2）人工回调。根据通知类型，在展示界面上提供不同回调接口，触发回调接口后，从展示层获取最新的发送请求参数，发送前台或后台通知，更新通信信息中的发送请求。
　　
　　2.3签名与参数生成算法。 签名与参数生成算法是服务层的核心内容，在请求参数校验、返回参数生成环节有重要作用。 不同的渠道有不同的签名方法，一是签名字符串的生成方法不同，二是签名算法不同。签名字符串的生成方法较为简单，各个渠道在参数拼接方法上有所差异，对汉字的编码处理上也有所不同，此外，一些渠道需要拼接电商平台的签名key,对此，模拟平台按渠道需求进行单独处理。各个渠道协定的请求参数中，一般会有标示签名方法的参数，模拟平台据此判断采用何种签名方法，如果没有标示参数，则根据渠道接口文档采用默认签名方法。目前流行的签名算法有MD5、RSA等，MD5属于对称加密，电商平台只需在渠道信息中配置渠道签名key即可，签名算法也很简单。RSA属于非对称加密，电商平台需要在模拟平台的渠道信息中配置其公开密钥，同时需要将本地配置的免签支付系统公钥修改为模拟平台提供的公钥，签名算法较为简单。 通过参数生成算法，模拟平台可以自动组装返回参数。首先，平台会获取返回参数中的“关联请求参数Id”和“参数格式”,如果“关联请求参数Id”不为空，则从对应的请求参数中取值，赋值给该返回参数，否则，平台会根据“参数格式”生成指定格式的随机参数值。“参数格式”分为两类，即日期格式和普通格式，日期格式中Y、m、d、H、i、s分别表示年、月、日、时、分、秒，字母之间可以增加“:”、“-”等链接符，服务层将对其进行解析，生成相应格式的时间。 普通格式类似于正则表达式的形式，正则表达式是一种形式化的字符串描述方法，只需很少的代码即可描述出应用遇到的任意字符串模式。平台根据需要对其进行简化，保留了“{}”、“[]”、“*”等常用字符，模拟平台对其进行反向解译，生成相应的参数值，例如：根据格式“moni[0-9]{5,9}”,模拟平台将生成以“moni”开头，以5到9位随机数字结尾的字符串。参数生成算法在产生免签支付系统订单号等参数值时有重要作用。
　　
　　2.4平台展示层的设计。 电商平台的开发测试人员与模拟平台的展示层进行直接交互，展示层也是直观的开发测试辅助平台，开发测试人员可在展示层观察参数、修改参数、触发回调。交易平台分为三个区域：请求参数区、返回参数区和回调触发区。请求参数区展示平台接收到的请求参数、参数说明以及每一参数的合法性。 返回参数区展示渠道的返回参数、参数值及参数说明，参数值以文本框或下拉列表的形式展现，可对其值进行修改，最终的回调参数以修改后的参数值为准。回调触发区放置回调触发按钮，根据回调类型，开发测试人员可分别触发前台通知、后台通知和前后台通知。展示层使用Bootstrap3前端框架，通过框架的栅格系统优化页面布局，便于之后的页面升级，同时也保证了展示层对移动端的兼容。
　　
　　二、免签支付系统支付系统开发费用
　　
　　1、从技术上来说，做一个最普通的网银收单跳转接口只接一个银行渠道，不含任何账务以及账户处理的话，需要大约1个月左右，如果有成熟的框架，1个人半个月加点班也就OK了，这里说的是普通程序员。人月=1个人干一个月的工作量，即一个普通程序员所需要的工资，魔都大约在7000左右（含税），但是公司需要承担公司税和四金部分，大约开销在10000左右（非精确计算，勿喷）根据每个城市的工资标准不一，工资也不一样，如果你是一个口才很好的老板，或者是一个“洗脑大师”，不给工资有人给你干的话，自然更好。
　　
　　2、如果要包括信用卡快捷，以及代收付，B2B等等其他的功能，并且希望多增加各种银行渠道，那么投资数额要翻番翻番~~我供职的上一家公司，一套系统做了2年，包括支付核心，账务核心，基础平台，商户平台等等，一共耗费了技术总监1人，项目经理4人，高工15人+，普工30人+，助理工程师20人+，加上20+的测试人员，大约投资N个千万，今年第一季度据说上线，但至今仍然未能商用（即接入真实商户跑真实交易）。
　　
　　3、上面两点都是针对技术的投资说明，非技术的呢？首先你得有商户接入你的平台，这里面包含了普通的营销投资，其次你得去谈合作的后端的银行渠道，这里面包含了特殊的营销投资（不是哪个银行都会和一个毫无名气毫无流量的免签支付系统进行合作的）。然后，是最重要的免签支付系统支付牌照，你得事先规划，你这个平台做的业务，这个业务需要哪个牌照才允许开展，然后去监管部门进行牌照申请，具体申请材料的准备，各种公关费用等等又是一笔开支。
　　
　　4、所以之前流行的一句话，没有2个亿的资金，不要跨入免签支付系统支付这个行业，至少不要自己进入，如果仅仅是帮免签支付系统支付公司做外包项目的话，那么请找专业的软件外包项目经理帮你评估项目的开发规模和所需要的人力资源。
　　
　　做成一个支付平台能够实现商用价值分两种方式：1、自建系统：投资金额2000+万元，200人团队、开发+测试，如果顺利需要1年时间（理想化）；不考虑更新业务模式和系统后期的拓展性
　　
　　5、外采系统：前期投资500+万元，最好是要求全部源代码交付。自己组建20人团队进行系统学习和摸索，后期自己进行二次开发
　　
　　举个事实的例子：自建系统是很多牛B公司的第一选择，像号称“中国系统之父”——用友集团、“无破界、不生态”——乐视集团、“我是金融公司而不是不是旅游公司”——途牛旅游.....很多，都是花大价钱、揣着大梦想来搞支付平台，最后是耗不起时间、经不起商用而被迫选择了采购成熟系统。