绝大部分情况下不需要调用微信开放平台的接口，只用到了微信公众账号的开发者模式就完成了；
如果想进一步改善用户体验，需要使用服务号调用微信 网页授权获取用户基本信息 接口。
基本认证流程：
用户设备（手机、Pad、笔电）连接到Wi-Fi热点
提供热点的终端节点（路由器/AP）上的WiFiDog拦截用户网络，将用户HTTP请求转向到云端AC服务器
（可跳过）云端AC服务器返回网页提醒用户进行认证
（可跳过）用户在网页或APP里完成认证（开放认证、粉丝认证、自主或定制认证）
云端AC服务器通知终端节点放行
抛开更多技术细节，主要补充说明：
如何判断当前用户是否关注了商户的微信公众账号？
为了避免太复杂的描述，以下讨论的前提是该商户的微信公众账号启用开发者模式并接入相应的接口实现服务器（一般由我这样的商业公共WiFi服务的第三方提供，或者我的客户），实现思路主要有两种：
不需要使用微信公众平台高级接口（思路：用户能与本公众账号互动，就说明已经关注）：
用网页、水牌、桌贴等提示用户关注商户的微信公众账号，然后分两种情况：
A. 用户刚刚关注，服务器在用户关注时自动下发的信息（一般是多图文，当然也可以要求用户发“上网”关键字），其中有一条目的是引导用户点击，例如“点此免费使用WiFi”——该条目对应的url里带了一个对应该设备（用户）的唯一的、一次性的token——用户点击该链接后转到对应的页面——此时服务器从链接中获得了这个token——服务器通知AP（放在商户现场的路由器）放行该设备（用户）；
B. 用户曾经已经关注过，请对该商户的微信公众账号发送某个关键字，如“上网”，或在商户微信公众账号菜单中点“上网”——服务器返回图文信息，其中有一条引导用户点击，后续同A
——核心思路：用户只要能和商户的微信公众账号互动，就意味着已经关注了该商户。因此，只需要将商户微信公众账号设为开发模式，并接入到相关服务器即可，不需要开通高级接口。
使用微信公众平台高级接口：
又分为两种情况：
A. 调用用户信息接口 获取用户基本信息(UnionID机制) （参考上文，此为无用的方案）——与上文区别不大，只不过通过调用接口判断是否是粉丝——可是，也需要用户至少一个操作来获取OpenId——既然交互了、能获取OpenId了，说明用户已经关注本公众账号，还需要调用接口么？
B. 调用OAuth-Basic接口 网页授权获取用户基本信息（注意：必须是在微信内嵌浏览器中，而且只有服务号有权限）：用户浏览器访问网页的请求被智能WiFi拦截并强制转向到商户的手机门户——在商户的手机门户的页面中加入对微信高级接口之OAuth-Basic的调用，获得当前用户（注意：对应当前商户微信公众账号）的OpenId——然后在服务器端保存的该商户的粉丝列表里匹配是否已有对应项——已有，服务器通知AP（放在商户现场的路由器）放行该设备（用户）——额外地，服务器端需要通过微信公众平台的粉丝关注和取消关注接口来维护粉丝OpenId的列表
——嗯嗯，熟悉服务号和高级接口，并细心的朋友能发现这里面还有扩展的空间和玩法。
至于在微信中发个消息、点个菜单后，微信回复预设好的WiFi密码——这是古时候某些号称国内最早、国内唯一的能用微信和WiFi关联的厂家的玩法，就不讨论了，呵呵
好，这里面有个延伸问题：
已经关注商户微信公众账号的用户 可以无感地自动可以访问网络么？
以上方法中，方法1显然是离不开用户与商户微信公众账号的互动的；方法2，如果用户已经关注过则可以实现无感体验的。
——但是，从商户甚至是商业公共WiFi服务方的利益来说，就是需要让用户在上外网前，先看看有些什么样的信息嘛
当然，我们自己是否定用商业公共WiFi发广告的商业模式的。
昨天和阿里大数据的PM聊的很开心，因为我们是用心做商户联盟、数据采集和拼图的，呵呵
其它细节参考回答：大数据时代，在街头安装收集移动设备 MAC 地址的装置，会不会是新商机，有哪些运用可能，有法律风险吗？
-------------------------补充分享------------------------------
嗯，对了，这两年见过很多公司表示不屑一顾：这事儿简单嘛，没什么技术门槛。
是的，这事儿不是不能做，也的确不算难做，但说三个方面谨供各位头脑发热的同行参考：
技术门槛永远不是门槛，从开发实现一个简单环境中的Demo到能够投入市场商业化运作，这里面大大小小的坑不计其数——这毕竟不是学生做一个毕业设计交给老师点击下看看就给个分数，何况门槛越低竞争越激烈；
商业化运营中，为了最大程度照顾好商户和用户的体验问题，我们是有专门的网络工程师团队来支撑的，这里面的成本并不低；
考虑好你的盈利模式、退出机制是什么？——不要告诉我你钱多、砸钱圈地（好吧，砸我吧）。
这事儿一定是相当红的红海，而且没多久以后注定三大阵营：BAT、三大运营商和虚拟运营商和硬件厂家（比如Fon的模式）、某些具备行业资源的大公司（机场、飞机、铁路、交运、公交、地铁等等），小公司也不是一点生存不下去，只是重点一定不在WiFi甚至不在C端（抢不过BAT等）
-----------------看别的回答发现了点问题，补充分享----------------
相关从业者 匿名用户 的回答虽然很有参考性，但仔细看了下有很大的问题，比如这一段：
a、完全不具备任何开发能力，路由器是贴牌从别的公司买来的。
b、具备一定的wap页面开发能力，可以对商家wifi连接成功的微网站做一定的开发优化
c、拥有固件开发能力，可以对路由器功能做定制，包括微信登陆、微博登陆等方式的开发（实际上是路由器mac地址控制类的技术）。
d、掌握了无线射频探测技术和初步商业化的能力。
e、有稳定的代工厂和硬件设计能力。
其实，如果结合自身特点考虑好产品定位、再换一种设计思路，路由器硬件、固件都不是问题。比如我们的产品和技术实现的设计思路有几个要点（为避免广告，不讨论具体细节，尽量用白话描述意义而不是产品本身）：
终端无关：无论终端设备使用的是开源系统和固件如DD-Wrt、Open-Wrt，还是极路由等，前者有WiFiDog，后者可以做插件，但到了WiFi接入和认证服务器、Portal（门户和具体应用）服务器都是一样的——也就是说可以兼容任何终端设备（AP、胖AP、AC）；
简化认证模型，Radius无关：没有使用Radius认证，同上，我们封装了一套Web API，无论任何终端设备中的WiFiDog或者极路由插件等，通过Http/Https与接入和认证服务器通讯，随后由Portal服务器接管以进行业务判断、提供更丰富的内容和应用；
支持不同级别的漫游：一般都支持AC内的若干AP间漫游（比如KTV、电影院），额外可以支持同一商户的不同路由器/胖AP（节点）之间漫游（比如更大的ShoppingMall、机场、旅游景区），当然，甚至可以支持商户之间的漫游——取决于业务需求。只是，好的设计让你可以很简单实现，不那么好的设计会比较累吧；
与现有产品可以很快速、简单集成——WiFi接入管理和认证的系统，与Portal系统（手机网站、具体业务）分离，后者可能是第三方（比如我们的客户）自己的系统，提供了各种特色的内容、服务，必须让他们可以很快速、简单的在已有产品中加入和对接智能WiFi；
WiFi接入和认证服务器可以和第三方认证服务器对接：比如，有银行客户想采用我们的系统并且与我们开展商盟的联盟营销方面的合作，但总部推荐了另外的技术公司。考虑到银行营业厅的特殊性、采集数据的价值，我们建议他们采用总部推荐的技术公司的产品（利益问题），但可以对接数据或者接口。同理，可对接大型商场已有的WiFi，甚至运营商的CMCC、ChinaNet——考虑清楚自己的核心优势是什么？技术？no, no，有核心优势外加终端无关，一样可以推翻之前使用的别家的产品重来（有没有必要罢了）；
MAC地址无关：MAC地址不是商业公共WiFi的核心诉求，别走偏了。MAC地址固然好，类似于Cookie，能唯一标识一个“设备”（设备可能会更换，也可能有多个）。但是如果没有MAC地址是不是就什么也不能干了？不是滴，核心在于通过用户的各种数据拼碎片，MAC地址是其中比较好用的一种罢了；
个人坚持不碰无线射频探测：好嘛，还是冲着MAC地址来的，呵呵。上面说了，我们的产品设计思路与MAC地址无关，不是没能力实现MAC Sniffer而是存在相当大的隐私泄露方面社会事件和法律相关风险，比如近期的新闻和问题：iOS 8 设备随机 MAC 地址躲避 Wi-Fi 热点的记录追踪，技术上是怎么实现，有何影响？从用户角度或者商业角度，个人都期望类似技术尽快流行，避免甚至打击MAC嗅探技术的过度使用。其实这类问题不妨邀请芝麻科技等来回答。
因此，对照匿名用户的几条来看，其中C是错误的，微信登录等不需要固件开发能力，也与MAC地址控制无关；B是我们的目标客户和合作伙伴；A和E意义不大；D可能面临较大的风险——个人感觉匿名用户所在公司的产品定位、设计思路和技术路线有问题。同样，@张强 的技术实现思路也比较传统甚至过时了。
所以，不要纠结设备是否是找厂家定制的了——这是传统厂家的优势，它们也会来做商业公共智能路由的（貌似Dlink已经推出了吧）；不要纠结系统和固件了——这是海蜘蛛、WayOS等等的地盘；不要纠结是否自己去从0实现了——有解决方案提供商和成熟商业产品、运营经验了。
呵呵，我们是在开始启动之前已经分析好这些优劣势才决定了产品的定位和设计思路的，个人以为非常值得同行参考。
追问订阅号可以设置吗？