First-time is not a card-level promise
A developer reported that a Stripe promotion code restricted to first-time orders kept discounting purchases made with the same card through guest checkout. The question asks whether the restriction was failing; it is evidence of an integration concern, not proof of a Stripe defect.[4] The important distinction is between a Dashboard guest grouping and an identified customer whose transaction history can be evaluated.
Stripe’s hosted Checkout documentation explicitly says that promotion codes limited to first-time customers are still accepted for Sessions that do not create a customer.[1] Therefore, do not advertise restrictions. as “one discount per card” or “one discount per human.” This guide reviews documentation retrieved on 2026-09-22; it does not report an executed payment test.
Read the identity boundary before changing the coupon
The Checkout guide considers a transaction first-time when no customer or customer_account is defined, or when the defined customer has no prior payments or non-void invoices.[1] Guest customers, meanwhile, are a read-only grouping for completed transactions. Stripe groups guest activity using card, email, or phone information, and explains that card payments sharing a card can appear under the same guest identity.[2] That reporting convenience is not documentation of a reusable customer-level redemption lock.
Checkout supports passing customer or customer_account to associate a payment or subscription with a specific customer. When neither is passed, customer_creation controls whether Checkout creates a customer when the Session is confirmed.[2] Recommended design: retain the relationship between your authenticated user and the intended Stripe customer, then reuse that identity. Creating another customer for each visit would not implement your own account’s purchase history.
Do not reduce history to successful charges
The subscriptions discount guide uses a broader warning: first-time restrictions exclude customers who initiated a PaymentIntent even if payment never completed, or subscribed to a trial even if it was subsequently cancelled.[3] The Checkout guide instead describes prior payments and non-void invoices.[1] Preserve those different formulations rather than inventing one universal rule about every failed attempt across all integrations.
For subscriptions, “has never paid us” is therefore insufficient as an eligibility explanation.[3] Recommended handling: inspect the customer’s relevant payment and subscription history, record which integration path applies, and test ambiguous states using that path and your API version. If a customer disputes a rejection after a trial, explain the documented restriction rather than promising that cancelling the trial restores eligibility.
Choose the commercial rule explicitly
- For an open guest campaign, accept that first-time restricted codes remain accepted in the documented customerless Checkout flow.[1] Decide whether that matches the offer before publishing it.
- For a registered-customer campaign, reuse a stable customer mapping and add your own account-level eligibility policy. This is an implementation recommendation, not a claim that identity mapping prevents every abuse pattern.
- For a named recipient, Stripe allows a promotion code to be restricted to a particular customer.[1] Treat that restriction separately from a campaign-wide redemption budget.
Stripe’s max_redemptions limits total uses; the underlying coupon’s limit also constrains a promotion code’s maximum.[1] Setting a shared code’s limit to one is not a way to give every customer one use. Minimum amounts and expiration dates are additional redemption conditions, not substitutes for customer identity.[1]
Three decision examples
Illustrative case A: a repeat buyer enters the same card in two customerless Sessions. Both purchases appear in one guest group. The documented acceptance of first-time codes for these Sessions means the group alone is insufficient evidence of a restriction failure.[1][2] Review whether the application intended to supply a customer before modifying the discount.
Illustrative case B: an identified subscriber previously used a trial but paid nothing. Do not classify the subscriber as eligible merely from a zero paid total: the subscription guide explicitly includes prior trials in its exclusion.[3] Route an exception request through a separate, documented commercial decision.
Illustrative case C: a campaign wants one benefit per registered account while allowing anonymous browsing. Recommended approach: establish eligibility at sign-in, bind the purchase to the saved customer identity, and retain an application-side benefit record. Decide how concurrent attempts, cancelled orders, and support exceptions affect that record; these are your policy choices, not guarantees supplied by a guest grouping.
Checks before launching
- Record the Session’s customer identity, promotion code, relevant history, and integration path without logging raw card details.
- Exercise fresh customers, returning customers, guest repeat purchases, previous trials, and unsuccessful payment histories in a sandbox. Record observed outcomes separately from the expectations above.
- Check minimum amount, expiration, and redemption limits before attributing every rejection to first-time eligibility.[1]
- Make the offer wording match the actual identity and exception policy.
Stripe is an external reference, not a PayIn feature description. These sources establish no country-by-country availability matrix; confirm account and regional support separately. No discount, conversion, fraud-prevention, or financial outcome is guaranteed.
Sources and dates
Official documentation supports technical behavior; community questions demonstrate qualitative demand only. Retrieved and checked on 2026-09-22. Retrieval is not publication. Unstated dates remain unknown. This is documentation research, not a live-account test, PayIn feature claim, or legal, tax or financial advice. Account eligibility and regional availability require separate confirmation.
- [1] Add discounts · Publication date not stated; update date not stated · Checked 2026-09-22.
- [2] Guest customers · Publication date not stated; update date not stated · Checked 2026-09-22.
- [3] Discounts for subscriptions · Publication date not stated; update date not stated · Checked 2026-09-22.
- [4] Issue with Stripe Promotion Code First-time Order Only Restriction and Guest Customers · Published: 2024-08-09; update date not stated · Checked 2026-09-22.