微信小程序怎么内嵌网页实现支付

内嵌网页中可使用JSSDK 1.3.0提供的接口，可坑就来了，居然不支持支付接口的调用，经过一番研究，总算打通了两边的交互。

大概流程

1、先说明涉及到的文件，下面会用到

1.1 app.js:小程序的app.js文件,在globalData里定义一个全局变量paySuccessUrl: '',用来保存支付成功跳转url

1.2 wxminiwebview.js:小程序中放web-view的界面 1.3 wxminipay.js:小程序原生支付界面

1.4 web_pay.vue:内嵌网页会调起支付的路由组件界面，由于我是用vue+vue-router写的，所以你最好了解下vue和vue-router，记得引入微信jssdk1.3.0,最新版本才包含小程序相对应方法。很遗憾，微信并没提供npm包，github有人提供的commonjs引入方式的微信jssdk版本也只有1.2.0,所以就只能这样引入了。

<script src="./static/jweixin-1.3.0.js">script>

2、首先我们像官网那样正常嵌入一个内嵌网页,url是wxmini_webview.js中data中定义的变量，webview加载的就是网页就是这个url。

<web-view src="{{url}}">web-view>

3、在内嵌网页web_pay.vue里判断当前是否是微信环境。

window.wx.ready(function () {

isWxMini = window.__wxjs_environment === 'miniprogram'

})

4、在内嵌网页web_pay.vue调用支付时把支付金额，支付说明，支付成功跳转url...(任何你想要的参数，记得encodeURIComponent)，传给小程序原生页面。

if (isWxMini) {

let jumpUrl = encodeURIComponent(window.location)

let path = `/page/pay/pay?amount=${amount}&title=${desc}&jumpUrl=${jumpUrl}`

window.wx.miniProgram.navigateTo({

url: path

})

}

5、在小程序支付界面wxmini_pay.js里获取到内嵌网页传过来的值,这里演示方便,实际上是在page的data里存储这些会显示在界面的值好些。

onLoad: function (options) {

console.log(options)

// 获取网页传过来的值

// TODO 用es6解构来获取值TODO

jumpUrl = options.jumpUrl

amount = options.amount

title = options.title

...

},

6、支付成功后,把跳转url附带支付结果及当前时间保存到全局变量。

paySuccess () {

let currentTime = new Date().getTime()

//这是为了防止wxmini_webview.js文件里调用setData由于前后两个url一致导致路由不触发刷新的bug

jumpUrl = options.jumpUrl+encodeURIComponent(`?payResult=1&time=${currentTime}`)

//payResult=1表示支付成功，这里我偷懒了直接在url后面补?,实际情况比较复杂

//为了实现支付成功返回后的无刷新加载,这里的参数应该是属于路由web_pay.vue的,而不是属于window.location.search的

//所以要判断路由锚点#的位置和是否已经有路由参数（如果是vue-router的history模式我没用过,应该和window.location一样吧）

getApp().globalData.paySuccessUrl=jumpUrl //保存跳转url到小程序全局变量里

wx.navigateBack() //返回会上个页面，也就是承载网页的容器页面wxmini_pay.js

}

7、回到小程序wxmini_webview.js,会触发onshow,在里面进行界面无刷新加载。

onShow: function () {

console.log('on show')

let paySuccessUrl = getApp().globalData.paySuccessUrl

getApp().globalData.paySuccessUrl="" //清空支付成功url，防止一些 *** 作触发onShow事件

if (paySuccessUrl) {

let url = decodeURIComponent(paySuccessUrl)

this.setData({

//这里在次说明下步骤6中的&time=${currentTime},就是因为不加这个当你第一次支付成功回来这里

//这个url跟你第二次支付成功回来这里是一样的，会导致第二次支付开始，这里的setData方法失效

url

})

}

},

8、步骤7中的setData会触发webview中的网页加载，由于我采用的是vue-router,而且前后两个url只有路由的参数query不一样，所以并不会触发界面刷新，也不会触发路由的重新加载，而是只会触发beforeRouteUpdate 这个方法，举个例子，现在支付前界面是https://host/#/pay,然后支付成功后跳转https://host/?payResult=1&time=123456#/pay,此时界面不会刷新，pay路由也不会重新加载，而是触发beforeRouteUpdate (to, from, next),你要做的只是在这里界面解析to.query里的数据，然后该干嘛干嘛

beforeRouteUpdate (to, from, next) {

console.log('路由发生改变，很有可能是小程序的支付成功回调')

let payResult = to.query.payResult

if (payResult) { // 小程序支付成功

if (payResult === '1') {

console.log('支付成功,下班打卡走人')

}

}

next()

},

微信小程序内嵌webview，部分安卓机型无法打开h5界面，h5地址格式为：http://xxx?wxinfo=xxx,ios和大部分机型可正常打开内嵌的h5界面，考虑是传参格式问题，地址栏带参编码问题，解决方式如下：

小程序上：

let base64 = require('./base64.js')，引用base64进行编码进行传参

h5项目上：

进行base64.decode解析

在这之前，如果有人问我，在微信中做一个产品，是用小程序还是 Web 页面 (严谨，既不是 HTML5 更不是 H5…) 的时候，我会这么说：

产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。

营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。

关于后一点，朋友圈分享现在普遍会用海报来做，在这点上 Web 和小程序的能力其实是一样的，都是只能帮你保存图片到相册，再请用户手动发送到朋友圈。而小程序独有的发现 - 小程序、搜索框快捷方式等对用户回访特别重要的入口，Web 页面是不能使用的。

那么，昨天的发布意味着什么？简单地说，小程序的开发成本有了很大的下降。

微信小程序刚刚上线的时候，由于小程序使用类似 HTML、CSS 和 JavaScript 等 Web 语言的方式进行开发，让一些媒体误以为小程序就是 Web 开发，欢呼将「迎来 Web 开发的春天」。我自己的第一份工作就是 Web 开发工程师，Web 开发入门确实比较容易；可是尽管小程序使用了 Web 语言，那只是语法上的一致，整个开发模式完全不同，更接近于原生 App 的开发而不是 Web。打个比方，对在看这篇文章的大多数人来说，读中文要比读英文更容易，但假如你看不懂英文版的《量子力学导论》，翻译成中文版你也不一定能看懂。开发小程序，需要有专门的、独立于 Web 团队之外的团队，按小程序的规范重新设计、重新开发，不能将已有的产品直接迁移过来。

可以理解微信当初做这个决定，是希望开发者按照微信的要求，为微信的用户重新去思考、设计一套全新的用户体验，而不是将已有的 Web 页面搬进来。历史上，包括 Microsoft 的 Windows Phone 平台、Google 的 Chrome Packaged App 都冒过类似的险，而其实 Apple 也做过类似的决定——Steve Jobs 2010 年 4 月亲笔写过一篇文章，解释为何 iPhone 不支持 Flash (Thoughts on Flash)，其中最重要的原因是，Apple 不希望第三方开发者将已有的产品直接搬过来，而是希望开发者能直接在 iOS (当年还叫 iPhone OS) 进行开发，为 iPhone 的用户提供最好的体验。这些决定赌的是，新平台 (小程序或 iOS) 带来的商业上的好处，最终会让开发者们愿意付出这个成本。

那时候的 iPhone 还很弱小，但后来的历史证明 Steve Jobs 赌对了——Adobe 公司今年 7 月宣布，将在 2020 年最终停止 Flash 的更新和分发。

微信，则在昨天支持了开发者直接嵌入已有网页。

所以，如果你已经有一个网站，可以直接在小程序中套个壳，把网站中的 Web 页面摇身一变成一个小程序。至于这和直接分发 Web 页面有什么区别——

产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。

营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。

细心的你可能已经注意到了，上面这两条并没有任何变化… 对，在小程序的用法上其实没有任何变化，只是开发成本下降了。

那么，在今天之后，使用微信小程序框架开发的「原生」小程序，和嵌入已有的 Web 页面的「Web」小程序，在用户感受上会有什么区别呢？

「原生」小程序，整个小程序是提前下载的，不会有 Web 页面打开时的页面加载感。我们过去的可用性研究表明，这是用户对一个界面是「Web」还是「原生」的最主要判断标准。对于偏工具型的小程序，「原生」的感受应该会更好。

「原生」小程序对体验的控制更完整，自己要做的事情也更多。例如 Web 页面中用户可以选择页面上的文字复制，而在「原生」小程序界面中，这是需要单独添加的功能。

「原生」小程序提供了一些专属的控件和 APIs（接口），如展示群信息、发送推送等，这些只有使用小程序框架开发才能使用。

所以，如果需要和微信生态整合得更紧密，可以使用「原生」方式开发；如果追求快速迁移已有 Web 产品，嵌入 Web 页面更快。

---