“首次交易”不是按银行卡限用一次
一位开发者在社区提问：已经为 Stripe 促销码启用“仅限首次订单”，但同一张卡通过访客结账再次购买时仍获得折扣。他怀疑限制没有正确生效。这个问题证明了真实的集成困惑，并不能单凭用户描述认定 Stripe 存在缺陷。[4] 排查时应先区分两件事：管理后台归并显示的访客，以及能够关联交易历史的明确客户身份。
Stripe 的托管结账文档明确说明：对于不创建客户的结账会话，限制首次客户使用的促销码仍会被接受。[1] 因此，不能把 restrictions. 对外解释成“每张卡只能优惠一次”，也不能承诺“每个自然人只能领取一次”。本文依据 2026-09-22 检索并阅读的资料，不代表已经执行支付测试。
先检查身份边界，再修改优惠配置
结账文档写明：没有指定 customer 或 customer_account，或者指定客户没有既往付款及未作废的账单时，会被视为首次交易。[1] 与此不同，访客只是已完成交易的只读分组。Stripe 会根据银行卡、邮箱或电话归并访客活动，并说明使用同一张卡的付款可能显示在同一个访客身份下。[2] 这种报告展示能力，不等于文档承诺了一套可重复使用的客户级优惠锁定机制。
结账支持传入 customer 或 customer_account，将付款或订阅关联到明确客户；没有传入时，customer_creation 决定会话确认时是否创建客户。[2] 编辑建议：保存站内登录用户与目标 Stripe 客户之间的对应关系，后续购买复用该身份。若每次访问都重新创建客户，就没有通过这个设计表达站内账户的连续购买历史。仅查看后台访客页面，不能代替检查实际提交的客户参数。
不能只看有没有成功扣款
订阅折扣文档给出了更宽的历史限制：客户曾发起 PaymentIntent，即使付款没有完成，也会被排除；客户曾进入订阅试用，即使之后取消，也会被排除。[3] 结账文档使用的表述则是既往付款及未作废账单。[1] 应保留两处文档的措辞差异，不要自行把它们合成为一条覆盖所有失败付款状态、所有集成方式的统一算法。
对于订阅，“从未付过钱”因此不足以证明符合首次优惠资格。[3] 建议检查相关客户的付款和订阅历史，记录当前使用的集成路径，并在该路径与自己的 API 版本下验证有歧义的状态。客户在试用后质疑优惠被拒绝时，应解释文档规定的限制，而不是承诺取消试用会恢复资格。也不要为了让优惠通过，直接给老账户重新创建一份客户身份。
把商业规则拆成明确选择
- 开放访客活动：文档所述无客户结账流程仍接受首次客户促销码。[1] 发布前先判断这是否符合活动意图；若允许重复访客参与，应使宣传文字与此一致。
- 注册客户活动：建议复用稳定的客户映射，并自行制定站内账户级领取政策。这是实现建议，不代表客户映射能够阻止所有滥用，也不等于识别了唯一自然人。
- 指定领取人活动：Stripe 支持将促销码限制给特定客户。[1] 应把“谁能领取”与“活动总共允许领取多少次”分别配置和解释。
max_redemptions 限制的是总兑换次数，底层优惠券的次数上限也会约束促销码的最大次数。[1] 把共享促销码的上限设为一次，不是让每位客户各用一次。最低金额与到期时间是另外的兑换条件，不是客户身份机制的替代品。[1] 支持团队也应分别记录这些拒绝原因，避免所有失败都归类成“不是新客”。
三个决策示例
假设示例一：回头客在两个没有客户身份的会话中使用同一张卡，两笔付款显示在同一访客分组中。既然文档明确允许这些会话使用首次客户促销码，就不能仅凭分组相同认定限制失效。[1][2] 首先检查应用是否本来应该传入客户，以及映射关系是否确实进入了创建会话的请求。这个检查关注身份传递，不需要收集原始卡号。
假设示例二：已有明确身份的订阅用户曾使用试用，但累计支付金额为零。不能只看支付金额就认定其有资格，因为订阅文档明确将既往试用列为排除条件。[3] 若业务希望照顾这类用户，应通过独立、可记录的商业例外处理，而不是把例外描述成首次交易参数的默认效果。
假设示例三：活动允许匿名浏览，但要求每个注册账户只享受一次权益。建议在登录后确定资格，将购买绑定到已保存的客户身份，并在应用侧保留权益记录。还应决定并发领取、取消订单及客服补发分别如何改变记录。这些是商户需要制定的政策，不是访客分组自动提供的保证。客户身份连续性解决的是关联问题，不会替代完整的领取规则。
上线前的检查清单
- 记录会话客户身份、促销码、相关历史与集成路径；不在排查日志中记录原始银行卡信息。
- 在沙盒分别检查新客户、回头客、重复访客购买、历史试用和未成功付款的情况。将实际观察结果与本文依据文档提出的预期分开保存。
- 核查最低金额、到期时间和兑换上限，再判断拒绝是否确实来自首次资格限制。[1]
- 复核宣传文字是否准确表达身份范围、领取次数与例外处理方式。不要把账户级政策写成对所有自然人的技术保证。
Stripe 在此仅作为外部技术参考，不代表 PayIn 提供对应功能。所读资料没有建立逐国家或地区的可用性清单，账户资格及地区支持仍需单独确认。本文不保证优惠一定可用，也不保证转化率、反滥用效果或任何财务结果。
来源与日期
技术行为以官方文档为依据；社区提问只说明定性需求。于2026-09-22读取核验，检索日期不等于原文发布日期；未注明的日期仍视为未知。本文为文档研究，不是实际账户测试，不代表 PayIn 产品功能，也不是法律、税务或财务意见。账户资格与地区可用性需要另行确认。
- [1] 添加折扣 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。
- [2] 访客客户 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。
- [3] 订阅折扣 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。
- [4] 首次订单促销码限制与访客客户问题 · 发布于2024-08-09; 更新日期未注明 · 核验于2026-09-22。