Mastering In-App and Third-Party Payments: A Complete Guide for Mobile Apps

Background

Payments can occur through many channels that differ across host environments such as in‑app, WeChat, mini‑programs, and browser H5. This article clarifies the common scenarios, processes, and APIs to guide developers when integrating new payment business, helping avoid pitfalls.

Business App Internal Payments

Inside a mobile app, the mainstream payment methods are divided into two categories: In‑App Purchase (IAP) and third‑party payment.

IAP (In‑App Purchase) allows users to complete purchases directly within the app. It generally provides a better experience than third‑party payment, but on iOS it is mandatory for virtual goods; otherwise the app will be rejected. Some developers temporarily enable IAP during review and switch to third‑party payment after approval, which carries the risk of being removed if detected. The 30% commission taken by Apple is a major reason for preferring third‑party solutions. Android also supports IAP (Google Play, Amazon Appstore), but the fragmented ecosystem often leads developers to choose third‑party payment.

Third‑Party Payment requires jumping to a third‑party app such as WeChat or Alipay to complete the transaction.

Both IAP and third‑party payments rely on a JS bridge to communicate between the front‑end and the native app. Using H5 inside the app is also possible.

Third‑Party Payment Flow

The flow involves five parties: user, business app, business server, payment platform client, and payment platform server (WeChat or Alipay).

User initiates payment.

App requests order creation API and receives an order ID.

Business server uses the order ID to call the payment platform’s order API and obtains pre‑payment information (prepay_id).

App receives the payment info and invokes the platform SDK to launch the third‑party app; the user enters a password to pay.

Payment platform server notifies the business server of the payment result.

App polls the business server for the final payment status.

Front‑end responsibilities:

Call the business order‑creation API to get the order ID.

Call the business payment‑initiation API to obtain payment info.

Use the JS bridge to pass the payment info to the native client, which launches the third‑party SDK.

After invoking the bridge, query the server (polling or WebSocket) for the payment status and update the UI.

IAP Flow

The IAP flow involves four parties: user, business app, business server, and Apple App Store.

Create IAP products in the App Store console and obtain product IDs.

Map the IAP product ID to the internal product ID.

User selects a product on the C‑side sales page and initiates payment.

Business server creates an order and assembles payment info containing the IAP product ID.

App uses the App Store SDK to submit the payment request.

The payment dialog appears; after user confirmation, the App receives a payment receipt.

App uploads the receipt to the business server.

Server validates the receipt with the App Store and records a successful payment.

App polls the server for the final payment status.

The front‑end steps are similar to those for third‑party payment.

Differences Between IAP and Third‑Party Payment

IAP offers a better user experience on iOS but incurs a 30% commission and requires more complex handling of crashes and receipt verification. Third‑party payment works on both iOS and Android, offloads most verification to the provider, and is generally preferred by developers despite a moderate user experience.

Payments Outside the Business App

WeChat In‑App H5 Payment (jsapi)

This scenario occurs when a user opens an H5 page inside the WeChat app. The flow is similar to third‑party payment, but the payment is launched via WeChat’s jsapi bridge.

Configure the payment directory; mismatched URLs trigger a “URL not registered” warning.

Obtain the user’s OpenID (required for order creation).

User initiates payment; the server creates an order and obtains pre‑payment data from WeChat.

The front‑end receives a PayParam object and calls the WeChat jsapi.

interface PayParam { appId:string; timeStamp:string; nonceStr:string; package:string; signType:string; paySign:string; } function onBridgeReady(){ const payParam:PayParam={ appId:'wx2421b1c4370ecxxx', timeStamp:'1395712654', nonceStr:'e61463f8efa94090b1f366cccfbbb444', package:'prepay_id=up_wx21201855730335ac86f8c43d1889123400', signType:'RSA', paySign:'...signature...' }; WeixinJSBridge.invoke('getBrandWCPayRequest',payParam,function(res){ if(res.err_msg==='get_brand_wcpay_request:ok'){ /* payment succeeded, still need to poll server */ } }); } if(typeof WeixinJSBridge==='undefined'){ if(document.addEventListener){ document.addEventListener('WeixinJSBridgeReady',onBridgeReady,false); }else if(document.attachEvent){ document.attachEvent('WeixinJSBridgeReady',onBridgeReady); document.attachEvent('onWeixinJSBridgeReady',onBridgeReady); } }else{ onBridgeReady(); }

WeChat Mini‑Program Payment

Mini‑program payment uses a similar flow but with a simpler API.

Obtain OpenID via wx.login (easier than H5).

User initiates payment; server creates an order and gets pre‑payment data from WeChat.

Mini‑program calls wx.requestPayment with the received parameters.

const payParam:PayParam={ timeStamp:'1414561699', nonceStr:'5K8264ILTKCH16CQ2502SI8ZNMTM67VS', package:'prepay_id=wx201410272009395522657a690389285100', signType:'RSA', paySign:'...signature...' }; wx.requestPayment({ ...payParam, success:function(res){}, fail:function(res){}, complete:function(res){} });

WeChat External H5 Payment (Browser)

This scenario involves a user opening a web page in a mobile browser, which then redirects to WeChat or Alipay for payment.

The flow includes six parties: user, browser, WeChat H5 intermediate page, WeChat client, WeChat payment server, and business server.

User initiates payment.

Business server requests a WeChat payment URL (e.g.,

https://wx.tenpay.com/cgi-bin/mmpayweb-bin/checkmweb?...&redirect_url=...

).

The app opens the intermediate page, which checks the network and launches the WeChat app via a deeplink such as weixin://wap/pay?prepayid=....

WeChat payment UI appears; after confirmation, WeChat notifies the business server of the result.

If a redirect_url was provided, the browser navigates to it after payment; otherwise it returns to the originating page.

After returning to the browser, the front‑end should let the user confirm before polling the server for the final status.

Best Practices

Based on the above flows, the recommended payment method for each scenario is:

Business app on Android: third‑party payment (recommended), H5 supported but poor experience.

Business app on iOS: third‑party payment (recommended), IAP possible but incurs commission.

WeChat H5: jsapi payment (recommended).

WeChat mini‑program: mini‑program payment (recommended).

External browser H5: H5 payment (recommended).

Q&A

Can an H5 page embedded in a mini‑program use its original H5 payment capability? No, but you can redirect to the mini‑program’s payment page via window.wx.miniProgram.navigateTo , though the experience is not as smooth.

Can an H5 page opened in a browser launch WeChat or Alipay payment when embedded in a native app? Yes, but the native client must handle the deeplink; returning to the original app after cancellation can be problematic.