stripe-directory

Stripe Directory Search

Convertissez un besoin marché vague en une courte shortlist pertinente avec stripe directory search. Utilisez cela même quand l'utilisateur ne dit jamais « Stripe Directory » — toute demande pour trouver des vendors, outils, partenaires ou prestataires pour un vertical, workflow, pain point, ou job-to-be-done.

La plupart des demandes sont des discovery — trouver et comparer des services. C'est le cœur du job ci-dessous. Certains services sont aussi MPP-supported (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 d'acheter — voir « Purchasing » à la fin.

Process

1. Clarifiez seulement ce qui manque : buyer/vertical, job-to-be-done, capability indispensable, géographie (seulement si ça compte).

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

   • Courtes phrases nominales, un angle par query ; lancez 1-3, puis élargissez/restreignez sur les résultats.
   • Angles à couvrir : vertical → workflow → pain point → adjacent. Deux exemples :
     • services/trades : vertical (electrician software, electrical contractor) → workflow (field service management, dispatch invoicing estimates) → pain point (job scheduling, quote automation) → adjacent (home services automation, contractor crm).
     • SaaS/software : vertical (b2b saas billing, developer tools) → workflow (subscription management, usage-based metering) → pain point (failed payment recovery, revenue recognition) → adjacent (analytics dashboards, customer onboarding).
   • Contraintes fermes → 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ée ? Augmentez --limit et essayez la prochaine --page avant de conclure que c'est vide.

3. Dédoublonnez & cotez en utilisant display_name, description, url, username comme preuve.

   • Préférez les résultats dont la description/site correspond clairement au workflow cible.
   • Préférez plus de trust signals sur moins : Projects provider, Link enabled, Marketplace app, Stripe Verified. Pour intent buy/use, préférez aussi les résultats MPP-supported.
   • Description mince mais match brand/domain fort → gardez dans un bucket plus faible, ne rejetez pas.

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

   • direct / adjacent / needs manual review
   • Chaque entrée : nom · pourquoi ça correspond · URL (· quelle query l'a fait remonter, si utile).
   • Résultats MPP-supported : notez qu'ils sont achetables et incluez mpp.slug / mpp.url.

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

Reportez 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 MPP-supported sont payables directement. Ne poussez pas à l'achat sans invitation. Quand l'utilisateur veut acheter, présentez le menu complet des méthodes de paiement et demandez laquelle il préfère avant de faire quoi que ce soit :

« Quelle méthode de paiement préférez-vous ?

• 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 continuer.

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

Version courte :

1. Résolvez le vrai endpoint callable depuis mpp.slug / mpp.url du résultat. mpp.url est souvent la forme 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 payer que l'utilisateur a sélectionné.
   • link-cli (Stripe-native Shared Payment Token, a un mode test, pas de crypto wallet, US Link accounts seulement ; 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 ni ne contournez la gate prix/approbation.