Unity Iap 5 Fournisseurs de paiements: Une alternative aux paiements AppStore et google play

Unity In-App Purchasing (IAP) version 5.4 et plus récente prend en charge les fournisseurs de paiement tiers Stripe et Coda Payments comme alternative à la facturation traditionnelle de l'app store. Les paiements directs au consommateur (D2C) dans Unity permettent aux développeurs de contourner la facturation traditionnelle des magasins d'applications en acheminant les joueurs à travers les caisses sur le Web.

L'intégration est gérée via le tableau de bord Unity Gaming Services (UGS): les développeurs connectent un compte fournisseur via OAuth, déploient un catalogue de produits cloud ou le créent dans le tableau de bord cloud, et acheminent les joueurs via une caisse basée sur le Web qui revient au jeu via un lien profond où vous pouvez afficher un message de réussite ou d'échec d'achat.

Ce que vous devez savoir sur les fournisseurs de paiement dans Unity Iap 5

• Les fournisseurs de paiement tiers, Stripe et Coda Payments, sont disponibles dans Unity In-App Purchasing 5.4 et versions ultérieures.
• Les fournisseurs de paiement sont connectés dans le tableau de bord UGS sous LiveOps > Achats intégrés > Fournisseurs de paiement, à l'aide d'un flux d'autorisation OAuth avec un compte Sandbox ou fournisseur en direct.
• Le paiement se fait sur une page Web externe, de sorte que l'identité du joueur doit être vérifiée avec le package Unity Authentication (Unity Player Accounts, ou Anonymous Login) pour livrer les objets achetés au bon compte.
• Les catalogues de produits peuvent être gérés localement dans l'éditeur Unity ou déployés à distance sur le tableau de bord UGS (LiveOps > Achats intégrés > Catalogue). Le déploiement à distance permet aux équipes commerciales et marketing de modifier les prix et d'exécuter des promotions sans mise à jour de l'application côté client.
• Les URL de redirection après la commande doivent utiliser des liens profonds (par exemple, mygame://checkout-success) plutôt que des URL Web standard, de sorte que l'OS mobile ferme le navigateur et renvoie le focus sur le jeu automatiquement.
• Les règles de routage du panneau Fournisseurs de paiement UGS peuvent diriger les transactions vers différents fournisseurs par plateforme ou par pays.
• Vous pouvez configurer des tests de bac à sable dans Paramètres du projet > Environnements, créer un environnement de développement puis vous connecter via OAuth à un compte Stripe ou Coda sandbox, là vous pouvez tester le processus avec des numéros de carte de crédit fictifs, sans argent réel impliqué.
• Vous pouvez commencer avec le Minimal Coded IAP 5 Sample, importé de l'onglet Samples du package In-App Purchasing dans le Gestionnaire de packages.

Comment intégrer un fournisseur de paiement avec Unity Iap 5

L'intégration se déroule en sept étapes:

Faites des comptes. Reliez le projet Unity à une organisation Unity et à un ID de projet via la fenêtre Services, et créez des comptes développeurs chez Stripe et/ou Coda Payments (démarrez dans leurs environnements Sandbox).

Préparez le projet. Installez ou mettez à jour In-App Purchasing (5.4+) dans le Gestionnaire de packages et importez l'échantillon codé IAP 5. Installez le package Authentication et ajoutez un fournisseur d'identité (Unity Player Accounts ou Anonymous Login) sous Gestion des accès > Player Authentication dans l'UGS Dashboard.

Déployez le catalogue de produits. Configurez les éléments du catalogue (type de produit — Consommable, Non-consommable ou Abonnement — et prix de base) dans l’Éditeur, puis poussez-les vers le cloud via Services > Déploiement. Vérifiez les UGS sous LiveOps > Achats intégrés > Catalogue ou créez le catalogue directement dans le même tableau de bord LiveOps > Achats intégrés > Catalogue.

Environnements séparés. Créez un environnement de développement dans Paramètres du projet > Services > Environnements, sélectionnez-le dans l'éditeur et faites correspondre la chaîne d'environnement dans le script IAPService de l'échantillon (chaîne de caractères k_Environnement = "développement";). Couplez l'environnement de développement avec un compte fournisseur sandbox et la production avec un compte live.

Connectez le fournisseur. Dans le tableau de bord UGS, ouvrez LiveOps > Achats intégrés > Fournisseurs de paiement, cliquez sur Se connecter sur Stripe ou Coda, choisissez Compte Sandbox et autorisez le lien via la boîte de dialogue OAuth du fournisseur.

Configurer les redirections avec lien profond. Dans la carte de configuration de paiement, définissez Success URLs sur un schéma URL personnalisé afin que les joueurs soient renvoyés au jeu après avoir payé, l'objet étant rempli automatiquement. Les schémas personnalisés sont déclarés par la documentation Deep Linking d'Unity.

Testez et vérifiez. Jouez à la scène de l'échantillon codé dans l'éditeur, déclenchez un achat, complétez la caisse du bac à sable Stripe avec une carte simulée et confirmez le retour du lien profond avec une bannière confirmée par la commande. Vérifiez les transactions sur le tableau de bord du fournisseur (Mode de test) et dans UGS sous LiveOps > Achats intégrés > Journaux, à la recherche de Succès du créateur de commande suivi de Mise à jour de l'état de la commande (Succès rempli).

Le flux d'achat Unity Iap 5

Utilisez l'infographie ci-dessous pour afficher l'intégralité du flux d'achat pour Unity IAP5, y compris les nouvelles fonctionnalités, boutiques en ligne, catalogues et fournisseurs de paiement.

Téléchargez le PDF haute résolution ici.

Pièges courants lors de l'ajout de fournisseurs de paiement

• Joueurs bloqués après la caisse: en utilisant une page web simple comme URL Success, le joueur est laissé dans un navigateur externe après avoir payé, obligé de revenir au jeu manuellement si, par exemple, le joueur a utilisé un navigateur de bureau. Utilisez toujours un lien profond pour que l'OS les renvoie automatiquement à l'application ou traite les achats confirmés sur FetchProducts lorsque vous initialisez le jeu comme indiqué sur l'infographie.
• Mauvais environnement: développer contre l'environnement de production risque de casser les fonctionnalités en direct. Conservez un environnement de développement dédié avec un compte fournisseur sandbox, et assurez-vous que la chaîne d'environnement dans le code correspond à la sélection Editeur.
• Identité manquante : comme le paiement se fait en dehors de l’application, échouer à Unity Authentication signifie que les achats ne peuvent pas être appariés de manière fiable au bon compte joueur.
• Pages génériques : un portail de paiement sans marque rompt la continuité visuelle. Les tableaux de bord des fournisseurs (par exemple, Stripe sous Business > Branding) prennent en charge les couleurs hexagonales, la typographie et les logos de studio personnalisés pour correspondre à l'interface utilisateur du jeu.

En savoir plus sur la configuration des fournisseurs de paiement pour Unity Iap 5 →