公网Web应用控制本地网络POS支付终端的实现方案咨询

你现在用的WCF方案可以实现需求，但对C#基础薄弱、没有Windows服务开发经验的开发者来说门槛偏高，有更轻量易落地的替代方案：

• 首选ASP.NET Core极简本地HTTP服务：直接用ASP.NET Core写个只监听本地固定端口的HTTP服务，只需要配置允许你公网Web应用域名的CORS规则，前端JS直接用fetch就能发起请求，逻辑和你之前用XMLHttpRequest调用WCF完全一致，但代码量只有WCF实现的三分之一不到，全程不用碰WCF复杂的配置体系，上手难度和你之前写控制台应用差不多。
• 如果你的银行卡支付终端有官方提供的本地驱动，优先对接官方自带的本地服务能力：大部分正规支付终端的驱动都会自带本地WebSocket/HTTP监听能力，不用你自己开发本地服务，直接按官方文档调接口就行，省掉后续服务维护的工作量。

如果你还是要继续用WCF方案，按以下步骤测试可靠性最高，不用上来就部署成Windows服务：

• 第一阶段先拿控制台程序承载WCF服务运行，直接在控制台打日志排查问题，测试的时候直接用浏览器控制台写JS调用代码，或者用Postman发请求调接口，把所有参数、返回值、支付终端的交互逻辑都调通之后，再封装成Windows服务，避免调试的时候反复启停系统服务、查系统事件日志的麻烦。
• 可以用系统自带的WcfTestClient工具测试，打开Visual Studio的工具目录就能找到，输入你的WCF服务地址后会自动枚举所有可用接口，直接填参数就能发起调用，不用自己写测试代码。
• 测试的时候要注意两个必做配置：一是给你用的服务端口加Windows防火墙入站规则，不然本地网络里的支付终端访问不到你的服务；二是WCF绑定的地址要设为0.0.0.0而非127.0.0.1，才能接收本地网络内的请求。

针对你只有基础C#控制台开发经验的情况，按以下分步走的路径落地风险最低：

• 优先放弃WCF方案选ASP.NET Core极简API方案：新建ASP.NET Core空项目，核心逻辑只需要两个接口，一个接收前端的支付请求，转成支付终端要求的数据包发送，另一个把终端的处理结果返回给前端，所有逻辑都可以在Program.cs里写完，和写控制台程序的逻辑差异极小。
• 所有逻辑测通后再部署成系统服务：ASP.NET Core自带托管为Windows服务的官方包，只需要加一行配置代码，之后用sc create命令就能注册成Windows服务，设置开机自启即可，完全不需要研究Windows服务的底层开发逻辑。
• 支付场景必须加安全校验：本地服务要严格校验请求来源，只允许你自己的公网Web应用域名的跨域请求，所有接口必须加签名校验，避免被恶意网页调用发起非法支付请求。

内容的提问来源于stack exchange，提问作者ScrawnyYawny