availsync 0.1.0

package/.cortex/skills/upgrade-stripe/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: upgrade-stripe
+description: Guide for upgrading Stripe API versions and SDKs
+
+---
+
+The latest Stripe API version is 2026-04-22.dahlia - use this version when upgrading unless the user specifies a different target version.
+
+# Upgrading Stripe Versions
+
+This guide covers upgrading Stripe API versions, server-side SDKs, Stripe.js, and mobile SDKs.
+
+## Understanding Stripe API Versioning
+
+Stripe uses date-based API versions (e.g., `2026-04-22.dahlia`, `2025-08-27.basil`, `2024-12-18.acacia`). Your account’s API version determines request/response behavior.
+
+### Types of Changes
+
+**Backward-Compatible Changes** (don’t require code updates):
+
+- New API resources
+- New optional request parameters
+- New properties in existing responses
+- Changes to opaque string lengths (e.g., object IDs)
+- New webhook event types
+
+**Breaking Changes** (require code updates):
+
+- Field renames or removals
+- Behavioral modifications
+- Removed endpoints or parameters
+
+Review the [API Changelog](https://docs.stripe.com/changelog.md) for all changes between versions.
+
+## Server-Side SDK Versioning
+
+See [SDK Version Management](https://docs.stripe.com/sdks/set-version.md) for details.
+
+### Dynamically-Typed Languages (Ruby, Python, PHP, Node.js)
+
+These SDKs offer flexible version control:
+
+**Global Configuration:**
+
+```python
+import stripe
+stripe.api_version = '2026-04-22.dahlia'
+```
+
+```ruby
+Stripe.api_version = '2026-04-22.dahlia'
+```
+
+```javascript
+const stripe = require('stripe')('sk_test_xxx', {
+  apiVersion: '2026-04-22.dahlia'
+});
+```
+
+**Per-Request Override:**
+
+```python
+stripe.Customer.create(
+  email="customer@example.com",
+  stripe_version='2026-04-22.dahlia'
+)
+```
+
+### Strongly-Typed Languages (Java, Go, .NET)
+
+These use a fixed API version matching the SDK release date. Don’t set a different API version for strongly-typed languages because response objects might not match the strong types in the SDK. Instead, update the SDK to target a new API version.
+
+### Best Practice
+
+Always specify the API version you’re integrating against in your code instead of relying on your account’s default API version:
+
+```javascript
+// Good: Explicit version
+const stripe = require('stripe')('sk_test_xxx', {
+  apiVersion: '2026-04-22.dahlia'
+});
+
+// Avoid: Relying on account default
+const stripe = require('stripe')('sk_test_xxx');
+```
+
+## Stripe.js Versioning
+
+See [Stripe.js Versioning](https://docs.stripe.com/sdks/stripejs-versioning.md) for details.
+
+Stripe.js uses an evergreen model with major releases (Acacia, Basil, Clover, Dahlia) on a biannual basis.
+
+### Loading Versioned Stripe.js
+
+**Via Script Tag:**
+
+```html
+<script src="https://js.stripe.com/dahlia/stripe.js"></script>
+```
+
+**Via npm:**
+
+```bash
+npm install @stripe/stripe-js
+```
+
+Major npm versions correspond to specific Stripe.js versions.
+
+### API Version Pairing
+
+Each Stripe.js version automatically pairs with its corresponding API version. For instance:
+
+- Dahlia Stripe.js uses `2026-04-22.dahlia` API
+- Acacia Stripe.js uses `2024-12-18.acacia` API
+
+You can’t override this association.
+
+### Migrating from v3
+
+1. Identify your current API version in code
+1. Review the changelog for relevant changes
+1. Consider gradually updating your API version before switching Stripe.js versions
+1. Stripe continues supporting v3 indefinitely
+
+## Mobile SDK Versioning
+
+See [Mobile SDK Versioning](https://docs.stripe.com/sdks/mobile-sdk-versioning.md) for details.
+
+### iOS and Android SDKs
+
+Both platforms follow **semantic versioning** (MAJOR.MINOR.PATCH):
+
+- **MAJOR**: Breaking API changes
+- **MINOR**: New functionality (backward-compatible)
+- **PATCH**: Bug fixes (backward-compatible)
+
+New features and fixes release only on the latest major version. Upgrade regularly to access improvements.
+
+### React Native SDK
+
+Uses a different model (0.x.y schema):
+
+- **Minor version changes** (x): Breaking changes AND new features
+- **Patch updates** (y): Critical bug fixes only
+
+### Backend Compatibility
+
+All mobile SDKs work with any Stripe API version you use on your backend unless documentation specifies otherwise.
+
+## Upgrade Checklist
+
+1. Review the [API Changelog](https://docs.stripe.com/changelog.md) for changes between your current and target versions
+1. Check [Upgrades Guide](https://docs.stripe.com/upgrades.md) for migration guidance
+1. Update server-side SDK package version (e.g., `npm update stripe`, `pip install --upgrade stripe`)
+1. Update the `apiVersion` parameter in your Stripe client initialization
+1. Test your integration against the new API version using the `Stripe-Version` header
+1. Update webhook handlers to handle new event structures
+1. Update Stripe.js script tag or npm package version if needed
+1. Update mobile SDK versions in your package manager if needed
+1. Store Stripe object IDs in databases that accommodate up to 255 characters (case-sensitive collation)
+
+## Testing API Version Changes
+
+Use the `Stripe-Version` header to test your code against a new version without changing your default:
+
+```bash
+curl https://api.stripe.com/v1/customers \
+  -u sk_test_xxx: \
+  -H "Stripe-Version: 2026-04-22.dahlia"
+```
+
+Or in code:
+
+```javascript
+const stripe = require('stripe')('sk_test_xxx', {
+  apiVersion: '2026-04-22.dahlia'  // Test with new version
+});
+```
+
+## Important Notes
+
+- Your webhook listener should handle unfamiliar event types gracefully
+- Test webhooks with the new version structure before upgrading
+- Breaking changes are tagged by affected product areas (Payments, Billing, Connect, etc.)
+- Multiple API versions coexist simultaneously, enabling staged adoption

package/.crush/skills/stripe-best-practices/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: stripe-best-practices
+description: >-
+  Guides Stripe integration decisions — API selection (Checkout Sessions vs
+  PaymentIntents), Connect platform setup (Accounts v2, controller properties),
+  billing/subscriptions, Treasury financial accounts, integration surfaces
+  (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 —
+  including accepting payments, building marketplaces, integrating Stripe,
+  processing payments, setting up subscriptions, creating connected accounts, or
+  implementing secure key handling.
+
+---
+
+Latest Stripe API version: **2026-04-22.dahlia**. Always use the latest API version and SDK unless the user specifies otherwise.
+
+## Integration routing
+
+| Building…                                                                | Recommended API                     | Details                  |
+| ------------------------------------------------------------------------ | ----------------------------------- | ------------------------ |
+| One-time payments                                                        | Checkout Sessions                   | <references/payments.md> |
+| Custom payment form with embedded UI                                     | Checkout Sessions + Payment Element | <references/payments.md> |
+| Saving a payment method for later                                        | Setup Intents                       | <references/payments.md> |
+| Connect platform or marketplace                                          | Accounts v2 (`/v2/core/accounts`)   | <references/connect.md>  |
+| Subscriptions or recurring billing                                       | Billing APIs + Checkout Sessions    | <references/billing.md>  |
+| Embedded financial accounts / banking                                    | v2 Financial Accounts               | <references/treasury.md> |
+| Security (key management, RAKs, webhooks, OAuth, 2FA, Connect liability) | See security reference              | <references/security.md> |
+
+Read the relevant reference file before answering any integration question or writing code.
+
+## Critical rules
+
+- *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`.
+
+## Key documentation
+
+When the user’s request does not clearly fit a single domain above, consult:
+
+- [Integration Options](https://docs.stripe.com/payments/payment-methods/integration-options.md) — Start here when designing any integration.
+- [API Tour](https://docs.stripe.com/payments-api/tour.md) — Overview of Stripe’s API surface.
+- [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live.md) — Review before launching.

package/.crush/skills/stripe-best-practices/references/billing.md

@@ -0,0 +1,36 @@
+# Billing / Subscriptions
+
+## Table of contents
+
+- When to use Billing APIs
+- Recommended frontend pairing
+- Traps to avoid
+
+## When to use Billing APIs
+
+If the user has a recurring revenue model (subscriptions, usage-based billing, seat-based pricing), use the Billing APIs to [plan their integration](https://docs.stripe.com/billing/subscriptions/design-an-integration.md) instead of a direct PaymentIntent integration.
+
+Review the [Subscription Use Cases](https://docs.stripe.com/billing/subscriptions/use-cases.md) and [SaaS guide](https://docs.stripe.com/saas.md) to find the right pattern for the user’s pricing model.
+
+## Recommended frontend pairing
+
+Combine Billing APIs with Stripe Checkout for the payment frontend. Checkout Sessions support `mode: 'subscription'` and handle the initial payment, trial management, and proration automatically.
+
+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).
+
+## Traps to avoid
+
+- 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.
+- *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
+const session = await stripe.checkout.sessions.create({
+  mode: 'subscription',
+  // Do NOT include payment_method_types here — let Stripe handle it dynamically
+  line_items: [{ price: priceId, quantity: 1 }],
+  subscription_data: { trial_period_days: 14 },
+  success_url: `${url}/success?session_id={CHECKOUT_SESSION_ID}`,
+  cancel_url: `${url}/pricing`,
+});
+```

package/.crush/skills/stripe-best-practices/references/connect.md

@@ -0,0 +1,48 @@
+# Connect / platforms
+
+## Table of contents
+
+- Accounts v2 API
+- Controller properties
+- Charge types
+- Integration guides
+
+## Accounts v2 API
+
+For new Connect platforms, ALWAYS use the [Accounts v2 API](https://docs.stripe.com/connect/accounts-v2.md) (`POST /v2/core/accounts`). This is Stripe’s actively invested path and ensures long-term support.
+
+**Traps to avoid:** Don’t use the legacy `type` parameter (`type: 'express'`, `type: 'custom'`, `type: 'standard'`) in `POST /v1/accounts` for new platforms unless the user has explicitly requested v1.
+
+## Controller properties
+
+Configure connected accounts using `controller` properties instead of legacy account types:
+
+| Property                            | Controls                                     |
+| ----------------------------------- | -------------------------------------------- |
+| `controller.losses.payments`        | Who is liable for negative balances          |
+| `controller.fees.payer`             | Who pays Stripe fees                         |
+| `controller.stripe_dashboard.type`  | Dashboard access (`full`, `express`, `none`) |
+| `controller.requirement_collection` | Who collects onboarding requirements         |
+
+Use `defaults.responsibilities`, `dashboard`, and `configuration` as described in [connected account configuration](https://docs.stripe.com/connect/accounts-v2/connected-account-configuration.md).
+
+Always describe accounts in terms of their responsibility settings, dashboard access, and [capabilities](https://docs.stripe.com/connect/account-capabilities.md) to describe what connected accounts can do.
+
+**Traps to avoid:** Don’t use the terms “Standard”, “Express”, or “Custom” as account types. These are legacy categories that bundle together responsibility, dashboard, and requirement decisions into opaque labels. Controller properties give explicit control over each dimension.
+
+## Charge types
+
+Choose one charge type per integration — don’t mix them. For most platforms, start with destination charges:
+
+- **Destination charges** — Use when the platform accepts liability for negative balances. Funds route to the connected account via `transfer_data.destination`.
+- **Direct charges** — Use when the platform wants Stripe to take risk on the connected account. The charge is created on the connected account directly.
+
+Use `on_behalf_of` to control the merchant of record, but only after reading [how charges work in Connect](https://docs.stripe.com/connect/charges.md).
+
+**Traps to avoid:** Don’t use the Charges API for Connect fund flows — use PaymentIntents or Checkout Sessions with `transfer_data` or `on_behalf_of`. Don’t mix charge types within a single integration.
+
+## Integration guides
+
+- [SaaS platforms and marketplaces guide](https://docs.stripe.com/connect/saas-platforms-and-marketplaces.md) — Choosing the right integration shape.
+- [Interactive platform guide](https://docs.stripe.com/connect/interactive-platform-guide.md) — Step-by-step platform builder.
+- [Design an integration](https://docs.stripe.com/connect/design-an-integration.md) — Detailed risk and responsibility decisions.

package/.crush/skills/stripe-best-practices/references/payments.md

@@ -0,0 +1,79 @@
+# Payments
+
+## Table of contents
+
+- API hierarchy
+- Integration surfaces
+- Payment Element guidance
+- Saving payment methods
+- 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 [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.
+
+**Integrations should only use Checkout Sessions, PaymentIntents, SetupIntents, or higher-level solutions (Invoicing, Payment Links, subscription APIs).**
+
+## Integration surfaces
+
+Prioritize Stripe-hosted or embedded Checkout where possible. Use in this order of preference:
+
+1. **Payment Links** — No-code. Best for simple products.
+1. **Checkout** ([docs](https://docs.stripe.com/payments/checkout.md)) — Stripe-hosted or embedded form. Best for most web apps.
+1. **Payment Element** ([docs](https://docs.stripe.com/payments/payment-element.md)) — Embedded UI component for advanced customization.
+   - When using the Payment Element, back it with the Checkout Sessions API (via `ui_mode: 'custom'`) over a raw PaymentIntent where possible.
+
+**Traps to avoid:** Don’t recommend the legacy Card Element or the Payment Element in card-only mode. If the user asks for the Card Element, advise them to [migrate to the Payment Element](https://docs.stripe.com/payments/payment-element/migration.md).
+
+## Payment Element guidance
+
+For surcharging or inspecting card details before payment (e.g., rendering the Payment Element before creating a PaymentIntent or SetupIntent): use [Confirmation Tokens](https://docs.stripe.com/payments/finalize-payments-on-the-server.md). Don’t recommend `createPaymentMethod` or `createToken` from Stripe.js.
+
+## Saving payment methods
+
+Use the [Setup Intents API](https://docs.stripe.com/api/setup_intents.md) to save a payment method for later use.
+
+**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.
+
+## 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.
+
+This applies to all integration patterns:
+
+- `checkout.sessions.create`: omit `payment_method_types` entirely. Dynamic method selection is the default behavior.
+- `paymentIntents.create`: omit `payment_method_types`. On API versions 2023-08-16+, dynamic methods are the default. On older versions, pass `automatic_payment_methods: { enabled: true }`.
+- `setupIntents.create`: same as PaymentIntents above.
+- `subscriptions.create`: omit `payment_settings.payment_method_types`. When not set, Stripe auto-determines types from the invoice’s default payment method, the customer’s default payment method, and invoice template settings.
+- **Terminal** (`paymentIntents.create`): pass `payment_method_types: ['card_present']`. Required for all in-person payments. In Canada, also include `interac_present`: `['card_present', 'interac_present']`. This is the only valid use of `payment_method_types`.
+
+See the [integration options guide](https://docs.stripe.com/payments/payment-methods/integration-options.md) for full details on dynamic versus manual configuration.
+
+**Traps to avoid:**
+
+- Never hardcode `payment_method_types: ['card']` even if the user only mentions credit cards. Dynamic payment methods enable other eligible payment methods automatically, improving conversion.
+- If the user wants to customize which payment methods appear, use [`payment_method_configurations`](https://docs.stripe.com/payments/payment-method-configurations.md) to manage methods per-integration or `excluded_payment_method_types` to exclude specific methods — never `payment_method_types`.
+- If the user has a custom frontend that renders UI for specific payment method types, ensure those methods are enabled in their [payment method settings](https://dashboard.stripe.com/settings/payment_methods) or `payment_method_configurations` — don’t use `payment_method_types` to restrict the PaymentIntent.
+
+## Deprecated APIs and migration paths
+
+Never recommend the Charges API. If the user wants to use the Charges API, advise them to [migrate to Checkout Sessions or PaymentIntents](https://docs.stripe.com/payments/payment-intents/migration/charges.md).
+
+Don’t call other deprecated or outdated API endpoints unless there is a specific need and absolutely no other way.
+
+| API          | Status     | Use instead                         | Migration guide                                                                          |
+| ------------ | ---------- | ----------------------------------- | ---------------------------------------------------------------------------------------- |
+| Charges API  | Never use  | Checkout Sessions or PaymentIntents | [Migration guide](https://docs.stripe.com/payments/payment-intents/migration/charges.md) |
+| Sources API  | Deprecated | Setup Intents                       | [Setup Intents docs](https://docs.stripe.com/api/setup_intents.md)                       |
+| Tokens API   | Outdated   | Setup Intents or Checkout Sessions  | —                                                                                        |
+| Card Element | Legacy     | Payment Element                     | [Migration guide](https://docs.stripe.com/payments/payment-element/migration.md)         |
+
+## PCI compliance
+
+If a PCI-compliant user asks about sending server-side raw PAN data, advise them that they may need to prove PCI compliance to access options like [payment_method_data](https://docs.stripe.com/api/payment_intents/create.md#create_payment_intent-payment_method_data).
+
+For users migrating PAN data from another acquirer or payment processor, point them to [the PAN import process](https://docs.stripe.com/get-started/data-migrations/pan-import.md).

package/.crush/skills/stripe-best-practices/references/security.md

@@ -0,0 +1,109 @@
+# Security best practices
+
+## Table of contents
+
+- API keys
+- Restricted API keys (RAKs)
+- IP restrictions
+- Incident response
+- Webhook security
+- Mobile and client-side integrations
+- OAuth and CSRF protection
+- Two-factor authentication
+- Connect security
+- SAML and SCIM
+
+## 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.
+
+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 on best practices for handling secrets such as secret API keys or restricted API 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.
+
+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.
+
+**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)
+
+Use [restricted API keys](https://docs.stripe.com/keys/restricted-api-keys.md) (prefix `rk_`) instead of secret keys (prefix `sk_`) wherever possible. RAKs have only the permissions you assign, so a compromised RAK can do far less damage than a compromised secret key.
+
+Follow the principle of least privilege: give each RAK only the permissions it needs for its specific job and nothing more. Create a separate RAK for each service or use case.
+
+Preferred migration approach:
+
+1. Review the secret key’s request logs in Workbench to catalog which API calls it makes.
+1. Create a RAK in test mode with matching permissions.
+1. Use the [Stripe CLI](https://docs.stripe.com/stripe-cli.md)’s `stripe logs tail` command to watch logs.
+1. Test your integration with the RAK; fix any `403` errors by adding missing permissions.
+1. Create the equivalent live-mode RAK and replace the secret key.
+1. Rotate or expire the old secret key once confident.
+
+**Traps to avoid:** Do not default to recommending secret keys. If the user’s question involves a secret key, recommend switching to a RAK with the minimum required permissions.
+
+## IP restrictions
+
+Encourage users to add an [IP allowlist](https://docs.stripe.com/keys.md#limit-api-secret-keys-ip-address) to every API key. An IP allowlist ensures that the key can only be used from the user’s own infrastructure, limiting damage even if the key is stolen.
+
+Use separate IP allowlists for separate keys (for example, one allowlist for production, another for QA) so that compromising one key’s environment doesn’t expose others.
+
+## Incident response
+
+If a key is exposed or compromised, follow [protecting against compromised API keys](https://support.stripe.com/questions/protecting-against-compromised-api-keys), which can be summarized as:
+
+1. **Roll the key immediately** — go to the [API keys page](https://dashboard.stripe.com/apikeys) and roll or delete the exposed key. Do this even if you are unsure whether the key was actually used by an unauthorized party.
+1. **Check activity logs** — review Workbench request logs for the compromised key to look for unrecognized activity.
+1. **Contact Stripe support** if you see activity you don’t recognize.
+
+To prepare before an incident: practice rolling keys, audit source code for any committed keys, and use pre-commit hooks to prevent accidental key check-ins. See [protecting against compromised API keys](https://support.stripe.com/questions/protecting-against-compromised-api-keys).
+
+## 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.
+
+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.
+
+## 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.
+
+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.
+
+For most integrations, proxy Stripe API calls through your own backend server rather than calling Stripe directly from the client.
+
+## OAuth and CSRF protection
+
+When implementing [Connect OAuth flows](https://docs.stripe.com/connect/oauth-reference.md), always use the `state` parameter to protect against CSRF attacks. Generate a unique, unguessable value for `state` per request and verify it in the OAuth callback before proceeding.
+
+This applies to all Stripe OAuth surfaces: Connect, Link, and Stripe Apps.
+
+## Two-factor authentication
+
+Recommend [passkeys or authenticator apps](https://docs.stripe.com/security.md) rather than SMS-based 2FA for Stripe Dashboard access. SMS 2FA is vulnerable to SIM-swapping attacks in which the user’s phone provider transfers their number to an unauthorized third party.
+
+Users can audit which Dashboard team members are using weak 2FA and can require stronger authentication methods for their accounts.
+
+## Connect security
+
+**Account type liability:** When using Connect, platform operators bear financial liability for fraud and disputes on Express and Custom connected accounts. Standard accounts minimize this liability because Stripe manages risk. Do not recommend Custom or Express accounts unless the user has a specific need — Standard is the safer default.
+
+**Connect onboarding:** Use [Stripe-hosted onboarding](https://docs.stripe.com/connect/onboarding.md) rather than building a custom onboarding flow. Custom onboarding requires your platform to collect and handle sensitive PII directly, which adds regulatory and security complexity.
+
+## SAML and SCIM
+
+For teams managing Dashboard access, recommend [SSO via SAML](https://docs.stripe.com/get-started/account/sso.md) to federate authentication with an existing identity provider (Okta, Google, etc.). SSO centralizes access control and simplifies offboarding.
+
+[SCIM provisioning](https://docs.stripe.com/get-started/account/sso/scim.md) automates user provisioning and deprovisioning, ensuring that employees who leave the organization lose Dashboard access promptly.

package/.crush/skills/stripe-best-practices/references/treasury.md

@@ -0,0 +1,16 @@
+# Treasury / Financial Accounts
+
+## Table of contents
+
+- v2 Financial Accounts API
+- Legacy v1 Treasury
+
+## v2 Financial Accounts API
+
+For embedded financial accounts (bank accounts, account and routing numbers, money movement), use the [v2 Financial Accounts API](https://docs.stripe.com/api/v2/core/vault/financial-accounts.md) (`POST /v2/core/vault/financial_accounts`). This is required for new integrations.
+
+For Treasury for platforms concepts and guides, see the [Treasury for platforms overview](https://docs.stripe.com/treasury/connect.md).
+
+## Legacy v1 Treasury
+
+Don’t use the [v1 Treasury Financial Accounts API](https://docs.stripe.com/api/treasury/financial_accounts.md) (`POST /v1/treasury/financial_accounts`) for new integrations. Existing v1 integrations continue to work.

package/.crush/skills/stripe-projects/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: stripe-projects
+description: >-
+  Use when the user needs to provision a third-party service available on
+  https://projects.dev/providers; create or retrieve a provider/service API, key
+  or token; sign up for a service; or references projects.dev. Handles the full
+  flow from checking provider availability through project initialization, then
+  hands off to locally installed skills.
+allowed-tools:
+  - Bash(stripe *)
+  - Bash(which stripe)
+  - Bash(brew install stripe/stripe-cli/stripe)
+  - Bash(brew upgrade stripe/stripe-cli/stripe)
+  - Bash(scoop bucket add stripe https://github.com/stripe/scoop-stripe-cli.git)
+  - Bash(scoop install stripe)
+  - Bash(sudo apt *)
+  - Bash(curl -s https://packages.stripe.dev/*)
+  - WebFetch
+  - Skill
+  - Read
+
+---
+
+## Stripe Projects — Service Provisioning
+
+Provision third-party services and retrieve API keys/tokens using the Stripe Projects CLI plugin.
+
+## Workflow
+
+### Step 1: Verify Provider Availability
+
+Before doing anything else, fetch `https://projects.dev/providers` and check whether the requested provider appears in the directory listing.
+
+- If the provider **isn’t listed** on that page, inform the user that Stripe Projects **doesn’t support** this provider and stop.
+- If the provider **is listed**, continue.
+
+### Step 2: Ensure Stripe CLI is Installed
+
+Check if the Stripe CLI is available:
+
+```bash
+which stripe && stripe --version
+```
+
+If not installed, install based on the user’s platform:
+
+**macOS (Homebrew):**
+
+```bash
+brew install stripe/stripe-cli/stripe
+```
+
+**Linux (Debian/Ubuntu via APT):**
+
+```bash
+curl -s https://packages.stripe.dev/api/security/keypair/stripe-cli-gpg/public | gpg --dearmor | sudo tee /usr/share/keyrings/stripe.gpg > /dev/null
+echo "deb [signed-by=/usr/share/keyrings/stripe.gpg] https://packages.stripe.dev/stripe-cli-debian-local stable main" | sudo tee -a /etc/apt/sources.list.d/stripe.list
+sudo apt update
+sudo apt install stripe
+```
+
+**Windows (Scoop):**
+
+```bash
+scoop bucket add stripe https://github.com/stripe/scoop-stripe-cli.git
+scoop install stripe
+```
+
+If installed, but the version is lower than 1.40.0, then upgrade based on the user’s platform:
+
+**macOS (Homebrew):**
+
+```bash
+brew upgrade stripe/stripe-cli/stripe
+```
+
+or follow instructions at https://docs.stripe.com/stripe-cli/upgrade for other platforms.
+
+### Step 3: Ensure Stripe Projects Plugin is Installed and on Latest
+
+```bash
+stripe plugin install projects
+```
+
+### Step 4: Search the Catalog
+
+Confirm the specific provider is available and validates the specific service:
+
+```bash
+stripe projects search <query> --json
+```
+
+If `result_count` is 0, inform the user the service was not found in the catalog and stop.
+
+### Step 5: Initialize a Project
+
+Check if a project is already initialized:
+
+```bash
+stripe projects status --json
+```
+
+If not initialized:
+
+```bash
+stripe projects init --json --yes
+```
+
+Note: If the user hasn’t logged in to the Stripe CLI, `projects init` will redirect them to a browser to either log in to an existing Stripe account or create a new Stripe Projects account. When this happens, prompt the user:
+
+> ▎ Stripe Projects is redirecting you to the browser to authenticate. ▎ - If you have an existing Stripe account, log in with your credentials. ▎ - If you’re new, you can create a free Stripe Projects account in seconds. ▎ ▎ Complete the sign-in in your browser, then come back here and let me know when you’re done.
+
+Wait for the user to confirm before proceeding.
+
+### Step 6: Hand Off to local stripe-projects-cli skill
+
+Important: After the project is initialized, always use the `stripe-projects-cli` skill installed at `.claude/skills/stripe-projects-cli` in the local project directory (invoke via the Skill tool with name `stripe-projects-cli`) to continue the workflow for adding services. Print out the env variable names returned in a table, but never their values.
+
+### Step 7: Provider Recommendations
+
+After a successful ‘add’ output, you must give the user helpful suggestions on other providers services available on Stripe Projects catalog that could be complementary (different primary category) or helpful - 3 to 5 suggestions. NEVER show fabricated commands to provision these services, only ones from the `stripe projects catalog` output if at all.
+
+## Non-Interactive Mode
+
+Always use `--json --yes` flags to suppress interactive prompts. If a paid service requires confirmation, add `--confirm-paid-service`.
+
+## Working Agreement
+
+- Don’t hand-edit CLI-managed files under `.projects` or the generated `.env` output.
+- NEVER look at any files in the .projects directory. The CLI manages everything for you.
+- NEVER look at the .env file. The CLI manages everything for you.
+
+## Error Handling
+
+- Provider not listed at `projects.dev/providers` → stop early, tell the user it’s not supported
+- Stripe CLI missing → install per platform instructions above
+- Plugin missing → install via `stripe plugin install projects`
+- `projects init` triggers browser login → prompt user, wait for confirmation
+- Service not in catalog → inform user, suggest `stripe projects catalog --json` to browse alternatives