Stripe支付:Source与Token/Card的区别及选型建议
Hey there! Let's break down these two Stripe methods clearly so you can pick the right one for your recurring payments.
createToken() vs createSource(): Key Differences & Recommendations 1. Core Purpose & Lifecycle
createToken(): Generates a one-time use payment token. This token is a temporary wrapper for card details, designed to safely pass sensitive card data to Stripe for a single operation (like creating a Customer or processing a one-time charge). Once used, the token becomes invalid immediately.- When you call
stripe.customers.create({ source: tokenId }), Stripe converts that temporary token into a persistent card entry tied to the Customer. So while the token itself is disposable, the card saved to the Customer is reusable for future charges/subscriptions.
- When you call
createSource(): Directly creates a persistent, reusable payment source (in your case, a card source). This source is meant to be attached to a Customer and used repeatedly for charges, subscriptions, or other recurring billing needs—no temporary middleman required.
2. Stripe Dashboard Display Differences
- Token-based workflow: The "CVC/ZIP verified" label you see refers to the validation done when generating the token. Since the token itself is temporary, the dashboard doesn't mark it as reusable—but once that token is converted to a Customer card, that card entry will be reusable (you just won't see that label on the token itself).
- Source-based workflow: Sources are built for reuse from the start, so the dashboard explicitly labels them "chargeable" and "reusable" to reflect their persistent nature.
3. Reusability Clarification
To clear up your confusion: Cards saved via the token workflow are reusable—the token itself is the only disposable part. Once you've used the token to create a Customer, you can charge that Customer (and their attached card) as many times as needed for subscriptions or recurring payments.
That said, the source workflow cuts out the middle step: you get a reusable entity right away, which can be attached to a Customer or used directly for future charges.
4. Event Logs & Practicality
- Source-based events are definitely more robust for recurring billing. Since sources are persistent entities, Stripe triggers granular events like
source.chargeable,source.failed, orsource.expiringthat let you track the health and status of the payment method over time. This is super useful for monitoring subscription failures, card expirations, or other issues that affect recurring payments. - Token-based events are limited to the single operation they're used for (like
customer.createdorcharge.succeeded). Since the token has a short lifecycle, there's no ongoing event data tied to it—you'll only get events related to the Customer or charges you create with it.
5. Return Object Structure Differences
- Token object: Lean and focused on temporary data transfer. Key fields include
id(the token ID),card(basic card details + validation status), andused(a boolean marking if the token has been consumed). No fields for long-term status or reuseability. - Source object: More comprehensive, with fields that reflect its persistent nature. You'll get
id(source ID),type(e.g.,card),status(e.g.,chargeable),usage(set toreusable), plus detailed card info, owner details, and metadata. It's built to hold all the data needed for ongoing billing.
Which Should You Choose?
For recurring payments/subscriptions, go with createSource() hands down:
- It's purpose-built for reuse, so your workflow is more direct (no token-to-source conversion step).
- The richer event system makes it easier to monitor and manage ongoing billing issues (like failed subscription charges due to expired cards).
- It aligns better with Stripe's modern billing patterns for recurring use cases.
If you were only handling one-time payments, createToken() would work fine—but since you're building a recurring system, createSource() is the more practical, future-proof choice.
内容的提问来源于stack exchange,提问作者connor

