17370845950

本文解释为何 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'],

这导致 \Stripe\Charge::create() 实际执行的是：

“对 ID 为 cus_xxx 的客户，用其已绑定且设为默认的那张卡，扣 $10.00”。

而你输入的 4000000000000002 等测试卡从未被提交、未被创建、更未被附加到该客户——它被 Checkout 完全丢弃了。

✅ 正确做法（临时修复，仅限过渡）

若暂无法迁移，必须确保：

1. 前端表单包含隐藏域接收 stripeToken；
2. 后端使用该 token 创建新 Customer 或直接创建 Charge。

后端应改为：

try {
    // ✅ 正确：使用前端传来的 token 创建 Charge（不依赖 customer）
    $charge = \Stripe\Charge::create([
        'amount' => 1000,
        'currency' => 'usd',
        'source' => $_POST['stripeToken'], // ← 关键！不是 customer
        'description' => "Single Credit Purchase",
        'receipt_email' => $loggedInUser->email,
    ]);
} catch (\Stripe\Exception\CardException $e) {
    // ✅ 此时 4000000000000002 将触发 CardException，$e->getError()->code === 'card_declined'
    $errors[] = $e->getMessage();
} catch (\Stripe\Exception\RateLimitException $e) {
    $errors[] = 'Too many requests. Please try again later.';
} catch (\Stripe\Exception\InvalidRequestException $e) {
    $errors[] = 'Invalid parameters: ' . $e->getMessage();
} catch (\Stripe\Exception\AuthenticationException $e) {
    $errors[] = 'Authentication failed. Check your API keys.';
} catch (\Stripe\Exception\ApiConnectionException $e) {
    $errors[] = 'Network error. Please try again.';
} catch (\Stripe\Exception\ApiErrorException $e) {
    $errors[] = 'Stripe API error: ' . $e->getMessage();
} catch (Exception $e) {
    $errors[] = 'Unexpected error: ' . $e->getMessage();
}

? 重要警告：旧版 Checkout 已彻底弃用

Stripe 官方已于 2025 年 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% 可控，又满足全球合规要求：

1. 前端使用 Stripe Elements 收集卡信息（PCI 合规，卡号不触达你的服务器）；
2. 调用 stripe.confirmCardPayment() 发起带 SCA 的支付；
3. 后端通过 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 = \Stripe\PaymentIntent::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。

迁移虽需数小时开发，但换来的是稳定性、安全性与未来兼容性——这才是生产环境应有的技术债偿还节奏。