我已將這四個支付閘道的每一個都整合到生產環境的無頭商務商店中。有些令人愉快。其他的則讓我在週五凌晨 2 點質疑自己的職業選擇。這不是從行銷頁面提取的表面級功能比較 — 這是針對 2026 年的 Stripe、PayPal、Klarna 和 Square 的深入、有見地的分析，特別是從無頭商務和 Next.js 開發的角度來看。

如果您正在構建（或重建）電子商務店面，並且需要選擇支付處理商，這是我三年前希望擁有的文章。

目錄

Stripe vs PayPal vs Klarna vs Square：支付閘道比較 2026

為什麼支付閘道選擇對無頭商務很重要

在傳統的單體電子商務平台（如 Shopify 或 WooCommerce）中，您的支付閘道通常是內置的。您從下拉菜單中選擇一個，也許粘貼一個 API 密鑰，就完成了。無頭商務是不同的。

當您將前端從後端分離開來 — 運行一個 Next.js 店面與無頭 CMS 和單獨的商務 API 通信時 — 支付閘道成為一個一流的架構決策。它影響您的：

  • 結帳用戶體驗：您能構建完全自訂的結帳流程，還是要將用戶重定向到托管頁面？
  • 伺服器端邏輯：Webhooks 如何工作？在履行前如何處理付款確認？
  • PCI 合規負擔：您是在客戶端進行令牌化，還是卡號將到達您的伺服器？
  • 訂閱和經常性賬單：閘道是否原生處理此問題，還是需要集成另一個服務？
  • 國際擴展：貨幣支持、本地支付方法、監管合規。

選擇錯誤可能會讓您花費數個月的返工時間。我見過這種情況發生。一個客戶選擇了 Square，因為他們有實體零售業務，後來發現 Square 的在線 API 無法處理他們需要的訂閱模式。我們最終不得不並行運行兩個支付處理商。別成為那個團隊。

定價和交易費用比較

讓我們從每個人都想知道的開始：每一個的實際成本是多少？

這些數字截至 2026 年初是最新的。所有四個提供商都有調整費用的歷史，所以在簽署任何內容之前請驗證。

功能 Stripe PayPal Klarna Square
標準線上交易 2.9% + $0.30 3.49% + $0.49 商家支付 3.29% - 5.99%（變動） 2.9% + $0.30
現場交易 2.7% + $0.05（Terminal） N/A（使用 Zettle） N/A 2.6% + $0.10
國際卡 +1.5% +1.5% 因市場而異 +3.3% + $0.30 總計
貨幣兌換 1% 3-4% 納入商家費用 1%
月費 $0 $0 $0 $0（免費方案）
拒付費 $15 $20 Klarna 承擔（BNPL 模式） $0
支付速度 2 天（可用即時） 1-3 天 淨 15-30 天 1-2 天
大量折扣 是（自訂定價 80K+/月） 是（聯絡銷售） 可協商 是（自訂定價）

實際成本分析

原始百分比並不能說明全部情況。讓我分解一下 $100,000/月交易額在每個提供商中的實際成本（假設所有國內、線上、標準卡）：

  • Stripe：約 $3,200/月（$2,900 百分比 + 約 $300 的每筆交易費用，假設 $65 AOV）
  • PayPal：約 $4,243/月（$3,490 百分比 + 約 $753 的每筆交易費用，$65 AOV）
  • Klarna：約 $3,290 - $5,990/月（很大程度上取決於您協商的費率和產品類別）
  • Square：約 $3,200/月（對於線上交易，幾乎與 Stripe 相同）

PayPal 在標準線上交易中的成本最高，差距很大。他們以買家信任和轉換提升來為此辯護，老實說，對於某些人口統計數據，這個論點是成立的。但是在 $100K/月，您支付的費用比 Stripe 高大約 $1,000。那是每年 $12,000。

Klarna 的定價是最瘋狂的變量。他們的 BNPL（現在購買，稍後支付）模式意味著 Klarna 預先向商家支付並從客戶那裡隨時間收集。商家費用更高以支付 Klarna 的信用風險。對於時尚和生活方式品牌，具有高購物車放棄率，轉換提升可能不止抵銷費用。對於 B2B 或低利率產品？可能不會。

開發者體驗和整合複雜性

這是我的意見變得強硬的地方。我在這些 API 和 SDK 中花費了數百小時，差異並不細微。

方面 Stripe PayPal Klarna Square
API 設計品質 ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆
文檔 ★★★★★ ★★★☆☆ ★★★☆☆ ★★★★☆
Next.js SDK/支持 ★★★★★ ★★★☆☆ ★★★★☆ ★★★☆☆
Webhook 可靠性 ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆
測試/沙盒模式 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★☆
首次整合時間 2-4 小時 4-8 小時 6-12 小時 3-6 小時
自訂結帳支持 完整 有限（Advanced Checkout） 部分（基於小部件） 完整（Web Payments SDK）

Stripe vs PayPal vs Klarna vs Square：支付閘道比較 2026 - 架構

Stripe 深度分析

為什麼開發者喜歡 Stripe

Stripe 的 API 是金牌標準。就這麼簡單。每個端點都是一致的，每條錯誤消息都很有幫助，文檔看起來就像是由真正使用 API 的人寫的。儀表板簡潔，測試模式出色，Stripe CLI 可讓您將 webhooks 轉發到本地開發環境。

對於無頭 Next.js 商務，Stripe 幾乎不公平地好。以下是典型的整合模式：

// app/api/checkout/route.ts（Next.js App Router）
import Stripe from 'stripe';
import { NextResponse } from 'next/server';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(request: Request) {
  const { items, customerEmail } = await request.json();

  const session = await stripe.checkout.sessions.create({
    payment_method_types: ['card'],
    line_items: items.map((item: any) => ({
      price_data: {
        currency: 'usd',
        product_data: { name: item.name },
        unit_amount: item.price,
      },
      quantity: item.quantity,
    })),
    mode: 'payment',
    customer_email: customerEmail,
    success_url: `${process.env.NEXT_PUBLIC_URL}/order/success?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${process.env.NEXT_PUBLIC_URL}/cart`,
  });

  return NextResponse.json({ url: session.url });
}

這是一個可行的結帳端點。不到 30 行。對於完全嵌入式結帳（無重定向），Stripe Elements 與其 React 組件一樣簡單明瞭。

Stripe 的薄弱環節

Stripe 的帳戶保留和儲備政策對新企業來說可能很殘酷。我有客戶的資金被保留了 2-4 週，而 Stripe 支持沒有太多解釋。他們的欺詐檢測（Radar）很好，但不完美 — 對於高風險垂直領域，您仍然會希望分層進行額外檢查。

另外，在您每月處理約 $80K 之前，Stripe 的定價是不可協商的。在此之下，無論如何您都在支付標準費率。

Stripe Connect 和市場支持

如果您正在構建市場，Stripe Connect 遠領先於此列表中的任何其他內容。分割付款、托管帳戶、1099 生成 — 全部都在這裡。我們在幾個無頭商務構建中使用了它，其中供應商需要自己的付款流程。

PayPal 深度分析

轉換論證

PayPal 最大的賣點不是它的技術 — 它是它的品牌。截至 2025 年，全球有超過 4.3 億個活躍帳戶。對於某些客戶群（特別是年長人口、國際買家和行動購物者），看到 PayPal 按鈕確實會增加結帳完成率。研究一致顯示，當提供 PayPal 作為選項時，結帳完成增加 28-44%。

這不算什麼。那是真實的錢。

開發者體驗問題

但哦，開發者體驗。PayPal 的 API 具有使集成痛苦的遺留代碼層。他們多年來一直在從 v1 REST API 遷移到 v2，文檔仍然引用兩者。JavaScript SDK 已通過他們較新的 Advanced Checkout 產品改進，但構建完全自訂結帳流程仍然感覺像是在與一個真正想讓您使用其托管按鈕的系統搏鬥。

// PayPal 的伺服器端訂單建立
// 注意：需要他們的 SDK 和授權令牌管理
import { PayPalHttpClient, SandboxEnvironment, OrdersCreateRequest } from '@paypal/checkout-server-sdk';

const environment = new SandboxEnvironment(
  process.env.PAYPAL_CLIENT_ID!,
  process.env.PAYPAL_SECRET!
);
const client = new PayPalHttpClient(environment);

export async function createOrder(cart: CartItem[]) {
  const request = new OrdersCreateRequest();
  request.prefer('return=representation');
  request.requestBody({
    intent: 'CAPTURE',
    purchase_units: [{
      amount: {
        currency_code: 'USD',
        value: calculateTotal(cart).toString(),
      },
    }],
  });
  
  const response = await client.execute(request);
  return response.result;
}

它可以工作，但它有更多的樣板代碼、更多的授權管理，而且不如 Stripe 的方法直觀。

我對 PayPal 的誠實看法

提供 PayPal 作為次要付款方法。不要將其作為主要閘道。使用 Stripe 進行後端配管，在結帳中為喜歡使用 PayPal 的客戶添加 PayPal 按鈕。這就是我們在 Social Animal 構建的大多數商店最終的做法，它融合了兩個世界的最好的。

Klarna 深度分析

BNPL 作為增長戰略

Klarna 實際上不是傳統意義上的支付閘道。這是一個碰巧處理付款的融資產品。當客戶選擇 Klarna 時，他們正在將購買分為分期付款（通常是 4 個無息付款），而 Klarna 預先向您支付全額。

對於銷售 $50-$500 範圍內產品的商人 — 例如時尚、美容、家居用品 — Klarna 可以顯著提高平均訂單價值。Klarna 自己的數據聲稱 AOV 增加 45%，轉換率提高 30%，儘管獨立研究將這些數字定為有些許低。

無頭商務整合

Klarna 的整合已顯著改進。他們的 Klarna Payments API 和 Klarna Checkout API 都支持無頭架構，儘管實現更多基於小部件而不是 API 優先：

// Klarna 會話建立（伺服器端）
export async function createKlarnaSession(cart: CartItem[]) {
  const response = await fetch('https://api.klarna.com/payments/v1/sessions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Basic ${Buffer.from(
        `${process.env.KLARNA_USERNAME}:${process.env.KLARNA_PASSWORD}`
      ).toString('base64')}`,
    },
    body: JSON.stringify({
      purchase_country: 'US',
      purchase_currency: 'USD',
      locale: 'en-US',
      order_amount: calculateTotal(cart),
      order_lines: cart.map(item => ({
        name: item.name,
        quantity: item.quantity,
        unit_price: item.price,
        total_amount: item.price * item.quantity,
      })),
    }),
  });
  
  return response.json(); // 返回前端小部件的 client_token
}

客戶端令牌被傳遞到 Klarna 的 JavaScript 小部件，該小部件在您的結帳中呈現付款選項。它不如 Stripe Elements 靈活，但它有效。

Klarna 的缺點

支付時間是最大的。淨 15-30 天的支付，相比 Stripe 或 Square 的 1-2 天，可能會造成嚴重的現金流問題，特別是對於較小的商人。更高的商家費用也會侵蝕利潤。而且 Klarna 的開發者門戶雖然有所改進，但在邊界情況的文檔中仍然存在差距。

Klarna 全球也面臨越來越多的監管審查。英國、歐盟和澳大利亞都為 BNPL 產品引入了或提議了新法規。這不會殺死 Klarna，但值得監控。

Square 深度分析

全渠道遊戲

Square 的超級力量是統一線上和線下商務。如果您的客戶除了無頭電子商務網站外還有實體零售位置，Square 的生態系統使庫存同步、報告和付款對帳變得比拼湊單獨的系統簡單得多。

Web Payments SDK

Square 的 Web Payments SDK 是可靠的。不如 Stripe 優雅，但文檔完善且積極維護：

// Square 付款表單初始化（客戶端）
import { payments } from '@square/web-payments-sdk-types';

async function initSquarePayment() {
  const payments = window.Square.payments(
    process.env.NEXT_PUBLIC_SQUARE_APP_ID!,
    process.env.NEXT_PUBLIC_SQUARE_LOCATION_ID!
  );
  
  const card = await payments.card();
  await card.attach('#card-container');
  
  // 在表單提交時
  const result = await card.tokenize();
  if (result.status === 'OK') {
    // 將 result.token 發送到您的伺服器
    await processPayment(result.token);
  }
}

Square 在無頭商務方面的不足之處

Square 的 API 是根據他們的生態系統構建的。如果您在 Square 的 POS、庫存和線上銷售中全力以赴，那很好。如果您將無頭 CMS（如 Sanity 或 Contentful）與單獨的商務層一起使用，Square 的 API 可能會令人感到侷限。他們的產品目錄深深融入 Square 自己的數據模型，這並不總是將無頭商務架構清晰地映射。

國際支持也比 Stripe 或 PayPal 弱。截至 2026 年，Square 僅在 8 個國家（美國、加拿大、英國、澳大利亞、日本、法國、愛爾蘭、西班牙）運營。如果您需要在全球銷售，這是一個硬性限制。

無頭 CMS 和 Next.js 整合模式

以下是我們在 Next.js 開發項目中通常如何連接這些的：

模式 1：Stripe + 無頭 CMS（最常見）

  1. 產品數據存在於無頭 CMS 中（Sanity、Contentful 等）
  2. Next.js 在構建時或根據請求獲取產品數據
  3. 購物車狀態由客戶端管理（Zustand、Redux 或 Context）
  4. Stripe Checkout Session 通過 Next.js API 路由建立
  5. Webhooks（通過 checkout.session.completed）觸發 CMS 中的訂單建立或單獨的訂單管理系統

這是我們的麵包和黃油。它有效、可擴展，而且 Stripe 完全在他們這一端處理 PCI 合規。

模式 2：多閘道結帳

對於想要最大轉換的商店，我們將 Stripe 實施為主要處理商，PayPal 和/或 Klarna 作為次要選項。結帳頁面呈現所有選項，後端為每個閘道提供單獨的 API 路由。來自每個提供商的 Webhooks 進入相同的訂單管理流程。

這增加了複雜性，但明顯提高了轉換率，特別是對於國際流量。

模式 3：用於全渠道的 Square

當客戶有實體店並想要統一系統時，我們使用 Next.js 構建無頭前端，但將 Square 的 API 用於整個商務後端 — 目錄、庫存、付款和履行。它的意見比模式 1 更多，但對於客戶的運營簡單性是重要的。

您應該實際選擇哪一個？

以下是我的誠實、沒有迴避的推薦：

對於大多數無頭商務項目：Stripe。 當您考慮 API 品質、文檔、Next.js 支持和生態系統時，它不是偶然。如果您的客戶基數傾向於年長或國際，添加 PayPal 作為次要方法。

對於針對年輕人口統計的時尚/生活方式品牌： Stripe + Klarna。BNPL 選項確實為 $50-$300 範圍內的衝動購買帶來了變化。

對於擁有實體店的全渠道業務： Square 用於統一平台，或 Stripe 用於線上 + Square 用於 POS，如果您想要兩者的最佳。

對於市場平台： Stripe Connect。沒有其他東西接近多方付款流程。

如果您正在規劃無頭商務構建，並希望討論哪種付款架構對您的具體情況有意義，請聯絡我們。我們已經做了足夠的次數來在成本問題之前發現陷阱。

常見問題

2026 年在線交易的哪個支付閘道費用最低？ Stripe 和 Square 在標準國內線上交易中並列 2.9% + $0.30。PayPal 在 3.49% + $0.49 時最昂貴。但是，如果您每月處理超過 $80K，所有提供商都提供協商費率，而且 Stripe 的自訂定價往往在規模上最具競爭力。

我可以將 Stripe 與 Next.js App Router 和 Server Components 一起使用嗎？ 絕對地。Stripe 的 Node.js SDK 在 Next.js API 路由和 Server Actions 中完美工作。在客戶端，@stripe/react-stripe-js 和 @stripe/stripe-js 通過客戶端組件包裝與 React Server Components 整合。Stripe 在其文檔中有使用 App Router 模式的官方 Next.js 示例。

對於小型電子商務商店，Klarna 值得嗎？ 這取決於您的產品類別和平均訂單價值。如果您在時尚、美容或家居用品中銷售 $50-$500 範圍內的商品，Klarna 的轉換提升可以為更高的商家費用（3.29% - 5.99%）辯護。對於低 AOV 產品或 B2B 銷售，數學通常不起作用。還要考慮 Klarna 更長的支付時間 — 淨 15-30 天可能會給較小的運營造成現金流壓力。

我如何使用無頭商務設置處理 PCI 合規？ 所有四個提供商都提供令牌化功能，將原始卡數據保留在您的伺服器外。使用 Stripe Elements、PayPal 的托管字段、Klarna 的小部件或 Square 的 Web Payments SDK，卡號在由付款提供商控制的 iframe 中捕獲。您的伺服器只能看到令牌。這將您保持在 PCI SAQ-A 級別，這是最輕的合規負擔。永遠不要構建自訂卡輸入表單 — 它不值得責任。

我可以在同一個無頭商店上使用多個支付閘道嗎？ 是的，您可能應該這樣做。我們實施的最常見模式是 Stripe 作為主要處理商，PayPal 作為次要選項。每個閘道有自己的 API 路由和 webhook 處理程序，但它們進入相同的訂單管理系統。額外的開發複雜性是真實的，但可管理的 — 通常對於高級開發人員來說需要額外 2-3 天的工作。

Square 是否適用於國際電子商務？ 不是真的。截至 2026 年，Square 僅在 8 個國家運營，跨境交易會產生更高的費用。如果國際銷售佔您收入的 10-15% 以上，Stripe 是顯著更好的選擇，支持 135+ 種貨幣和本地化付款方法。Square 在國內全渠道商務方面表現出色，但在全球覆蓋方面落後。

什麼是基於訂閱的無頭商務的最佳支付閘道？ Stripe Billing 是明確的贏家。它通過 API 處理訂閱建立、按比例分配、催收（失敗的付款重試）、發票和客戶門戶。PayPal 有訂閱支持，但更有限，API 也更笨拙。Square 最近添加了訂閱計費，但它仍在成熟。Klarna 本身不支持經常性付款。

將支付閘道集成到 Next.js 無頭商務網站中需要多長時間？ 對於高級開發人員，基本 Stripe 整合需要 2-4 小時。PayPal 通常需要 4-8 小時，因為其更複雜的 SDK。Klarna 運行 6-12 小時，因為基於會話的小部件流和批准流程。Square 登陸 3-6 小時。這些估計假設一個標準結帳流程 — 訂閱、市場付款或多貨幣設置會增加更多時間。如果您需要幫助確定範圍，我們在 Social Animal 的團隊可以通過我們的定價頁面提供估計。