stripe-directory

Recherche dans le Répertoire Stripe

Transformez un besoin de marché vague en une courte shortlist pertinente avec stripe directory search. Utilisez cet outil même quand l'utilisateur ne mentionne jamais « Stripe Directory » — toute demande pour trouver des vendeurs, outils, partenaires ou prestataires pour un secteur, workflow, point douloureux ou job-to-be-done.

La plupart des demandes sont des découvertes — trouver et comparer des services. C'est le cœur du travail ci-dessous. Certains services sont aussi supportés par 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 vraiment utiliser ou acheter un service, présentez ces résultats et proposez l'achat — voir « Purchasing » à la fin.

Process

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

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

   • Courtes phrases nominales, un angle par requête ; lancez 1-3 requêtes, puis élargissez/réduisez selon les résultats.
   • Angles à couvrir : secteur → workflow → point douloureux → adjacent. Deux exemples :
     • services/métiers : secteur (logiciel électricien, entrepreneur électrique) → workflow (gestion du service sur le terrain, dépêche facturation devis) → point douloureux (planification des travaux, automatisation des devis) → adjacent (automatisation des services à domicile, crm entrepreneur).
     • SaaS/logiciel : secteur (facturation b2b saas, outils développeur) → workflow (gestion des abonnements, facturation à l'usage) → point douloureux (récupération de paiements échoués, reconnaissance des revenus) → adjacent (tableaux de bord analytiques, onboarding client).
   • Contraintes dures → 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 clairsemé ? 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 preuve.

   • Privilégiez les résultats dont la description/site correspondent clairement au workflow cible.
   • Privilégiez plus de signaux de confiance sur moins : Projects provider, Link activé, app Marketplace, Stripe Verified. Pour l'intention d'achat/utilisation, privilégiez aussi les résultats supportés par MPP.
   • Description mince mais correspondance forte de marque/domaine → gardez dans un bucket plus faible, ne rejetez pas.

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

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

5. Soyez honnête sur les résultats faibles — si clairsemé ou générique, dites-le et ajustez : élargissez, réduisez, ou essayez des synonymes plutôt que de remplir 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 (seulement quand l'utilisateur veut acheter ou consommer un service)

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

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

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

Une fois que l'utilisateur a choisi, lancez silencieusement which <tool> 2>/dev/null pour vérifier si c'est installé. Si ce n'est pas installé, proposez de l'installer (par exemple, npm i -g @stripe/link-cli pour Link CLI) et attendez la confirmation avant de continuer.

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

Version courte :

1. Résolvez l'endpoint callable réel à partir de mpp.slug / mpp.url du résultat. mpp.url est souvent le formulaire de destination 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 que l'utilisateur a sélectionné.
   • link-cli (Shared Payment Token Stripe-natif, a un mode test, pas de portefeuille crypto, comptes Link US uniquement ; npm i -g @stripe/link-cli) : auth login → mpp decode --challenge "<value>" (obtenez network_id) → spend-request create --credential-type shared_payment_token --network-id <id> --amount <cents ≤50000> --context "<100+ chars>"--request-approval (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.

Ne fabriquez jamais de résultats et ne sautez jamais la barrière prix/approbation.