القائمة
Guide for upgrading Stripe API versions and SDKs
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Deploy any local project to the user's Lucity platform. Triggers when the user says "deploy", "ship this", "put this online", "deploy to lucity", "get this running in the cloud", or points at a local codebase and asks to host it. Works for any application shape Railpack can build (Node, Python, Go, PHP, Java, Ruby, Rust, Elixir, Deno, Bun, .NET, static sites, and more) plus prebuilt images. Provisions PostgreSQL, Redis, and S3-compatible buckets, wires credentials, imports data, and self-heals failed rollouts.
Deploy the Lucity platform to production: upgrade the `lucity` control-plane chart and/or the `lucity-infra` chart on the lucity-prod cluster to a version published on ghcr.io. Use this whenever the user asks to deploy, release, ship, roll out, or upgrade production, "bump prod to <version>", "deploy the platform chart", "deploy the infra chart", "release to lucity-prod", or "upgrade the cluster", even if they don't say "skill". It lists published chart versions, reads what is currently installed, diffs the two with git, flags any breaking changes or manual migrations (new values, annotations, new secrets), and then applies with `make deploy-prod` / `make deploy-prod-infra`. This is for the platform's OWN charts, not for deploying user applications (that is the separate `lucity:deploy` skill).
Write Lucity GitHub release notes / changelog in the house style. Use this whenever the user asks to draft release notes, write a changelog, prepare a release announcement, summarize what has shipped since the last release or tag, or "write the notes for vX.Y.Z", even if they don't say "skill". Turns merged PRs and commits since the previous release into an intro placeholder (the maintainer writes the opening in their own voice) followed by grouped, user-facing, use-case-oriented bullets, with the social-preview image header, then writes the result straight into a draft GitHub release for the next CalVer tag. Internal-only changes are omitted unless they change day-to-day platform usage.
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), and migrating from deprecated Stripe APIs. Use when building, modifying, or reviewing any Stripe integration — including accepting payments, building marketplaces, integrating Stripe, processing payments, setting up subscriptions, or creating connected accounts.
| name | upgrade-stripe |
| description | Guide for upgrading Stripe API versions and SDKs |
The latest Stripe API version is 2026-02-25.clover - use this version when upgrading unless the user specifies a different target version.
This guide covers upgrading Stripe API versions, server-side SDKs, Stripe.js, and mobile SDKs.
Stripe uses date-based API versions (e.g., 2026-02-25.clover, 2025-08-27.basil, 2024-12-18.acacia). Your account’s API version determines request/response behavior.
Backward-Compatible Changes (don’t require code updates):
Breaking Changes (require code updates):
Review the API Changelog for all changes between versions.
See SDK Version Management for details.
These SDKs offer flexible version control:
Global Configuration:
import stripe
stripe.api_version = '2026-02-25.clover'
Stripe.api_version = '2026-02-25.clover'
const stripe = require('stripe')('sk_test_xxx', {
apiVersion: '2026-02-25.clover'
});
Per-Request Override:
stripe.Customer.create(
email="customer@example.com",
stripe_version='2026-02-25.clover'
)
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.
Always specify the API version you’re integrating against in your code instead of relying on your account’s default API version:
// Good: Explicit version
const stripe = require('stripe')('sk_test_xxx', {
apiVersion: '2026-02-25.clover'
});
// Avoid: Relying on account default
const stripe = require('stripe')('sk_test_xxx');
See Stripe.js Versioning for details.
Stripe.js uses an evergreen model with major releases (Acacia, Basil, Clover) on a biannual basis.
Via Script Tag:
<script src="https://js.stripe.com/clover/stripe.js"></script>
Via npm:
npm install @stripe/stripe-js
Major npm versions correspond to specific Stripe.js versions.
Each Stripe.js version automatically pairs with its corresponding API version. For instance:
2026-02-25.clover API2024-12-18.acacia APIYou can’t override this association.
See Mobile SDK Versioning for details.
Both platforms follow semantic versioning (MAJOR.MINOR.PATCH):
New features and fixes release only on the latest major version. Upgrade regularly to access improvements.
Uses a different model (0.x.y schema):
All mobile SDKs work with any Stripe API version you use on your backend unless documentation specifies otherwise.
npm update stripe, pip install --upgrade stripe)apiVersion parameter in your Stripe client initializationStripe-Version headerUse the Stripe-Version header to test your code against a new version without changing your default:
curl https://api.stripe.com/v1/customers \
-u sk_test_xxx: \
-H "Stripe-Version: 2026-02-25.clover"
Or in code:
const stripe = require('stripe')('sk_test_xxx', {
apiVersion: '2026-02-25.clover' // Test with new version
});