/stripe

name: stripe
description: Investigate Stripe customers, subscriptions, payments, webhooks, dashboard state, and CLI or API workflows.
user-invocable: true
metadata:
  hybridclaw:
    category: business
    short_description: "Stripe customer and payment ops."
    tags:
      - stripe
      - payments
      - billing
      - webhooks
      - enterprise
    related_skills:
      - feature-planning
      - code-review

Stripe

Use this skill for Stripe Dashboard, Stripe API, Stripe CLI, and integration-debugging workflows.

Scope

• investigate customers, products, prices, payments, checkout sessions, and

subscriptions

• debug webhook delivery and local webhook forwarding
• inspect or use the Stripe API through an existing authenticated integration
• coordinate Dashboard actions through the browser when the user is already

signed in

• draft safe operational steps for Stripe-backed app changes

Default Strategy

1. Confirm whether the task is in test mode or live mode. 2. Prefer read-only inspection before any mutation. 3. Use Stripe CLI or an existing API client when a terminal or application workflow is available; otherwise use the Dashboard in the browser. 4. Confirm the exact object id or customer email before changing anything.

Stripe CLI

Basic checks:

stripe version
stripe login
stripe config --list

Useful read commands:

stripe customers list --limit 10
stripe customers retrieve cus_123
stripe products list --limit 20
stripe prices list --product prod_123
stripe subscriptions retrieve sub_123
stripe payment_intents retrieve pi_123
stripe events list --limit 10

Stripe API

Use the API when the application already has a configured Stripe client, authenticated helper, or server-side integration path.

Prefer the official Stripe SDKs over ad hoc HTTP calls when you are working in application code. Useful read-first targets include:

• `/v1/customers/{id}`
• `/v1/subscriptions/{id}`
• `/v1/payment_intents/{id}`
• `/v1/checkout/sessions/{id}`
• `/v1/events/{id}`
• `/v1/prices?product={product_id}`

For API-backed debugging:

1. confirm whether the request is against test or live mode 2. trace one concrete object id end to end 3. compare the API object state with webhook delivery and app logs 4. mutate only after the read path is understood

If the user wants integration help, state whether the source of truth is:

• Stripe API
• Stripe CLI
• Dashboard
• application logs

Webhook Debugging

For local development, forward Stripe events to the app:

stripe listen --forward-to http://127.0.0.1:3000/api/stripe/webhook

Trigger common test events:

stripe trigger payment_intent.succeeded
stripe trigger checkout.session.completed
stripe trigger customer.subscription.created

When debugging webhook issues, capture:

• event id
• object id
• endpoint path
• HTTP status code
• whether the event came from test or live mode

Dashboard Workflow

Use the Dashboard when the user is already authenticated in the browser or when the CLI does not cover the needed operation cleanly.

Prepare the exact target first:

• customer email or id
• subscription id
• payment intent id
• product or price id
• refund or cancellation scope

Never click through destructive Dashboard actions until the user has confirmed them explicitly.

Working Rules

• Default to test mode unless the user explicitly says live mode.
• Never paste secret keys, restricted keys, or webhook signing secrets into

chat.

• Never invent a new API auth path mid-task when the existing integration is

unclear.

• Do not create refunds, cancellations, or live charges without explicit

confirmation.

• State whether you are using the Stripe API, CLI, Dashboard, or application

logs.

• For integration bugs, trace one concrete object or event end to end instead of

reasoning in the abstract.

Common Use Cases

• verify whether a checkout session completed
• inspect why a subscription did not activate
• compare API object state with webhook processing in the application
• replay or trigger webhook flows locally
• locate a customer, product, or price by known identifiers
• separate application bugs from Stripe configuration issues

Pitfalls

• Do not confuse test objects with live objects.
• Do not assume webhook delivery order beyond the guarantees Stripe documents.
• Do not mutate billing state when a read-only investigation is enough.
• Do not debug payments using only app logs if Stripe event history is

available.