本文解释为何 stripe 旧版 checkout（modal 弹窗）无法触发测试卡的预期拒付行为，并指出根本原因在于未正确使用 `stripeToken`，而是错误地对已有客户默认卡重复扣款；同时提供迁移至现代支付流程的明确路径。
你遇到的问题并非 Stripe 测试卡“失效”，而是集成逻辑存在关键缺陷：当前代码并未真正使用用户在 Checkout 弹窗中输入的测试卡信息，而是绕过了它，直接对一个已存在的客户（$_POST[‘customer_id’]）的默认支付方式发起扣款——该默认卡极大概率是你此前成功添加的一张有效测试卡（如 4242 4242 4242 4242），因此所有交易自然全部成功。
? 根本问题定位
在你的前端代码中，Stripe Checkout js 会生成一个一次性 token（代表用户输入的卡信息），并通过表单 POST 提交至后端，字段名为 stripeToken。但你的 php 后端代码却完全忽略了它：
// ❌ 错误：仅使用 customer_id，未使用 stripeToken 'customer' => $_POST['customer_id'],这导致 StripeCharge::create() 实际执行的是：
“对 ID 为 cus_xxx 的客户，用其已绑定且设为默认的那张卡，扣 $10.00”。
而你输入的 4000000000000002 等测试卡从未被提交、未被创建、更未被附加到该客户——它被 Checkout 完全丢弃了。
✅ 正确做法（临时修复，仅限过渡）
若暂无法迁移，必须确保：
- 前端表单包含隐藏域接收 stripeToken；
- 后端使用该 token 创建新 Customer 或直接创建 Charge。
后端应改为：
try { // ✅ 正确：使用前端传来的 token 创建 Charge（不依赖 customer） $charge = StripeCharge::create([ 'amount' => 1000, 'currency' => 'usd', 'source' => $_POST['stripeToken'], // ← 关键！不是 customer 'description' => "Single Credit Purchase", 'receipt_email' => $loggedInUser->email, ]); } catch (StripeExceptionCardException $e) { // ✅ 此时 4000000000000002 将触发 CardException，$e->getError()->code === 'card_declined' $errors[] = $e->getMessage(); } catch (StripeExceptionRateLimitException $e) { $errors[] = 'Too many requests. Please try again later.'; } catch (StripeExceptionInvalidRequestException $e) { $errors[] = 'Invalid parameters: ' . $e->getMessage(); } catch (StripeExceptionAuthenticationException $e) { $errors[] = 'Authentication failed. Check your API keys.'; } catch (StripeExceptionApiConnectionException $e) { $errors[] = 'Network error. Please try again.'; } catch (StripeExceptionApiErrorException $e) { $errors[] = 'Stripe API error: ' . $e->getMessage(); } catch (Exception $e) { $errors[] = 'Unexpected error: ' . $e->getMessage(); }? 重要警告：旧版 Checkout 已彻底弃用
Stripe 官方已于 2020 年 12 月正式弃用 checkout.js（v2），并停止对其维护与安全更新。它：
- ❌ 不支持 SCA/3D Secure 2（欧盟强认证合规必需）；
- ❌ 无 PCI DSS Level 1 合规保障（因卡号曾短暂经过你的服务器）；
- ❌ 无法处理现代支付方式（如 apple Pay、google Pay、Klarna）；
- ❌ Webhook 事件结构陈旧，缺乏 payment_intent 等关键对象。
✅ 推荐方案：立即迁移到 Stripe Payment Intents + Elements
采用现代标准流程，既保证测试卡 100% 可控，又满足全球合规要求：
- 前端使用 Stripe Elements 收集卡信息（PCI 合规，卡号不触达你的服务器）；
- 调用 stripe.confirmCardPayment() 发起带 SCA 的支付；
- 后端通过 PaymentIntent ID 处理异步结果。
// 前端示例（简化） const { paymentIntent, error } = await stripe.confirmCardPayment( '{{ CLIENT_SECRET }}', // 来自后端 /create-payment-intent { payment_method: { card: cardElement, billing_details: { email: userEmail } } } ); if (error) { console.log('Decline reason:', error.code); // e.g., 'card_declined' }后端创建 PaymentIntent（PHP）：
$intent = StripePaymentIntent::create([ 'amount' => 1000, 'currency' => 'usd', 'automatic_payment_methods' => ['enabled' => true], ]); echo json_encode(['client_secret' => $intent->client_secret]);? 所有测试卡（4000000000000002, 4000000000009995 等）在 Payment Intents 模式下将严格按文档返回对应错误码，且支持完整 SCA 流程模拟。
总结
- 不要归咎于测试卡：它们始终可靠，问题出在集成方式；
- 立即停用 checkout.js：它已过时、不安全、不合规；
- 优先实现 Payment Intents + Elements：这是 Stripe 当前唯一推荐、长期支持、符合全球监管的方案；
- 测试时务必使用 stripeToken（旧）或 client_secret（新），而非复用已有客户 ID。
迁移虽需数小时开发，但换来的是稳定性、安全性与未来兼容性——这才是生产环境应有的技术债偿还节奏。