CONSTRUIRE AVEC SHAREAI
Donnez aux clients un choix clair sur l'utilisation de l'IA, vos frais optionnels et chaque achat. Construisez un parcours de paiement qu'ils peuvent comprendre et contrôler.
L'expérience que vous concevrez
Payer avec ShareAIAccès clair. Conditions acceptées. Achats confirmés.
VOTRE MISE EN ŒUVRE
Gardez l'autorisation, les conditions acceptées et les paiements confirmés explicites dans votre produit et votre implémentation.
Le client comprend s'il connecte, utilise l'IA ou approuve un achat.
Le jeton et l'opération utilisent le compte et la portée prévus.
Publiez des offres compréhensibles et suivez la version acceptée par chaque client.
De nouvelles conditions ne modifient pas silencieusement un client existant.
Créez un achat prévu, vérifiez son statut payé et exécutez-le une fois.
Les réessais, annulations, paiements refusés et limites sont gérés.
INTÉGREZ-LE DANS VOTRE ÉDITEUR
Copiez le guide complet avec l'objectif de mise en œuvre, les entrées requises et les vérifications d'acceptation. Gardez les exemples de code, les tableaux et les liens de documentation ensemble.
Prêt pour votre projet, dans le format dont vous avez besoin.
Mis à jour
Vous distinguerez la connexion d'un compte, le paiement pour l'utilisation de l'IA et la confirmation d'un achat de produit.
Où vous travaillerez Votre produit → Expérience de paiement
Pay with ShareAI permet à un client d'utiliser son compte sélectionné ShareAI dans votre application. Il existe deux flux de facturation distincts : les demandes d'IA financées par le client sous une autorisation acceptée, et un achat de produit que le client confirme lors du paiement. Un balisage optionnel Builder est un accord supplémentaire sur l'utilisation de l'IA.
| Action du client | Ce qui se passe | Accès requis |
|---|---|---|
| Connecter un portefeuille | Crée une autorisation pour le compte sélectionné et les conditions acceptées. Aucun produit n'est acheté en cliquant sur Connecter. | openid plus les capacités utilisées par votre application. |
| Envoyer une requête IA | Utilise les crédits IA éligibles du compte autorisé et les conditions d'utilisation acceptées. | Accès d'inférence applicable ; monetization_gateway pour les termes de balisage acceptés Builder. |
| Confirmer un achat de produit | Débite l'achat particulier uniquement après une confirmation autorisée. | payments et une demande de paiement réussie. |
JamZY’s exemple de rendez-vous démontre le parcours d'utilisation de l'IA. Il n'a pas de passage en caisse marchand, ne demande aucun champ de paiement et ne prétend pas que la connexion achète un abonnement. Utilisez les chapitres restants lorsque vous ajoutez cette expérience distincte.
Votre bouton et le texte du produit indiquent si le client se connecte, utilise l'IA ou confirme un achat.
Vous obtiendrez l'autorisation du compte payeur prévu avant qu'une opération ne l'utilise.
Où vous travaillerez Console → Cas d'utilisation → Autorisation client
payments pour le paiement de produits, inference pour l'IA au coût réseau, et monetization_gateway pour un balisage d'IA approuvé. Demandez uniquement les capacités réellement utilisées par l'application.Un ID client identifie la plateforme. Un jeton d'accès représente l'autorisation client acceptée. Une version de contrat enregistre les conditions de facturation. Aucun de ces éléments seuls ne prouve qu'un paiement de produit particulier a été confirmé.
Le jeton appartient au client prévu et inclut les permissions pour l'opération que vous êtes sur le point d'effectuer.
Vous publierez des conditions d'utilisation claires que le client pourra examiner et accepter.
Où vous travaillerez Application → Abonnements
Dans Abonnements, créez des offres clairement nommées et expliquez les frais supplémentaires IA. L'ID d'abonnement est généré, en lecture seule et limité à votre application. Ces offres sont partagées entre les clients de la plateforme de l'application, donc vous ne maintenez pas une offre commerciale différente pour le Web et Android.
surcharge pour cette offre.Utilisez Estimation pour comparer le coût réseau, la surcharge et les revenus du builder pour le modèle choisi. Publiez un brouillon révisé comme la prochaine version de contrat. Les clients acceptent cette version lors de l'autorisation ; une offre publiée n'est pas la même chose qu'un accord client accepté.
Si vous avez seulement besoin du produit payments, utilisez le flux de contrat d'accès au paiement gratuit disponible plutôt que d'inventer un balisage Builder. Les prix et intervalles d'abonnement fixes ne sont pas configurés par l'éditeur d'offres d'utilisation actuel ; ne considérez pas une offre d'IA comme une facturation récurrente automatique.
Votre offre décrit avec précision ce qui est ajouté au coût de l'IA. Le consentement côté client montre les mêmes conditions publiées.
Vous introduirez un nouveau contrat tout en suivant les conditions acceptées par chaque compte.
Où vous travaillerez Abonnements → Contrats
Préparez les modifications dans le prochain brouillon de contrat. Les autorisations existantes conservent leur abonnement et version acceptés jusqu'à ce que le client accepte un remplacement. Comparez les comptes et les distributions dans l'aperçu des abonnements au lieu de supposer que chaque compte utilise la dernière version.
Informez les clients des modifications et faites-les passer par le processus de consentement pour accepter une nouvelle version si nécessaire. Un jeton actualisé ne peut pas fabriquer une acceptation. Conserver les contrats acceptés est la transition par défaut. Choisir d'exiger un consentement renouvelé avant d'autres actions interrompt délibérément l'accès existant jusqu'à ce que le client approuve les nouvelles conditions ; examinez cet impact avant publication. Toute diminution autorisée doit respecter les règles du contrat accepté ; une augmentation de tarif nécessite l'approbation du client.
Maintenez la vue au niveau de l'application et la limite d'identité séparées. Les identifiants spécifiques à la plateforme restent limités à leur contexte client même lorsque l'aperçu commercial agrège l'ensemble de l'application.
Vous pouvez identifier quel contrat chaque compte a accepté et expliquer comment il peut passer au suivant.
Vous créerez un achat prévu, obtiendrez une confirmation et vérifierez le paiement avant la livraison.
Où vous travaillerez Votre backend → ShareAI checkout → Vérification du paiement
Ce chapitre étend l'exemple de rendez-vous avec un achat de produit séparé. Exécutez-le uniquement après avoir activé les paiements et obtenu un jeton client avec cette portée. Conservez l'état de commande et de paiement sur votre backend.
# Real payment request: use scoped test access and an intentional amount.
curl --fail-with-body 'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: YOUR_UNIQUE_ORDER_REFERENCE' \
--data '{"title":"JamZY appointment preparation pack","amount":"1.00"}'curl --fail-with-body --get \
'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
--data-urlencode "id=$SHAREAI_PAYMENT_ID"| Statut de paiement | Ce que votre produit doit faire |
|---|---|
| en attente | Montrez que la confirmation du client est toujours requise. Ne pas exécuter encore. |
| payé | Vérifiez par rapport à la commande de votre serveur, puis exécutez une fois. |
| refusé | Respectez la décision ; laissez le client choisir s'il souhaite essayer un autre achat. |
| expiré | Créez une nouvelle demande avec une nouvelle clé d'idempotence lorsque le client souhaite réessayer. |
Utilisez uniquement une URL de paiement retournée par l'API de confiance, et validez-la par rapport à la politique de destination autorisée de votre intégration. Un message de succès de retour à l'application ne constitue pas une preuve de paiement. Le payeur ne peut pas acheter depuis son propre compte Builder.
Si vous prenez en charge un contrat d'abonnement à prix fixe existant, l'API de paiement peut utiliser ses conditions acceptées pour une période explicitement confirmée. Ne transmettez pas un prix récurrent inventé ni ne facturez une nouvelle période de manière silencieuse. JamZY’s exemple téléchargeable de rendez-vous n'implémente pas cette extension.
Aucune commande n'est livrée tant que votre backend n'a pas vérifié le paiement, et répéter le flux de confirmation ne peut pas livrer ou débiter la même commande deux fois.
Vous gérerez les limites de crédit et les déconnexions sans frais en double ni modifications inattendues du compte.
Où vous travaillerez Votre application → Récupération de facturation
L'utilisation de l'IA et les achats de produits ont des règles de crédit éligibles différentes. Un compte peut avoir des crédits éligibles à l'IA qui ne peuvent pas payer pour un produit. Gérez les fonds insuffisants et les limites de dépenses par application en utilisant l'erreur API et la destination de facturation du client.
Montrez au client le compte payeur choisi, l'action qui a échoué et une route pour gérer les crédits ou les limites. Le client contrôle son propre plafond ; le propriétaire de l'application ne peut pas l'augmenter. Ne passez pas silencieusement d'un compte organisationnel à un compte personnel pour réussir une facturation.
La déconnexion doit révoquer l'autorisation pertinente et effacer la session locale. Elle arrête les demandes autorisées futures ; elle n'annule pas un achat déjà confirmé ni ne résilie automatiquement un engagement payé distinct. L'échec de rafraîchissement, la révocation de l'autorisation et l'expiration du paiement nécessitent des messages de récupération distincts.
Les erreurs de crédit insuffisant et de limite laissent le client informé et en contrôle, sans commande en double accidentelle ni changement de payeur.
Vous testerez le chemin réussi et ses cas d'échec avant d'inclure la plateforme dans la publication.
Où vous travaillerez Paramètres OAuth → Vérification
Utilisez la liste des testeurs à l'échelle de l'application et un compte payeur éligible différent du Builder. Il y a au maximum cinq places de testeurs, y compris les invitations en attente. Complétez la vérification réelle des points de terminaison et des portées pour chaque plateforme incluse dans la publication.
inference ou monetization_gateway et l'appel API de paiement réussi requis pour payments. Une demande de paiement peut être en attente sans débit ; un test de paiement complet vérifie en outre la confirmation explicite et le paiement.Votre intégration distingue l'accès accepté, les conditions acceptées, le paiement demandé et le paiement confirmé, et gère le chemin d'échec pour chacun.
Sélectionnez le compte personnel ou organisationnel qui possédera l'inscription au programme avant de postuler. Les organisations peuvent soumettre une candidature avant vérification, mais l'approbation par le personnel seule n'active pas l'accès. Complétez la vérification de l'email de l'organisation et de l'entreprise à partir de la liste de contrôle d'intégration dans la Console. Une organisation approuvée reste En attente de vérification jusqu'à ce que les deux vérifications soient terminées. Builder, Provider et Creator suivent cette règle.
Voir la tarification Monetization Gateway · Explorer ShareAI for Startups · Scopes et permissions
Vos Conditions générales, Politique de confidentialité et instructions de suppression publiques doivent correspondre à l'application et rester accessibles sans connexion. L'acceptation du programme ShareAI, l'approbation Monetization Gateway, l'autorisation OAuth du client et le contrat de facturation accepté sont des décisions distinctes. Un rafraîchissement ne peut pas ajouter de permissions ou accepter de nouveaux termes commerciaux.
Le champ d'application hérité surcharge reste accepté pour les intégrations existantes. Les nouveaux exemples utilisent monetization_gateway. Conservez les champs existants tels que surcharge_bps et surcharge_percentage inchangés.
Voir la tarification Monetization Gateway · Explorer ShareAI for Startups · Scopes et permissions
Les frais standards 5% de la majoration Builder. Pour €2.00 du coût du réseau IA et une majoration de 10%, le client paie €2.20. ShareAI reçoit €0.01 de la majoration €0.20 ; le Builder a €0.19 avant l'Event Ingestion.
Les premières 1,000 requêtes de Production réglées Monetization Gateway sont gratuites chaque mois calendaire (UTC), partagées sur le compte Builder. Les requêtes supplémentaires coûtent €0.04 par 1,000 avant les remises éligibles. Une requête réglée crée un événement.
Pay with ShareAI seul, accès inference-uniquement, les clés API de compte ordinaire et le trafic de mise en scène ou de test n'entraînent pas d'Ingestion d'Événements Monetization Gateway.
ShareAI for Startups offre une allocation mensuelle partagée pour les frais réels ShareAI sur une application approuvée. Les niveaux actuels Launch, Growth et Momentum listent €1,000, €5,000 et €10,000 par mois. Le même budget couvre les frais en pourcentage de ShareAI sur la majoration Builder et l'ingestion d'événements facturables ensemble. Ce n'est pas une allocation de majoration brute, un quota d'événements gratuits séparé ou une IA gratuite inference. Les premiers 1,000 événements gratuits du compte ne le consomment pas.
Les frais restants d'ingestion d'événements sont payés à partir des nouveaux revenus de la demande Builder, puis des revenus disponibles Builder d'IA et des crédits IA non restreints. Les frais IA des clients et le produit payments restent séparés.
ShareAI peut approuver des frais spécifiques à l'application ou un soutien aux frais pour une période fixe ou jusqu'à modification. Consultez les tarifs actuels de l'application et les programmes spéciaux dans la Console pour ses conditions approuvées, sa validité et son allocation consommée. Un changement de niveau ou une modification des tarifs ne réinitialise pas l'utilisation mensuelle de l'application.
Launch garde Connexion avec ShareAI facultatif. Growth et Momentum l'exigent ; Momentum exige également l'insigne officiel ShareAI for Startups dans le pied de page de l'application. ShareAI vérifie l'insigne chaque semaine. Les tentatives confirmées de contourner les exigences peuvent entraîner une rétrogradation, une suppression du programme Startup ou un retrait du Marketplace selon les conditions du programme acceptées.
Les tarifs entreprise sont configurés par l'équipe ShareAI pour le compte Builder après accord sur une offre personnalisée. Le pourcentage assigné et le tarif par événement s'appliquent aux requêtes futures.
Voir la tarification Monetization Gateway · Explorer ShareAI for Startups · Scopes et permissions