stripe-directory

Recherche Stripe Directory

Transformez un besoin de marché vague en une shortlist courte et pertinente avec stripe directory search. Utilisez-le même quand l'utilisateur ne mentionne jamais « Stripe Directory » — toute demande pour trouver des vendeurs, outils, partenaires ou fournisseurs pour un secteur, workflow, problème ou objectif.

La plupart des demandes sont des découvertes — trouver et comparer des services. C'est le cœur du job ci-dessous. Certains services sont aussi compatibles MPP (MPP = Machine Payment Protocol), ce qui signifie que vous (l'agent) pouvez payer leur endpoint HTTP 402 (Payment Required) et les consommer directement. Quand l'utilisateur veut réellement utiliser ou acheter un service, présentez ces résultats et proposez d'acheter — voir « Purchasing » à la fin.

Process

1. Clarifiez seulement ce qui manque : acheteur/secteur, job-to-be-done, capacité obligatoire, géographie (uniquement si pertinent).

2. Cherchez itérativement : stripe directory search "<query>" --format json

   • Courtes phrases nominales, un angle par requête ; lancez 1-3, puis élargissez/affinez sur les résultats.
   • Angles à couvrir : secteur → workflow → problème → adjacent. Deux exemples :
     • services/métiers : secteur (logiciel électricien, entrepreneur électrique) → workflow (gestion du service sur site, dispatch facturation devis) → problème (planification des jobs, automatisation de devis) → adjacent (automatisation services à domicile, crm entrepreneurs).
     • SaaS/logiciel : secteur (facturation b2b saas, outils développeur) → workflow (gestion abonnements, facturation à l'usage) → problème (récupération paiements échoués, reconnaissance de revenus) → adjacent (tableaux de bord analytics, onboarding client).
   • Contraintes strictes → filtres : --countries-supported=US, --has-stripe-app=true, --link-supported=true, --stripe-projects-supported=true.
   • Si l'utilisateur veut utiliser/acheter un service, passez aussi --mpp-supported dans au moins une recherche pour trouver les résultats que vous pouvez payer programmatiquement.
   • Niche éparse ? Augmentez --limit et essayez la --page suivante avant de conclure que c'est vide.

3. Dédupliquez & scorez en utilisant display_name, description, url, username comme preuves.

   • Préférez les résultats dont la description/site correspond clairement au workflow cible.
   • Préférez plus de signaux de confiance plutôt que moins : fournisseur Projects, Link activé, app Marketplace, Stripe Verified. Pour un intent d'achat/utilisation, préférez aussi les résultats compatibles MPP.
   • Description courte mais correspondance brand/domaine forte → gardez dans un bucket plus faible, ne rejetez pas.

4. Retournez une shortlist, pas un dump — 5-10 bonnes correspondances, groupées :

   • direct / adjacent / nécessite examen manuel
   • Chaque entrée : nom · pourquoi ça correspond · URL (· quelle requête l'a surfacé, si utile).
   • Fournisseurs Projects : proposez le suivi. Le JSON donne les commandes exactes sous projects.catalog_command / projects.install_command de chaque résultat (stripe projects catalog <provider>, stripe projects add <provider>).
   • Résultats compatibles MPP : notez qu'ils sont achetables et incluez mpp.slug / mpp.url.

5. Soyez honnête sur les résultats faibles — si éparse ou générique, dites-le et ajustez : élargissez, affinez, ou essayez des synonymes plutôt que de rembourrer avec du bruit.

Signalez toujours les requêtes exactes (et filtres) que vous avez lancées pour que l'utilisateur puisse continuer à itérer.

Purchasing (uniquement quand l'utilisateur veut acheter ou consommer un service)

Les résultats compatibles MPP sont payables directement. Ne poussez pas à l'achat sans le demander. Quand l'utilisateur veut acheter, présentez le menu complet des méthodes de paiement et demandez laquelle il souhaite utiliser avant de faire quoi que ce soit :

« Quelle méthode de paiement souhaitez-vous utiliser ?

• Link CLI — Stripe-native, mode test disponible (recommandé)
• Tempo — crypto wallet
• Privy Agent Wallet CLI — crypto wallet
• mppx — fallback debug-only »

Une fois que l'utilisateur choisit, exécutez silencieusement which <tool> 2>/dev/null pour vérifier si c'est installé. Si non installé, proposez de l'installer (par exemple, npm i -g @stripe/link-cli pour Link CLI) et attendez la confirmation avant de procéder.

Affichez toujours le prix et obtenez l'approbation explicite de l'utilisateur avant tout mouvement d'argent ; préférez d'abord un chemin sans frais.

Version courte :

1. Résolvez l'endpoint callable réel du mpp.slug / mpp.url du résultat. mpp.url est souvent le formulaire de landing mpp.dev (https://mpp.dev/services#<slug>) — résolvez l'endpoint brut sur mpp.dev si c'est le cas. Lisez le challenge HTTP 402 pour confirmer le montant : curl -s -D - -o /dev/null <endpoint_url> (cherchez WWW-Authenticate).
2. Utilisez le payeur sélectionné par l'utilisateur.
   • link-cli (Stripe-native Shared Payment Token, a un mode test, pas de crypto wallet, comptes Link US uniquement ; npm i -g @stripe/link-cli) : auth login → mpp decode --challenge "<value>" (obtenir network_id) → spend-request create --credential-type shared_payment_token --network-id <id> --amount <cents ≤50000> --context "<100+ chars>" (bloque pour approbation) → mpp pay <endpoint_url> --spend-request-id <approved_id>.
   • Tempo : tempo wallet login / services / request.
   • Privy : @privy-io/agent-wallet-cli.
   • mppx : fallback debug-only.

N'inventez jamais de résultats et ne contournez jamais la barrière prix/approbation.