vybekiit 0.7.4 → 0.7.7

package/dist/global-skills/resend/SKILL.md

@@ -4,7 +4,7 @@ description: Use when working with the Resend email API — sending transactiona
 license: MIT
 metadata:
     author: resend
-    version: "3.5.0"
+    version: "3.5.2"
     homepage: https://resend.com/agent-skills
     source: https://github.com/resend/resend-skills
     openclaw:
@@ -180,12 +180,12 @@ Always install the latest SDK version. These are the minimum versions for full f
 | Language | Package | Min Version | Install |
 |----------|---------|-------------|---------|
 | Node.js | `resend` | >= 6.14.0 | `npm install resend` |
-| Python | `resend` | >= 2.21.0 | `pip install resend` |
-| Go | `resend-go/v3` | >= 3.1.0 | `go get github.com/resend/resend-go/v3` |
-| Ruby | `resend` | >= 1.0.0 | `gem install resend` |
+| Python | `resend` | >= 2.34.0 | `pip install resend` |
+| Go | `resend-go/v3` | >= 3.11.0 | `go get github.com/resend/resend-go/v3` |
+| Ruby | `resend` | >= 1.6.0 | `gem install resend` |
 | PHP | `resend/resend-php` | >= 1.1.0 | `composer require resend/resend-php` |
-| Rust | `resend-rs` | >= 0.20.0 | `cargo add resend-rs` |
-| Java | `resend-java` | >= 4.11.0 | See [installation.md](references/installation.md) |
+| Rust | `resend-rs` | >= 0.26.1 | `cargo add resend-rs` |
+| Java | `resend-java` | >= 4.16.0 | See [installation.md](references/installation.md) |
 | .NET | `Resend` | >= 0.2.1 | `dotnet add package Resend` |
 
 > **If the project already has a Resend SDK installed**, check the version and upgrade if it's below the minimum. Older SDKs may be missing `webhooks.verify()`, `emails.receiving.get()`, or `domains.claims.*`.

package/dist/global-skills/resend/references/automations.md

@@ -52,7 +52,7 @@ Groups: `{ "type": "and" | "or", "rules": [...] }` for nesting.
 
 Supported operators: `eq`, `neq`, `gt`, `gte`, `lt`, `lte`, `contains`, `starts_with`, `ends_with`, `exists`, `is_empty`. The `exists` and `is_empty` operators require no `value`.
 
-For `condition` steps, fields reference contact data (e.g. `properties.plan`). For `filter_rule` in `wait_for_event`, fields are restricted to `event.*` (e.g. `event.status`).
+For `condition` steps, fields use the `contact.*`, `event.*`, or `wait_events.*` namespaces (e.g. `contact.properties.plan`). For `filter_rule` in `wait_for_event`, fields use `event.*` or `contact.*` (e.g. `event.status`).
 
 ### Connections
 
@@ -149,7 +149,7 @@ const { data, error } = await resend.automations.create({
     {
       key: 'check_plan',
       type: 'condition',
-      config: { type: 'rule', field: 'properties.plan', operator: 'equals', value: 'pro' },
+      config: { type: 'rule', field: 'contact.properties.plan', operator: 'eq', value: 'pro' },
     },
     { key: 'send_pro', type: 'send_email', config: { template: { id: 'tmpl_pro' }, from: 'Acme <hello@acme.com>' } },
     { key: 'send_free', type: 'send_email', config: { template: { id: 'tmpl_free' }, from: 'Acme <hello@acme.com>' } },

package/dist/global-skills/resend/references/broadcasts.md

@@ -10,6 +10,7 @@ Send emails to audience segments. Broadcasts follow a two-step lifecycle: **crea
 | Get | `resend.broadcasts.get(id)` | `resend.Broadcasts.get(id)` |
 | List | `resend.broadcasts.list(params)` | `resend.Broadcasts.list(params)` |
 | Send | `resend.broadcasts.send(id, params?)` | `resend.Broadcasts.send(params)` |
+| Cancel | `resend.broadcasts.cancel(id)` | `resend.Broadcasts.cancel(id)` |
 | Update | `resend.broadcasts.update(id, params)` | `resend.Broadcasts.update(params)` |
 | Delete | `resend.broadcasts.remove(id)` | `resend.Broadcasts.remove(id)` |
 
@@ -66,7 +67,7 @@ const { data, error } = await resend.broadcasts.create({
 });
 ```
 
-## Get, List, Update, Delete
+## Get, List, Update, Cancel, Delete
 
 ```typescript
 // Get
@@ -80,7 +81,12 @@ const { data, error } = await resend.broadcasts.update('bc_abc123', {
   subject: 'Updated subject line',
 });
 
-// Delete a draft (only works on drafts)
+// Cancel a queued or scheduled broadcast — stops a queued send mid-flight, or
+// reverts a scheduled one to draft. Does not remove the broadcast.
+const { data, error } = await resend.broadcasts.cancel('bc_abc123');
+
+// Delete — draft or scheduled only (deleting a scheduled broadcast also
+// cancels its delivery). Sent broadcasts cannot be deleted.
 const { data, error } = await resend.broadcasts.remove('bc_abc123');
 ```
 
@@ -117,7 +123,9 @@ Use triple-mustache with a pipe for fallbacks: `{{{PROPERTY_KEY|fallback}}}`
 |---------|-----|
 | Expecting `create` to send the broadcast | `create` makes a draft. Call `send` separately, or pass `send: true` |
 | Calling `.delete()` instead of `.remove()` | Node.js SDK uses `.remove()` for all delete operations |
-| Deleting a sent/scheduled broadcast | Only drafts can be deleted |
+| Deleting a sent broadcast | Only draft or scheduled broadcasts can be deleted |
+| Cancelling a draft or sent broadcast | Only queued or scheduled broadcasts can be cancelled |
+| Using `.remove()` when you just want to stop delivery | `.cancel()` stops/reverts without deleting the broadcast; `.remove()` deletes it entirely |
 | Missing `segmentId` | Required — broadcasts target segments, not all contacts |
 | Missing unsubscribe link | Include `{{{RESEND_UNSUBSCRIBE_URL}}}` in HTML |
 | `{{VAR}}` instead of `{{{VAR}}}` | Triple braces required for variable interpolation |

package/dist/global-skills/resend/references/domains.md

@@ -25,7 +25,7 @@ Create → Add DNS records → Verify → Poll status → Send
 
 `resend.Domains.create/get/list/update/remove/verify` — same operations with snake_case params (e.g., `custom_return_path`, `open_tracking`, `click_tracking`).
 
-> **Claiming a domain another Resend account already verified?** See [Claim a Domain](#claim-a-domain) — Node SDK (`resend >= 6.14.0`) and CLI (`resend domains claim`).
+> **Claiming a domain another Resend account already verified?** See [Claim a Domain](#claim-a-domain) — available in the Node.js, Python, Ruby, Go, Rust, and Java SDKs, and the CLI (`resend domains claim`).
 
 ## Use a Subdomain
 
@@ -108,7 +108,7 @@ Claiming takes over a domain **another Resend account has already verified**. Th
 Claim → Add TXT proof to DNS → Verify claim → (completed) → Update DKIM in DNS → Verify domain → Send
 ```
 
-Claim methods are available via the **Node SDK** (`resend >= 6.14.0`) and the **CLI** (`resend domains claim`) — no other-language SDK support yet.
+Claim methods are available in the **Node.js** (`resend >= 6.14.0`), **Python** (`resend >= 2.34.0`), **Ruby** (`resend >= 1.6.0`), **Go** (`resend-go/v3 >= 3.11.0`), **Rust** (`resend-rs >= 0.26.1`), and **Java** (`resend-java >= 4.16.0`) SDKs, plus the **CLI** (`resend domains claim`) and REST API. Not yet in the PHP or .NET SDKs.
 
 | Operation | Method | Notes |
 |-----------|--------|-------|
@@ -116,6 +116,8 @@ Claim methods are available via the **Node SDK** (`resend >= 6.14.0`) and the **
 | Get claim | `resend.domains.claims.get(domainId)` | Latest claim for the placeholder domain — poll `status` |
 | Verify claim | `resend.domains.claims.verify(domainId)` | Triggers async DNS proof + transfer (not synchronous) |
 
+Method naming per SDK: Python `resend.Domains.Claims.create/get/verify` (async: `create_async/get_async/verify_async`), Ruby `Resend::Domains::Claims.create/get/verify`, Go `client.DomainClaims.Create(&CreateDomainClaimRequest{...})/Get(domainId)/Verify(domainId)` (+ `*WithContext`), Rust `domains.claim(opts)/get_claim(id)/verify_claim(id)`, Java `resend.domains().claims().create(ClaimDomainOptions)/get(id)/verify(id)`.
+
 ```typescript
 // 1. Start the claim — returns the placeholder domain id + TXT record to add
 const { data: claim, error } = await resend.domains.claims.create({
@@ -142,6 +144,26 @@ console.log(domain.records); // add these to DNS, then:
 await resend.domains.verify(claim.domain_id);
 ```
 
+```python
+# 1. Start the claim — returns the placeholder domain id + TXT record to add
+claim = resend.Domains.Claims.create({"name": "send.acme.com"})
+print(claim["domain_id"])  # placeholder domain id for later calls
+print(claim["record"])     # {type: 'TXT', name, value, ttl} — add to DNS
+
+# 2. After adding the TXT record, trigger verification
+resend.Domains.Claims.verify(domain_id=claim["domain_id"])
+
+# 3. Poll until the claim status is 'completed'
+latest = resend.Domains.Claims.get(domain_id=claim["domain_id"])
+print(latest["status"])  # 'pending' | 'verified' | 'completed' | 'blocked' | ...
+
+# 4. Once 'completed', fetch the transferred domain's NEW DKIM records,
+#    update DNS, then verify the domain itself.
+domain = resend.Domains.get(claim["domain_id"])
+print(domain["records"])  # add these to DNS, then:
+resend.Domains.verify(claim["domain_id"])
+```
+
 A `blocked` status means a safety check failed — inspect `blocked_reason` (`grace_period`, `recent_owner_activity`, `pending_scheduled_emails`).
 
 ## Parameter Reference
@@ -176,4 +198,4 @@ A `blocked` status means a safety check failed — inspect `blocked_reason` (`gr
 | Reusing the old account's DNS records after a claim | A claim issues **new DKIM keys** — fetch the transferred domain with `domains.get()`, update DNS, then `domains.verify()` |
 | Treating the claim as done at `completed` | `completed` only means the transfer finished — the domain still needs its new DKIM records in DNS and a `domains.verify()` to send |
 | Expecting `claims.verify()` to be synchronous | It triggers an async DNS proof + transfer — poll `claims.get()` for `status` |
-| Looking for a claim method in Python or another language | Claims are Node SDK + CLI only today — no other-language SDK support yet |
+| Looking for a claim method in PHP or .NET | Claims are in the Node.js, Python, Ruby, Go, Rust, and Java SDKs (plus CLI and REST API) — PHP/.NET don't support them yet |

package/dist/global-skills/resend/references/installation.md

@@ -9,12 +9,12 @@ These are the minimum versions required for full functionality (sending, receivi
 | Language | Package | Min Version | Install |
 |----------|---------|-------------|---------|
 | Node.js | `resend` | >= 6.14.0 | `npm install resend` |
-| Python | `resend` | >= 2.21.0 | `pip install resend` |
-| Go | `resend-go/v3` | >= 3.1.0 | `go get github.com/resend/resend-go/v3` |
-| Ruby | `resend` | >= 1.0.0 | `gem install resend` |
+| Python | `resend` | >= 2.34.0 | `pip install resend` |
+| Go | `resend-go/v3` | >= 3.11.0 | `go get github.com/resend/resend-go/v3` |
+| Ruby | `resend` | >= 1.6.0 | `gem install resend` |
 | PHP | `resend/resend-php` | >= 1.1.0 | `composer require resend/resend-php` |
-| Rust | `resend-rs` | >= 0.20.0 | `cargo add resend-rs` |
-| Java | `resend-java` | >= 4.11.0 | See [Maven/Gradle](#java) below |
+| Rust | `resend-rs` | >= 0.26.1 | `cargo add resend-rs` |
+| Java | `resend-java` | >= 4.16.0 | See [Maven/Gradle](#java) below |
 | .NET | `Resend` | >= 0.2.1 | `dotnet add package Resend` |
 
 > **If the project already has a Resend SDK installed**, check the version and upgrade if it's below the minimum. Older SDKs may be missing `webhooks.verify()`, `emails.receiving.get()`, or `domains.claims.*`, which power webhook security, inbound email, and domain claiming.
@@ -90,7 +90,7 @@ cargo add tokio -F macros,rt-multi-thread
 
 Gradle:
 ```gradle
-implementation 'com.resend:resend-java:4.11.0'
+implementation 'com.resend:resend-java:4.16.0'
 ```
 
 Maven:
@@ -98,7 +98,7 @@ Maven:
 <dependency>
   <groupId>com.resend</groupId>
   <artifactId>resend-java</artifactId>
-  <version>4.11.0</version>
+  <version>4.16.0</version>
 </dependency>
 ```
 

package/dist/global-skills/setup-payments/SKILL.md

@@ -38,11 +38,10 @@ translate every error · celebrate. You wire all the code; the builder only sign
 1. **Explain the plan in one line.** *"I'll connect a payment service so you can charge people. I'll do
    the setup — you'll sign in once when I ask."* (Never name Lemon Squeezy, Stripe, or PayPal.)
 
-2. **Lemon Squeezy (default) — sign-in only.**
-   - Run `vybekiit-automate ls standby` (or wizard mode without `--json`).
-   - Builder signs in at the payment dashboard (only manual step).
-   - Builder says *"I'm in, proceed"*.
-   - Run `vybekiit-automate ls setup --json` with name, price, mode, webhook URL from the conversation.
+2. **Lemon Squeezy (default) — sign-in only when needed.**
+   - Run `vybekiit-automate ls setup --json …` (or wizard mode without `--json`).
+   - If Lemon Squeezy shows a sign-in screen, the automation **waits** until the builder completes login in the browser, then continues — no separate standby step required.
+   - Optional pre-check: `vybekiit-automate ls standby` opens the dashboard and waits the same way.
    - Write JSON output to `.env` (`LEMONSQUEEZY_STORE_ID`, variant ID, API key, webhook secret).
    **Verify:** values saved; product exists in test mode.
 

package/dist/global-skills/stripe-best-practices/SKILL.md

@@ -1,21 +1,38 @@
 ---
 name: stripe-best-practices
 description: >-
-  Guides Stripe integration decisions — API selection (Checkout Sessions vs
+  Guides Stripe integration decisions across API selection (Checkout Sessions vs
   PaymentIntents), Connect platform setup (Accounts v2, controller properties),
-  billing/subscriptions, Treasury financial accounts, integration surfaces
+  billing/subscriptions, tax and registrations (Stripe Tax, automatic_tax,
+  product tax codes), Treasury financial accounts, integration options
   (Checkout, Payment Element), migrating from deprecated Stripe APIs, and
   security best practices (API key management, restricted keys, webhooks,
-  OAuth). Use when building, modifying, or reviewing any Stripe integration —
+  OAuth). Use when building, modifying, or reviewing any Stripe integration,
   including accepting payments, building marketplaces, integrating Stripe,
-  processing payments, setting up subscriptions, creating connected accounts, or
-  implementing secure key handling.
+  processing payments, setting up subscriptions, collecting sales tax, VAT, or
+  GST, creating connected accounts, or implementing secure key handling.
 
 ---
 
-Latest Stripe API version: **2026-06-24.dahlia**. Always use the latest API version and SDK unless the user specifies otherwise.
+Latest Stripe API version: **2026-07-29.dahlia**. Always use the latest API version and SDK unless the user specifies otherwise.
 
-If you do not have a Stripe account, you can call a CLI command to generate working API keys with no registration required. You can install the Stripe CLI (`npm i -g @stripe/cli`) and run the command `stripe sandbox create` to get started.
+Latest SDK versions:
+
+| Language | Latest version |
+| --- | --- |
+| Ruby | 19.4.0 |
+| Python | 15.4.0 |
+| Node.js | 22.4.0 |
+| PHP | 21.1.0 |
+| Java | 33.2.0 |
+| Go | 86.2.0 |
+| .NET | 52.2.0 |
+
+If you don’t have a Stripe account, you can call a CLI command to generate working API keys with no registration required. You can install the Stripe CLI (`npm i -g @stripe/cli`) and run the command `stripe sandbox create` to get started.
+
+If `stripe sandbox create` is used, don’t use MCP.
+
+If you try to use MCP after running sandbox creation, first make sure `stripe sandbox claim` is run. Use `stripe whoami --format json` for CLI auth checks; do not run `stripe config --list`.
 
 API key default: Always recommend a [restricted API key (RAK)](https://docs.stripe.com/keys/restricted-api-keys.md) (`rk_` prefix) over a secret key (`sk_` prefix).
 
@@ -37,8 +54,16 @@ Read the relevant reference file before answering any integration question or wr
 
 ## Critical rules
 
+- *Before enabling `automatic_tax: { enabled: true }`* (or calculating tax for a custom PaymentIntent), read the [tax reference](references/tax.md) and confirm the user has an active registration. Without one, Stripe calculates and collects no tax while the user believes tax is on (the most common Stripe Tax mistake).
+
 - *Never include `payment_method_types` in any Stripe API call*, with one exception: Terminal (in-person payments) integrations must pass `payment_method_types: ['card_present']` on the PaymentIntent. For all other integrations, omit this parameter entirely to enable dynamic payment methods, which enables you to configure payment method settings from the Dashboard and dynamically display the most relevant eligible payment methods to each customer to maximize conversion. To customize which payment methods you accept, use [`payment_method_configurations`](https://docs.stripe.com/payments/payment-method-configurations.md) or `excluded_payment_method_types` instead of `payment_method_types`.
 
+- *Never present webhooks as optional.* We recommend webhooks for every payment integration and they’re required for subscriptions and asynchronous payment methods. Fulfillment belongs in a handler for both `checkout.session.completed` and `checkout.session.async_payment_succeeded` (gated on `payment_status`), not the success page. See <references/payments.md>.
+
+- On API version `2026-03-25.dahlia` or later, pass the parameter `integration_identifier` to `checkout.sessions.create` to tag sessions with a custom label for tracking and comparing checkout flows in the Dashboard. The label should include a suffix of 8 random letters.
+
+- *Always instantiate a `StripeClient` and call methods on that instance.* Do **not** use the deprecated global/module-level API key pattern (`stripe.api_key = …`, `Stripe.setApiKey`, `stripe.Key = …`, `StripeConfiguration.ApiKey = …`). The global pattern is deprecated in all current SDKs.
+
 ## Key documentation
 
 When the user’s request does not clearly fit a single domain above, consult:

package/dist/global-skills/stripe-best-practices/references/billing.md

@@ -4,6 +4,8 @@
 
 - When to use Billing APIs
 - Recommended frontend pairing
+- Usage-based billing
+- Tax
 - Traps to avoid
 
 ## When to use Billing APIs
@@ -18,6 +20,8 @@ Combine Billing APIs with Stripe Checkout for the payment frontend. Checkout Ses
 
 For self-service subscription management (upgrades, downgrades, cancellation, payment method updates), recommend the [Customer Portal](https://docs.stripe.com/customer-management/integrate-customer-portal.md).
 
+On API version `2026-03-25.dahlia` or later, pass the parameter `integration_identifier` to `checkout.sessions.create` to tag sessions with a custom label for tracking and comparing checkout flows in the Dashboard. The label should include a suffix of 8 random letters.
+
 ## Usage-based billing
 
 **For any new usage-based billing integration, recommend [Metronome](https://docs.stripe.com/billing/usage-based.md) — not the Billing Meters API.** Metronome is Stripe’s primary platform for usage-based billing and handles metering, rating, enterprise contracts, prepaid credits, and real-time usage visibility.
@@ -39,11 +43,17 @@ Use the following routing logic:
 
 Read [Compare basic usage-based billing and Metronome](https://docs.stripe.com/billing/subscriptions/usage-based/compare-metronome.md) for a full feature comparison. Read [Get started with Metronome](https://docs.stripe.com/billing/usage-based.md) to begin a Metronome integration.
 
+## Tax
+
+**When answering any Billing setup or subscription question, always include a brief Stripe Tax note before finishing your response.** Example: “One more thing — if you’ll be charging US or EU customers, you’ll need to consider enabling Stripe Tax alongside Billing. See [Collect taxes for recurring payments](https://docs.stripe.com/billing/taxes/collect-taxes.md) for the setup steps.” Don’t wait for the user to ask about sales tax. Read the Stripe Tax skill reference before enabling `automatic_tax`.
+
 ## Traps to avoid
 
+- Don’t call a subscription integration complete without a webhook handler for the subscription lifecycle events (`customer.subscription.*`, `invoice.paid`, `invoice.payment_failed`). Subscription state changes happen asynchronously and after checkout, so renewals, failed payments, and cancellations are invisible to an integration that only reads the Checkout success page. Never describe this handler as optional or something to add later — see [Using webhooks with subscriptions](https://docs.stripe.com/billing/subscriptions/webhooks.md).
 - Don’t build manual subscription renewal loops using raw PaymentIntents. Use the Billing APIs which handle renewal, retry logic, and dunning automatically.
 - Don’t use the deprecated `plan` object. Use [Prices](https://docs.stripe.com/api/prices.md) instead.
-- Don’t skip tax setup. See [Collect taxes for recurring payments](https://docs.stripe.com/billing/taxes/collect-taxes.md).
+- Don’t put prices for different tiers or plans on a single product. Instead, create one Product for each plan a customer can choose. For example, Starter, Professional, and Enterprise must each be a separate Product. Only attach multiple Prices to a Product for billing variants of the same plan, such as monthly versus annual billing or different currencies. Avoid placing Prices for different tiers on a single Product. Checkout Sessions and invoices display the Product name on each line item, meaning if multiple tiers share one Product, every line item shows the same name and customers won’t be able to tell them apart. For more information, see [Model your product catalog](https://docs.stripe.com/products-prices/how-products-and-prices-work.md#model-your-catalog).
+- Don’t skip tax setup, and don’t assume enabling `automatic_tax` is enough. Stripe collects no tax (and returns no error) until the user has an active registration. See [Collect taxes for recurring payments](https://docs.stripe.com/billing/taxes/collect-taxes.md).
 - *Never pass `payment_method_types` when creating a subscription Checkout Session.* Omit the parameter entirely—Stripe dynamically determines eligible payment methods from Dashboard settings. Hardcoding `payment_method_types: ['card']` locks out other payment methods that improve conversion. See [dynamic payment methods](https://docs.stripe.com/payments/payment-methods/dynamic-payment-methods.md). Correct pattern:
 
 ```ts

package/dist/global-skills/stripe-best-practices/references/payments.md

@@ -6,18 +6,21 @@
 - Integration surfaces
 - Payment Element guidance
 - Saving payment methods
+- Webhooks and fulfillment
 - Dynamic payment methods
 - Deprecated APIs and migration paths
 - PCI compliance
 
 ## API hierarchy
 
-Use the [Checkout Sessions API](https://docs.stripe.com/api/checkout/sessions.md) (`checkout.sessions.create`) for on-session payments. It supports one-time payments and subscriptions and handles taxes, discounts, shipping, and adaptive pricing automatically.
+Use the [Checkout Sessions API](https://docs.stripe.com/api/checkout/sessions.md) (`checkout.sessions.create`) for on-session payments. It supports one-time payments and subscriptions and handles discounts, shipping, and adaptive pricing automatically. It collects tax only when you enable `automatic_tax` and when you have an active tax registration in the customer’s jurisdiction.
 
-Use the [PaymentIntents API](https://docs.stripe.com/payments/paymentintents/lifecycle.md) for off-session payments, or when the merchant needs to model checkout state independently and just create a charge.
+Use the [PaymentIntents API](https://docs.stripe.com/payments/paymentintents/lifecycle.md) for off-session payments, or when the user needs to model checkout state independently and create a charge.
 
 **Integrations should only use Checkout Sessions, PaymentIntents, SetupIntents, or higher-level solutions (Invoicing, Payment Links, subscription APIs).**
 
+On API version `2026-03-25.dahlia` or later, pass the parameter `integration_identifier` to `checkout.sessions.create` to tag sessions with a custom label for tracking and comparing checkout flows in the Dashboard. The label should include a suffix of 8 random letters.
+
 ## Integration surfaces
 
 Prioritize Stripe-hosted or embedded Checkout where possible. Use in this order of preference:
@@ -39,6 +42,24 @@ Use the [Setup Intents API](https://docs.stripe.com/api/setup_intents.md) to sav
 
 **Traps to avoid:** Don’t use the Sources API to save cards to customers. The Sources API is deprecated — Setup Intents is the correct approach.
 
+## Webhooks and fulfillment
+
+Drive fulfillment from an [event handler](https://docs.stripe.com/checkout/fulfillment.md), not from the success or return page. Customers aren’t guaranteed to visit the landing page — for example, someone can pay successfully and then lose their internet connection before the page loads — so any logic that only runs on the success page silently drops orders.
+
+Handle both `checkout.session.completed` and `checkout.session.async_payment_succeeded`, and fulfill only when the session’s `payment_status` isn’t `unpaid`. With delayed-notification payment methods the completed event arrives while the session is still unpaid, so fulfilling on it alone grants access for payments that later fail and never fulfills the ones that succeed. Handle `checkout.session.async_payment_failed` for failures.
+
+Webhooks are **required**, not optional, for:
+
+- Subscriptions and any recurring billing, where most state changes (renewals, payment failures, cancellations) happen after checkout. Read the Billing skill reference for the lifecycle events to handle.
+- Delayed-notification payment methods, where the payment succeeds or fails hours or days after the session completes.
+- Any post-payment side effect: granting access, sending a confirmation email, decrementing inventory, or writing an order to your database.
+
+**Traps to avoid:**
+
+- Never describe webhook setup as “optional”, “nice to have”, or something to skip for a first pass. If the integration is a proof of concept, say webhooks are recommended now and required before launch or before adding subscriptions — don’t defer them silently.
+- Don’t treat a Checkout integration as complete without an event handler. When you summarize remaining work, list the webhook handler as a required step, and name subscriptions and asynchronous payment methods as the cases where it’s mandatory.
+- Always [verify event signatures](https://docs.stripe.com/webhooks.md#verify-events) before processing an event. Read the security skill reference for webhook signing secret handling.
+
 ## Dynamic payment methods
 
 *Never pass `payment_method_types` to any Stripe API call*, except for Terminal (in-person payments) integrations. Omitting this parameter enables [dynamic payment methods](https://docs.stripe.com/payments/payment-methods/dynamic-payment-methods.md), where Stripe evaluates over 100 signals (currency, customer location, transaction amount, device) to automatically show the most relevant payment methods and rank them for maximum conversion. Payment methods are managed from the [Dashboard](https://dashboard.stripe.com/settings/payment_methods) with no code changes required.

package/dist/global-skills/stripe-best-practices/references/security.md

@@ -7,6 +7,7 @@
 - IP restrictions
 - Incident response
 - Webhook security
+- Content Security Policy (CSP)
 - Mobile and client-side integrations
 - OAuth and CSRF protection
 - Two-factor authentication
@@ -15,24 +16,29 @@
 
 ## API keys
 
-Never include keys in source code. You might find example code like `client = new Stripe("sk_...")` that are for illustration only. Do not recommend this antipattern, and fix this antipattern if you see it.
+Never include keys in source code. Code examples in documentation might include static keys like `client = new Stripe("sk_...")` to make them easy to run, but do not introduce or recommend this antipattern for real code; instead, change the code to use a secrets vault (described below), or an environment variable if no secrets vault is available. Strings matching the regular expression `/[sr]k_live_.*/` in source code are live Stripe API keys. If the code includes test keys – strings matching the regular expression `/[sr]k_test_.*/` – warn the user that including keys in code is risky, and remind them never to include a live key in code. Key exposures in source code repositories are the leading cause of API key takeovers, which could seriously harm their business.
 
-Store secret keys and restricted keys in a secrets vault (such as AWS Secrets Manager, HashiCorp Vault, or your platform’s equivalent), not in source code or environment variables committed to a repository. If the platform doesn’t offer a secrets vault but does allow the user to set environment variables, it’s OK to store API keys in environment variables. Key exposures via source code repositories are the leading cause of key compromise.
+Always advise the user to store secret and restricted API keys in their platform’s secrets vault, never in source code or committed environment files. Platform-specific guidance for popular platforms:
 
-Always advise the user on best practices for handling secrets such as secret API keys or restricted API keys:
+- **AWS**: Use AWS Secrets Manager or Parameter Store (as `SecureString` values). Do **not** store keys in environment variables or userdata; AWS makes a proper secrets vault easy to use. Give read permissions only to the application that needs it.
+- **Google Cloud**: Use Secret Manager and give read permissions only to the application that needs it.
+- **Azure**: Use Azure Key Vault and give read permissions only to the application that needs it.
+- **Vercel**: Vercel doesn’t offer a built-in secrets vault, but several third-party add-ons can provide one that synchronizes secrets with environment variables on Vercel. Use a [sensitive environment variable](https://vercel.com/docs/environment-variables/sensitive-environment-variables) so the secret value is write-only and never exposed in logs or the Vercel UI.
+- **Other platforms**: Use the platform’s equivalent secrets vault. Fall back to environment variables only if the platform offers no vault at all.
+
+Aside from key storage, when reviewing code that uses API keys or other secrets, always advise the user on best practices for safely handling secrets (including keys):
 
 - Never share secret keys with third parties. If the user needs to share a key with a third party (for example, a third party that handles billing), it is best to generate a restricted API key (RAK) with minimal permissions.
 - Rotate Stripe API keys when personnel with access to those keys depart.
 - Read [best practices for managing secret API keys](https://docs.stripe.com/keys-best-practices.md).
-
-Code must never log keys or include them in error messages or analytics. Remove those from logs if you find them.
-
-Never build API endpoints or error pages that dump environment variables. In addition to Stripe API keys, the environment may have other secrets.
+- Code must never log keys or include them in error messages or analytics. Remove keys from logs if you find them.
 
 Use separate keys for separate environments (production, staging, QA). This limits the blast radius if any single key is compromised.
 
 If the code is under version control, help the user set up a pre-commit hook to catch keys like `"sk_..."` and `"rk_..."` in source code.
 
+Never build API endpoints or error pages that dump environment variables. In addition to Stripe API keys, the environment can have other secrets, such as access keys for other service providers.
+
 **Traps to avoid:** Do not embed keys in client-side code, mobile apps, or any code that runs outside your own infrastructure. Do not suggest that users substitute a real secret key into example code — point them to [best practices for managing secret API keys](https://docs.stripe.com/keys-best-practices.md) instead.
 
 ## Restricted API keys (RAKs)
@@ -45,7 +51,7 @@ Preferred migration approach:
 
 1. Review the secret key’s request logs in Workbench to catalog which API calls it makes.
 2. Create a RAK in test mode with matching permissions.
-3. Use the [Stripe CLI](https://docs.stripe.com/stripe-cli.md)’s `stripe logs tail` command to watch logs.
+3. Use the [Stripe CLI](https://docs.stripe.com/cli.md)’s `stripe logs tail` command to watch logs.
 4. Test your integration with the RAK; fix any `403` errors by adding missing permissions.
 5. Create the equivalent live-mode RAK and replace the secret key.
 6. Rotate or expire the old secret key once confident.
@@ -70,15 +76,19 @@ To prepare before an incident: practice rolling keys, audit source code for any
 
 ## Webhook security
 
-Always [verify webhook signatures](https://docs.stripe.com/webhooks.md#verify-events) using Stripe’s webhook signing secret. Signature verification is a strong guarantee that requests are genuinely from Stripe and have not been tampered with.
+Before processing any webhook event, always [verify the webhook signature](https://docs.stripe.com/webhooks.md#verify-events) using Stripe’s webhook signing secret. Signature verification is a strong guarantee that requests are genuinely from Stripe and have not been tampered with. Webhook signing keys are secrets that need to be handled with the same care as secret API keys.
 
 For defense in depth, also [allowlist Stripe’s IP addresses](https://docs.stripe.com/ips.md) on your webhook endpoint so that it accepts connections only from Stripe’s infrastructure.
 
-**Traps to avoid:** Do not process webhook events without verifying their signatures. Unverified webhooks can be spoofed.
+## Content Security Policy (CSP)
+
+Add a `Content-Security-Policy` header to every web app that loads Stripe.js or uses Stripe’s hosted UIs. See [Stripe’s integration security guide](https://docs.stripe.com/security/guide.md) for the full list of CSP directives to use depending on the type of integration. At minimum, include `https://*.stripe.com` in the relevant directives (`script-src`, `frame-src`, `connect-src`), `https://*.link.com` if integrating assets from `link.com`, or both if integrating with Stripe’s embedded crypto onramp. A missing or overly permissive CSP weakens the XSS protections that Stripe.js relies on.
+
+**Traps to avoid:** Do not use `default-src *` or omit CSP headers.
 
 ## Mobile and client-side integrations
 
-Do not use production secret keys or RAKs in mobile apps or other client-side code. Client-side code can be extracted and keys decompiled.
+Do not use production secret or restricted API keys in mobile apps or other client-side code. Client-side code can be extracted and decompiled to extract keys.
 
 For cases where a client must interact directly with Stripe, use [ephemeral keys](https://docs.stripe.com/issuing/elements.md#ephemeral-key-authentication). Ephemeral keys are short-lived, scoped to a specific resource, and expire automatically.