In-App Purchase History API
Read the user's previous in-app purchases from your web app as JSON — perfect for "My purchases" pages.
The In-App Purchase History API returns the list of the user's previous purchases made through the In-App Purchases API on this device and injects it into your web app as window.purchaseHistory. Make sure to own an Extended License of WebViewGold if you plan to use this feature in an end product.
How to Use:
<a href="getpurchasehistory://" onclick="setTimeout(renderHistory, 300)">My purchases</a>
<script>
function renderHistory() {
const data = window.purchaseHistory;
if (!data) return;
data.purchases.forEach(function (p) {
console.log(p.productId, p.transactionId, p.purchaseDateMs);
});
}
</script>
Payload Shape:
{
"purchases": [
{
"productId": "com.example.premium",
"transactionId": "2000000123456789",
"purchaseDateMs": "1721600000000"
}
]
}
purchaseDateMs is the purchase timestamp in Unix milliseconds (as a string).
Typical Use Cases:
- Show a "My subscriptions" or "My purchases" page inside your web app.
- Client-side unlock of premium content based on past purchases without hitting your backend.
- Debugging and customer-support workflows.
Notes: The list contains purchases made within the app on this device. It is stored locally, so it does not sync across devices — for cross-device entitlement checks, validate receipts on your server instead.
SDK-style implementation notes
Treat this feature as a native capability exposed to your web layer: keep your production website or PWA as the source of truth, then use the documented WebViewGold configuration flags, URL commands, and JavaScript bridge calls to opt in to native iOS behavior only where it adds value. This approach keeps your codebase maintainable because the same web application can serve browsers, WebViewGold for iOS, and the other WebViewGold platforms with minimal conditional logic.
For reliable results, prefer HTTPS endpoints, stable route names, explicit success/error states in your UI, and small JavaScript helper functions that wrap native calls. For example, a web app built with jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, a custom React/Vue/Angular stack, or static HTML can expose a single button or event handler that triggers the native WebViewGold API while still showing a graceful browser fallback.
- Recommended integration pattern: detect the app context, call the WebViewGold API, then update your web UI after the native callback or route change.
- Testing checklist: validate the feature on a real device or packaged build, verify permissions and store review text, and confirm that browser-only users still receive a useful fallback.
- SEO benefit: keep feature pages, route titles, and structured content indexable on your website while WebViewGold delivers the native app shell for iOS users.