Réduire les frais des app stores grâce aux achats intégrés

Rediriger le checkout de l’app vers le web en toute conformité

Lien vers un navigateur externe : les développeurs qui utilisent une WebView dans leur app ont peu de chances de réussir l’examen de l’iOS App Store. Redirigez plutôt vers un navigateur externe pour rester en conformité.

Vérifiez le pays de distribution : Apple ne prend actuellement en charge que le Japon, la Corée du Sud, l’UE et les États-Unis. Tenez compte de votre région.

Utilisez une solution préconfigurée pour assurer la conformité : outre les directives Apple, respectez les réglementations gouvernementales, bancaires et des réseaux de paiement applicables. Elles comprennent des normes de sécurité comme PCI, des règles de confidentialité telles que le RGPD de l’UE et le CCPA de Californie, ainsi que les informations exigées par les banques et les sociétés de cartes. Nous pouvons vous accompagner sur ces exigences.

Quand utiliser les paiements externes

Apple autorise les apps éligibles de l’App Store américain à diriger les utilisateurs hors de l’app pour acheter des contenus ou services numériques dans certains cas. Jeux, adhésions, abonnements, biens virtuels et contenus numériques disposent ainsi d’une alternative aux achats intégrés Apple (IAP).

Selon les règles App Review d’Apple 3.1.1 et 3.1.1(a), les apps de la boutique américaine peuvent intégrer des boutons, liens externes ou autres appels à l’action menant à des mécanismes autres qu’IAP pour acheter des contenus ou services numériques.

• Objets de jeu, monnaie virtuelle, niveaux et contenus virtuels
• Adhésions et abonnements
• Contenus et services numériques
• Apps souhaitant utiliser un checkout Web/H5 tiers pour les achats externes

Les règles actuelles d’Apple n’exigent pas de demander le StoreKit External Purchase Link Entitlement pour afficher boutons, liens ou appels à l’achat externe dans la boutique américaine. Avant le lancement, le marchand doit vérifier que son modèle économique, sa catégorie d’app, ses produits et les dernières règles de validation Apple s’appliquent à son cas.

Le paiement externe ne se limite pas à un lien

Ajouter un accès au paiement externe semble simple, mais un checkout fiable exige plus qu’une redirection. Il faut gérer les commandes, la confirmation du paiement, la livraison de produits ou droits, la validation des notifications, les remboursements, les exceptions et le rapprochement.

Au retour du checkout Web, l’app ne doit pas se fier uniquement au résultat du client. Les paramètres de retour améliorent l’expérience, mais ne prouvent pas le paiement. Le résultat définitif doit provenir d’une notification du serveur WooshPay ou d’une réponse à la consultation de commande.

Comment WooshPay facilite le checkout externe

WooshPay fournit un checkout mobile Web/H5 accueillant les utilisateurs depuis l’accès à l’achat externe de l’app et les guidant pour payer dans le navigateur.

• Création de sessions de paiement
• Affichage du marchand, du produit, du montant, de la devise et de l’expiration de la commande
• Moyens courants aux États-Unis, comme les cartes de crédit et de débit, et portefeuilles selon l’éligibilité de l’activité
• États de paiement réussi, échoué, en attente, clôturé et liés aux remboursements
• Notifications du résultat du paiement par le serveur
• Consultation des commandes, remboursements, rapprochement et rapports de transactions
• Vérification des signatures, gestion des risques, limites, prévention de la fraude, tests sandbox et vérifications avant lancement

Parcours de paiement recommandé

Quand l’utilisateur touche l’accès externe de l’app, le marchand crée une commande avec un identifiant unique. Son serveur fixe produit, montant, devise, ID utilisateur, canal et expiration, puis crée une session de paiement WooshPay.

L’utilisateur paie sur le checkout Web/H5 de WooshPay. Lors d’un changement d’état, WooshPay notifie le notify_url du marchand. Le serveur vérifie signature, ID commande, montant, devise et ID marchand avant d’accorder le droit numérique.

Au retour dans l’app, consulter l’état de la commande auprès du serveur du marchand plutôt que de se fier aux paramètres de redirection du client.

Ce que le marchand doit préparer

• Configurer un accès clair aux achats externes dans l’app
• Expliquer clairement que l’utilisateur rejoindra une page Web ou un checkout sécurisé pour terminer l’achat
• Créer des commandes avec des identifiants marchands uniques au niveau mondial
• Fixer produit, montant, devise, ID utilisateur, canal et expiration
• Gérer les états en attente de paiement, en traitement, réussi, échoué, clôturé et remboursé
• Configurer notify_url pour les notifications de paiement, remboursement et clôture de commande
• Vérifier signatures, IDs commandes, montants, devises et IDs marchands des notifications
• Traiter les notifications de manière idempotente pour éviter les livraisons en double
• Accorder adhésions, abonnements, monnaie virtuelle, objets ou autres droits numériques uniquement après confirmation du serveur
• Gérer notifications et paiements en double, commandes expirées, remboursements, annulations de paiement et commandes anormales

Aucune déclaration des paiements tiers à Apple n’est requise

Dans le cas américain décrit par le document source, le marchand n’a pas à déclarer les transactions de paiement tierces à Apple. Il doit conserver des dossiers complets de transactions, remboursements, rapprochement, risques et assistance pour ses besoins opérationnels et financiers.

Un checkout plus flexible pour les utilisateurs de l’App Store américain

Les paiements externes offrent un autre parcours d’achat aux apps de contenus et services numériques aux États-Unis. WooshPay relie les accès de l’app au checkout Web/H5, tout en gardant paiement, livraison, remboursements et rapprochement sous contrôle du serveur.

WooshPay réduit la complexité d’intégration, améliore la gestion des états et transforme les liens d’achat externe en checkout fiable, auditable et évolutif.

Au Japon, l’achat externe ne se limite pas à un lien de paiement

Apple permet aux apps iOS éligibles au Japon d’utiliser l’achat externe dans certains cas. Les éditeurs peuvent conserver Apple IAP et proposer aussi de payer dans le navigateur par défaut de l’appareil.

Il ne suffit pas d’ajouter un lien à la page produit. Les développeurs doivent gérer l’entitlement Apple, l’éligibilité régionale et de l’appareil, la visibilité équivalente d’IAP, Apple Disclosure, le navigateur par défaut, le retour par Universal Link, la livraison serveur et les déclarations à Apple.

WooshPay relie ces étapes avec un SDK, Hosted Checkout et un service de données de déclaration pour jeux iOS, créant un parcours externe prêt au lancement, auditable et plus simple à rapprocher.

Champ d’application

• Utilisateurs d’iPhone dans la boutique japonaise
• iOS 26.2 ou version ultérieure
• Jeux ayant demandé et configuré l’entitlement d’achat externe Apple pertinent
• Achats numériques nécessitant un paiement dans le navigateur en complément d’Apple IAP
• Biens numériques du jeu, comme objets, monnaie virtuelle, niveaux et contenus virtuels

Avant le lancement, vérifier l’applicabilité selon la documentation Apple Developer à jour, les exigences de validation, le modèle économique et la stratégie de publication.

Comment WooshPay facilite tout le parcours d’achat

Quand le joueur touche l’accès externe sur la page produit, WooshPay SDK exécute d’abord les contrôles Apple à l’exécution. Si le joueur et le contexte sont éligibles, il affiche Apple Disclosure puis, après confirmation, ouvre WooshPay Hosted Checkout dans le navigateur par défaut.

Après paiement, le joueur revient par Universal Link. Le client ne doit pas livrer d’objets sur la seule base de l’URL de retour : le serveur du jeu doit consulter l’état définitif WooshPay ou traiter son webhook avant livraison.

Fonctionnalités clés

1. Contrôle d’éligibilité avant chaque achat

Le SDK doit exécuter canMakePayments et isEligible avant chaque tentative, sans dépendre uniquement du résultat mis en cache au démarrage. Restrictions utilisateur, boutique, version iOS et état de l’entitlement influencent le résultat.

2. Prise en charge d’iOS 26.2/26.3 et iOS 26.4+

L’achat externe au Japon est pris en charge dès iOS 26.2+. Les parcours de jetons et de déclaration diffèrent entre iOS 26.2/26.3 et iOS 26.4+. WooshPay SDK peut couvrir les deux en maintenant une expérience cohérente.

3. Gestion des jetons LINK_OUT et création du registre

Sur iOS 26.4+, le SDK obtient un jeton LINK_OUT avant chaque transaction potentielle et l’envoie à WooshPay Server avant le checkout. Le jeton relie tentative d’achat, session, état de transaction et données de déclaration Apple.

4. Apple Disclosure avant d’ouvrir le navigateur

Apple Disclosure informe que l’utilisateur quitte l’environnement Apple pour traiter avec le développeur ou un tiers. Le SDK doit utiliser l’API fournie par Apple, pas une interface personnalisée similaire. Si le joueur ferme ou refuse l’avis, renvoyer l’état annulé sans ouvrir le navigateur.

5. Hosted Checkout dans le navigateur par défaut

Les liens externes doivent ouvrir une page ou un onglet du navigateur par défaut, pas un WKWebView ni une page de paiement intégrée à l’app. WooshPay Hosted Checkout gère moyens de paiement, risques, états, résultats et bouton de retour au jeu.

La livraison doit utiliser l’état définitif du serveur

Universal Link ramène le joueur dans l’app avec des données de commande consultables, mais ne prouve pas le paiement. return_url ne doit pas contenir de paramètre modifiable success=true déclenchant directement la livraison.

L’état définitif doit venir de WooshPay Server. Il est recommandé de combiner notifications webhook et consultations actives. Le serveur ne doit accorder adhésions, abonnements, monnaie virtuelle, objets ou autres droits que si la commande est SUCCESS et que montant, devise, commande et identité du joueur correspondent.

Ce que le développeur du jeu doit gérer

WooshPay regroupe paiement, ouverture du navigateur et données de déclaration, mais le développeur conserve des tâches essentielles commerciales et de conformité. Éligibilité Apple, présentation des produits, commandes, livraison et déclarations doivent être mises en œuvre selon son app, ses produits et ses comptes joueurs.

Configuration Apple et App Store

• Confirmer que l’app, le type de produit, la région du joueur et le cas d’usage relèvent du périmètre Apple de l’achat externe au Japon.
• Demander et configurer l’entitlement pertinent dans Apple Developer ou App Store Connect.
• Définir jp comme région autorisée dans le fichier entitlements Xcode et vérifier sa présence dans le paquet de production.
• Maintenir la cohérence entre bundle identifier, compte Apple, environnement de publication et app approuvée.
• Consulter la documentation et les directives Apple à jour avant lancement pour réduire les risques de validation liés aux changements de politique.

Page produit et accès à l’achat

• Concevoir l’accès externe sur la page produit, détail d’objet ou recharge, et ne l’afficher que dans les cas éligibles.
• Conserver Apple IAP disponible et au moins aussi visible que l’option externe en placement, poids visuel, texte et orientation.
• Expliquer clairement que le joueur quittera l’app pour payer dans un navigateur ou un checkout sécurisé.
• Éviter de suggérer qu’Apple traite l’achat externe et les réductions, couleurs ou mises en page détournant clairement les utilisateurs d’IAP.
• Si canMakePayments ou isEligible échoue, masquer ou désactiver l’accès externe ou guider vers Apple IAP selon la stratégie produit.

Intégration client et retour à l’app

• Initialiser WooshPay SDK au démarrage avec merchantId, environment, returnUniversalLink et niveau de journalisation.
• Appeler purchase uniquement lorsque le joueur touche activement l’accès externe ; ne pas déclencher le parcours sans action utilisateur.
• Configurer domaine Universal Link, fichier apple-app-site-association et Associated Domains.
• Gérer les états client : réussi, en attente, échoué, annulé, échec d’ouverture du navigateur et repli Universal Link.
• Ne pas stocker clés privées Apple API, issuer ID, key ID ou autres identifiants sensibles de déclaration dans le client.

Commandes et livraison côté serveur

• Créer un merchant_order_id unique mondialement et fixer produit, montant, devise, joueur, serveur, personnage et expiration.
• Intégrer les API serveur WooshPay pour créer des sessions, consulter des commandes, recevoir les webhooks et rembourser.
• Vérifier signatures webhook, IDs commandes, montants, devises, identité du joueur et protection contre le rejeu.
• Effectuer toutes les livraisons sur le serveur du marchand avec idempotence par merchant_order_id ou transaction_id.
• Définir des règles pour PENDING, FAILED, CANCELLED, EXPIRED et REFUNDED afin d’éviter les livraisons prématurées ou en double.
• Si le paiement réussit sans retour à l’app, le webhook doit tout de même déclencher la livraison serveur ; le joueur verra le droit mis à jour à la prochaine consultation d’état.

Déclarations, rapprochement et opérations

• Obtenir les données ou fichiers pour Apple via WooshPay Reporting API ou Dashboard.
• Transmettre les déclarations à Apple avec les identifiants/JWT propres au marchand et conserver la responsabilité des délais et de l’exactitude.
• Créer contrôles, nouvelles tentatives et pistes d’audit pour transactions réussies, remboursements, annulations, expirations, jetons sans transaction et corrections.
• Rapprocher paiements WooshPay, livraisons du jeu, remboursements et données Apple dans les processus financiers.
• Préparer des SOP d’assistance et d’exploitation pour annulations, paiements en attente, débit sans livraison, paiement sans retour, remboursements et récupération des droits.

Données de déclaration à Apple et limites de responsabilité

Les risques de déclaration au Japon incluent aussi annulations, expirations, paiements échoués, jetons sans transaction, remboursements et corrections. SDK et serveur doivent les traiter comme des états commerciaux formels, pas comme du bruit dans les journaux.

Le service de déclaration WooshPay tient le registre des jetons et relie transactions, remboursements, annulations, expirations et résultats sans transaction aux données ou fichiers destinés à Apple.

Par défaut, WooshPay ne conserve pas les clés privées Apple API, issuer ID ou key ID du marchand et ne transmet pas de déclarations en son nom. Le marchand utilise ses propres identifiants/JWT et garde le contrôle des identifiants ainsi que la responsabilité juridique et financière.

Créez des achats externes pour jeux iOS au Japon avec WooshPay

L’achat externe offre une nouvelle voie de paiement aux jeux iOS au Japon, avec de nouvelles exigences techniques, de validation et de déclaration. WooshPay relie SDK, Hosted Checkout, synchronisation des états et génération des données pour lancer une expérience contrôlée, rapprochable et évolutive.

WooshPay réduit le développement répété des parcours Apple, simplifie ouverture du navigateur et retour à l’app, permet une livraison fondée sur l’état définitif du serveur et prépare des données structurées et auditables pour Apple.