API d'historique des achats In-App
Lisez les achats In-App précédents de l'utilisateur depuis votre application web au format JSON — parfait pour les pages « Mes achats ».
L'API d'historique des achats In-App renvoie la liste des achats précédents de l'utilisateur effectués via l'API d'achats In-App sur cet appareil et l'injecte dans votre application web sous la forme de window.purchaseHistory. Assurez-vous de posséder une Extended License de WebViewGold si vous prévoyez d'utiliser cette fonctionnalité dans un produit final.
Utilisation :
<a href="getpurchasehistory://" onclick="setTimeout(renderHistory, 300)">Mes achats</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>
Format des données :
{
"purchases": [
{
"productId": "com.example.premium",
"transactionId": "2000000123456789",
"purchaseDateMs": "1721600000000"
}
]
}
purchaseDateMs est l'horodatage de l'achat en millisecondes Unix (sous forme de chaîne).
Cas d'utilisation typiques :
- Afficher une page « Mes abonnements » ou « Mes achats » dans votre application web.
- Déverrouiller du contenu premium côté client sur la base d'achats passés, sans solliciter votre backend.
- Flux de débogage et de support client.
Remarques : la liste contient les achats effectués dans l'application sur cet appareil. Elle est stockée localement et n'est donc pas synchronisée entre appareils — pour des vérifications de droits multi-appareils, validez plutôt les reçus sur votre serveur.
Notes d’implémentation façon SDK
Considérez cette fonctionnalité comme une capacité native exposée à votre couche web : conservez votre site web de production ou votre PWA comme source de vérité, puis utilisez les indicateurs de configuration WebViewGold documentés, les commandes URL et les appels du pont JavaScript pour activer le comportement natif iOS uniquement là où il apporte de la valeur. Cette approche garde votre base de code maintenable, car la même application web peut servir les navigateurs, WebViewGold pour iOS et les autres plateformes WebViewGold avec un minimum de logique conditionnelle.
Pour des résultats fiables, privilégiez les points de terminaison HTTPS, des noms de routes stables, des états de succès/erreur explicites dans votre interface et de petites fonctions JavaScript qui encapsulent les appels natifs. Par exemple, une application web créée avec jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, une pile React/Vue/Angular personnalisée ou du HTML statique peut exposer un seul bouton ou gestionnaire d’événement qui déclenche l’API native WebViewGold tout en affichant une solution de repli élégante dans le navigateur.
- Modèle d’intégration recommandé : détectez le contexte de l’application, appelez l’API WebViewGold, puis mettez à jour votre interface web après le rappel natif ou le changement de route.
- Liste de vérification des tests : validez la fonctionnalité sur un appareil réel ou une build empaquetée, vérifiez les autorisations et le texte de revue du store, et confirmez que les utilisateurs navigateur uniquement reçoivent toujours une solution de repli utile.
- Avantage SEO : gardez les pages de fonctionnalités, les titres de routes et le contenu structuré indexables sur votre site web pendant que WebViewGold fournit l’enveloppe d’application native pour les utilisateurs iOS.