Your checkout button fires and somewhere a payment gateway decides whether to route the request in 180ms or throw a cryptic 400 error at 11 PM. I've wired Stripe, PayPal, Klarna, and Square into 47 production headless commerce stores since 2023. Some integrations shipped in an afternoon. Others burned entire weekends hunting down webhook signature mismatches and undocumented rate limits. This breakdown covers real fees, developer experience, and headless Next.js integration — because one gateway will save your client $8K in transaction costs this year, and another will quietly eat 4.2% of every sale. But which one depends on three variables most comparison posts never mention.

If you're building (or rebuilding) an ecommerce storefront and you need to pick a payment processor, this is the article I wish I'd had three years ago.

Table of Contents

Stripe vs PayPal vs Klarna vs Square: Payment Gateway Comparison 2026

Why Payment Gateway Choice Matters for Headless Commerce

기존의 Shopify나 WooCommerce 같은 모놀리식 이커머스 플랫폼에서는 결제 게이트웨이가 이미 통합되어 있습니다. 드롭다운에서 선택하고, API 키를 붙여넣으면 끝입니다. 헤드리스 커머스는 다릅니다.

프론트엔드를 백엔드에서 분리할 때 — Next.js 스토어프론트를 헤드리스 CMS 및 별도의 커머스 API와 연결할 때 — 결제 게이트웨이는 1급 아키텍처 결정사항이 됩니다. 이는 다음에 영향을 미칩니다:

  • 체크아웃 UX: 완전히 맞춤형 체크아웃을 구축할 수 있나요, 아니면 사용자를 호스팅된 페이지로 리디렉션해야 하나요?
  • 서버 측 로직: 웹훅은 어떻게 작동하나요? 결제 확인을 이행 전에 어떻게 처리하나요?
  • PCI 규정 준수 부담: 클라이언트에서 토큰화되나요, 아니면 카드 번호가 서버에 도달하나요?
  • 구독 및 반복 청구: 게이트웨이가 기본적으로 처리하나요, 아니면 다른 서비스를 추가해야 하나요?
  • 국제 확장: 통화 지원, 현지 결제 방법, 규제 준수.

잘못된 선택은 수개월의 재작업이 걸릴 수 있습니다. 저는 그런 일이 일어나는 것을 봤습니다. 한 클라이언트가 물리적 소매 매장이 있다는 이유로 Square를 선택했는데, Square의 온라인 API가 필요한 구독 모델을 처리할 수 없다는 것을 발견했습니다. 결국 두 개의 결제 처리자를 병렬로 실행하게 되었습니다. 그런 팀이 되지 마세요.

Pricing and Transaction Fees Compared

모두가 알고 싶어 하는 것부터 시작하겠습니다: 각각의 실제 비용은 얼마인가요?

이 숫자들은 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일 Net 15-30일 1-2일
거래량 할인 네 (월 80K+ 커스텀 가격) 네 (영업 담당자 문의) 협상 가능 네 (커스텀 가격)

The Real Cost Analysis

원시 백분율은 전체 이야기를 말하지 않습니다. 각 공급자를 사용하여 월 $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 또는 낮은 마진 제품의 경우? 아마도 아닙니다.

Developer Experience and Integration Complexity

여기서 제 의견이 강해집니다. 저는 이 API와 SDK에서 수백 시간을 보냈고, 차이점은 미묘하지 않습니다.

측면 Stripe PayPal Klarna Square
API 설계 품질 ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆
문서 ★★★★★ ★★★☆☆ ★★★☆☆ ★★★★☆
Next.js SDK/지원 ★★★★★ ★★★☆☆ ★★★★☆ ★★★☆☆
웹훅 안정성 ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆
테스트/샌드박스 모드 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★☆
첫 통합까지의 시간 2-4시간 4-8시간 6-12시간 3-6시간
맞춤형 체크아웃 지원 전체 제한됨 (고급 체크아웃) 부분적 (위젯 기반) 전체 (Web Payments SDK)

Stripe vs PayPal vs Klarna vs Square: Payment Gateway Comparison 2026 - architecture

Stripe Deep Dive

Why Developers Love Stripe

Stripe의 API는 금본위제입니다. 완전히. 모든 엔드포인트는 일관성 있고, 모든 오류 메시지는 도움이 되며, 문서는 실제로 API를 사용하는 누군가가 작성한 것처럼 읽힙니다. 대시보드는 깔끔하고, 테스트 모드는 훌륭하며, Stripe CLI를 사용하면 웹훅을 로컬 개발 환경으로 전달할 수 있습니다.

헤드리스 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줄 미만. 완전히 임베드된 체크아웃 (리디렉션 없음)의 경우 React 컴포넌트를 사용하는 Stripe Elements도 마찬가지로 간단합니다.

Stripe's Weak Spots

Stripe의 계정 보유 및 예약 정책은 새로운 비즈니스에 무서울 수 있습니다. 저는 클라이언트가 자금을 2-4주 동안 보유하고 지원으로부터 거의 설명을 받지 못하는 경우를 보았습니다. 그들의 사기 탐지 (Radar)는 좋지만 완벽하지 않습니다 -- 고위험 업종의 경우 여전히 추가 검사를 계층화해야 합니다.

또한 Stripe의 가격은 월 약 $80K를 처리할 때까지 협상 불가능합니다. 아래 그것은 상관없이 표준 요금을 지불하고 있습니다.

Stripe Connect and Marketplace Support

마켓플레이스를 구축하는 경우 Stripe Connect는 이 목록의 다른 모든 것보다 몇 년 앞서 있습니다. 분할 결제, 관리 계정, 1099 생성 -- 모두 있습니다. 우리는 벤더가 자신의 결제 흐름이 필요한 여러 헤드리스 커머스 빌드에서 이를 사용했습니다.

PayPal Deep Dive

The Conversion Argument

PayPal의 가장 큰 장점은 기술이 아니라 브랜드입니다. 2025년 현재 전 세계 4억 3천만 개의 활성 계정. 특정 고객 세그먼트 (특히 나이가 많은 인구통계, 국제 구매자 및 모바일 쇼핑객)의 경우 PayPal 버튼을 보는 것이 실제로 체크아웃 완성률을 높입니다. 연구에 따르면 PayPal이 옵션으로 제공될 때 체크아웃 완성에서 28-44% 상승이 일관되게 나타납니다.

그건 아무것도 아닙니다. 그건 실제 돈입니다.

The Developer Experience Problem

하지만 오, 개발자 경험. PayPal의 API는 통합을 고통스럽게 만드는 유산 장비 계층을 가지고 있습니다. 그들은 오래되었던 v1 REST API에서 v2로 마이그레이션하고 있었는데, 문서는 여전히 둘 다 참조합니다. JavaScript SDK는 새로운 고급 체크아웃 제품으로 개선되었지만, 완전히 맞춤형 체크아웃 흐름을 구축하는 것은 여전히 정말로 호스팅된 버튼을 사용하고 싶어 하는 시스템과 씨름하는 것처럼 느껴집니다.

// 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의 접근보다 덜 직관적입니다.

My Honest Take on PayPal

보조 결제 방법으로 PayPal을 제공하세요. 기본 게이트웨이로 만들지 마세요. Stripe를 백엔드 배관에 사용하고 PayPal을 선호하는 고객을 위해 체크아웃에 PayPal 버튼을 붙이세요. 이것이 Social Animal에서 구축하는 대부분의 스토어가 최종적으로 하는 일이며, 두 세계의 최고를 모두 포착합니다.

Klarna Deep Dive

BNPL as a Growth Strategy

Klarna는 실제로 기존 의미의 결제 게이트웨이가 아닙니다. 그것은 결제를 처리하는 금융 상품입니다. 고객이 Klarna를 선택하면, 그들은 그들의 구매를 할부금으로 나누고 있습니다 (일반적으로 4개의 무이자 결제), Klarna는 당신에게 전체 금액을 미리 지불합니다.

$50-$500 범위의 상품을 판매하는 가맹점의 경우 -- 패션, 미용, 홈 상품을 생각해 보세요 -- Klarna는 평균 주문 가치를 측정 가능하게 증가시킬 수 있습니다. Klarna의 자체 데이터는 AOV에서 45% 증가, 전환 요금에서 30% 상승을 주장하지만, 독립적인 연구는 이들 숫자를 다소 낮게 설정합니다.

Integration for Headless Commerce

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's Downsides

지급 타이밍이 큰 것입니다. Stripe 또는 Square에서 1-2일에 비해 Net 15-30일 지급은 특히 작은 가맹점의 경우 심각한 현금 흐름 문제를 만들 수 있습니다. 더 높은 가맹점 수수료도 마진을 먹습니다. Klarna의 개발자 포털은 개선되었지만, 엣지 케이스에 대한 문서에 여전히 격차가 있습니다.

또한 BNPL 공급자에 대한 전 세계적인 규제 정밀 조사도 증가하고 있습니다. 영국, EU, 호주 모두 BNPL 상품에 대한 새로운 규정을 도입했거나 제안했습니다. 이것이 Klarna를 죽이지는 않을 것이지만, 모니터링할 가치가 있습니다.

Square Deep Dive

The Omnichannel Play

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);
  }
}

Where Square Falls Short for Headless

Square의 API는 그들의 생태계 주위에 구축됩니다. POS, 재고 및 온라인 판매를 위해 Square에 완전히 참여하고 있다면 좋습니다. Sanity 또는 Contentful과 같은 헤드리스 CMS를 별도의 커머스 계층과 함께 사용하고 있다면, Square의 API가 제한적으로 느껴질 수 있습니다. 그들의 상품 카탈로그는 Square의 자체 데이터 모델과 깊게 연결되어 있으며, 항상 헤드리스 커머스 아키텍처에 깔끔하게 매핑되지는 않습니다.

국제 지원도 Stripe 또는 PayPal보다 약합니다. Square는 2026년 현재 8개국에서만 운영합니다 (미국, 캐나다, 영국, 호주, 일본, 프랑스, 아일랜드, 스페인). 전 세계적으로 판매해야 하는 경우 이것은 어려운 한계입니다.

Headless CMS and Next.js Integration Patterns

다음은 우리가 일반적으로 Next.js 개발 프로젝트에서 이를 어떻게 연결하는지입니다:

Pattern 1: Stripe + Headless CMS (Most Common)

  1. 상품 데이터는 헤드리스 CMS (Sanity, Contentful 등)에 있습니다.
  2. Next.js는 빌드 시간에 또는 요청 시에 상품 데이터를 가져옵니다.
  3. 장바구니 상태는 클라이언트 측에서 관리됩니다 (Zustand, Redux 또는 Context)
  4. Stripe Checkout Session은 Next.js API 경로를 통해 생성됩니다.
  5. 웹훅 (checkout.session.completed 통해)은 CMS 또는 별도의 주문 관리 시스템에서 주문 생성을 트리거합니다.

이것이 우리의 핵심입니다. 그것은 작동하고, 확장되며, Stripe는 PCI 규정 준수를 완전히 자신의 끝에서 처리합니다.

Pattern 2: Multi-Gateway Checkout

최대 전환을 원하는 스토어의 경우 Stripe를 기본 프로세서로 구현하고 PayPal 및/또는 Klarna를 보조 옵션으로 구현합니다. 체크아웃 페이지는 모든 옵션을 렌더링하고, 백엔드는 각 게이트웨이에 대해 별도의 API 경로를 가집니다. 각 공급자의 웹훅은 동일한 주문 관리 흐름으로 공급됩니다.

이것은 복잡성을 추가하지만, 특히 국제 트래픽의 경우 전환율을 측정 가능하게 개선합니다.

Pattern 3: Square for Omnichannel

클라이언트가 물리적 스토어를 가지고 있고 통합 시스템을 원할 때, 우리는 헤드리스 프론트엔드를 Next.js로 구축하지만 Square의 API를 전체 커머스 백엔드에 사용합니다 -- 카탈로그, 재고, 결제 및 이행. Pattern 1보다 더 의견이 있지만, 클라이언트의 운영 단순성은 상당합니다.

Which One Should You Actually Choose?

솔직한, 변명 없는 권장사항을 말씀드리겠습니다:

대부분의 헤드리스 커머스 프로젝트의 경우: Stripe. API 품질, 문서, Next.js 지원 및 생태계를 고려할 때 심지어 그렇지 않습니다. 고객 기반이 나이가 많거나 국제적인 경우 보조 방법으로 PayPal을 추가하세요.

더 젊은 인구통계를 목표로 하는 패션/라이프스타일 브랜드의 경우: Stripe + Klarna. BNPL 옵션은 $50-$300 범위의 충동 구매에 대해 정말 동작합니다.

물리적 스토어가 있는 옴니채널 비즈니스의 경우: 통합 플랫폼의 경우 Square, 또는 온라인의 경우 Stripe + POS의 경우 Square (둘 다의 최고를 원하는 경우).

마켓플레이스 플랫폼의 경우: Stripe Connect. 다중 당사자 결제 흐름의 경우 다른 것은 가까이 가지도 않습니다.

헤드리스 커머스 빌드를 계획하고 있고 어떤 결제 아키텍처가 특정 경우에 맞는지에 대해 이야기하고 싶다면, 저희에게 문의하세요. 우리는 이것을 충분히 많이 해서 비용이 많이 드는 문제가 되기 전에 함정을 발견할 수 있습니다.

FAQ

2026년에 온라인 거래에서 가장 낮은 수수료를 가진 결제 게이트웨이는 어느 것인가요?

Stripe와 Square는 표준 국내 온라인 거래에 대해 2.9% + $0.30로 동료입니다. PayPal은 3.49% + $0.49로 가장 비쌉니다. 그러나 월 $80K 이상을 처리하고 있다면, 모든 공급자는 협상된 요금을 제공하며, Stripe의 커스텀 가격은 규모에서 가장 경쟁력 있는 경향이 있습니다.

Next.js App Router 및 Server Components와 함께 Stripe를 사용할 수 있나요?

절대적으로. 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의 더 긴 지급 타이밍을 고려하세요 -- net 15-30일은 더 작은 운영을 위해 현금 흐름을 긴장시킬 수 있습니다.

헤드리스 커머스 설정에서 PCI 규정 준수를 어떻게 처리하나요?

모든 네 공급자는 원시 카드 데이터를 서버에서 떨어지게 하는 토큰화를 제공합니다. Stripe Elements, PayPal의 호스팅된 필드, Klarna의 위젯 또는 Square의 Web Payments SDK를 사용하면 카드 번호가 결제 공급자가 제어하는 iframe에 캡처됩니다. 서버는 토큰만 봅니다. 이는 당신을 PCI SAQ-A 수준으로 유지하며, 이것이 가장 가벼운 규정 준수 부담입니다. 맞춤형 카드 입력 양식을 구축하지 마세요 -- 책임의 가치가 없습니다.

동일한 헤드리스 스토어에서 여러 결제 게이트웨이를 사용할 수 있나요?

네, 아마도 해야 합니다. 우리가 구현하는 가장 일반적인 패턴은 Stripe를 기본 프로세서로, PayPal을 보조 옵션으로 합니다. 각 게이트웨이는 자체 API 경로 및 웹훅 핸들러를 가지지만, 동일한 주문 관리 시스템으로 공급됩니다. 추가된 개발 복잡성은 실제이지만 관리 가능합니다 -- 일반적으로 선임 개발자를 위해 2-3일의 추가 작업입니다.

Square는 국제 이커머스에 잘 작동하나요?

실제로 아닙니다. Square는 2026년 현재 8개국에서만 운영하며, 국경 간 거래는 더 높은 수수료를 부과합니다. 국제 판매가 수익의 10-15% 이상인 경우 Stripe가 상당히 더 나은 선택입니다 -- 135+ 통화 및 현지 결제 방법에 대한 지원이 있습니다. Square는 국내 옴니채널 커머스에 탁월하지만 글로벌 도달력에서 뒤떨어집니다.

구독 기반 헤드리스 커머스에 가장 좋은 결제 게이트웨이는 무엇인가요?

Stripe Billing은 명확한 우승자입니다. 구독 생성, 프로레이션, 던닝 (실패한 결제 재시도), 송장 및 고객 포털을 모두 API를 통해 처리합니다. PayPal은 구독 지원을 가지고 있지만 더 제한적이며 API는 더 복잡합니다. Square는 최근에 구독 청구를 추가했지만 여전히 성숙하고 있습니다. Klarna는 기본적으로 반복되는 결제를 지원하지 않습니다.

Next.js 헤드리스 커머스 사이트에 결제 게이트웨이를 통합하는 데 얼마나 오래 걸리나요?

선임 개발자의 경우 기본 Stripe 통합은 2-4시간이 걸립니다. PayPal은 일반적으로 더 복잡한 SDK로 인해 4-8시간이 걸립니다. Klarna는 세션 기반 위젯 흐름 및 승인 프로세스로 인해 6-12시간을 실행합니다. Square는 3-6시간입니다. 이 추정치는 표준 체크아웃 흐름을 가정합니다 -- 구독, 마켓플레이스 결제 또는 다중 통화 설정은 훨씬 더 많은 시간을 추가합니다. 이를 범위를 지정하는 데 도움이 필요한 경우, Social Animal의 팀은 가격 책정 페이지를 통해 추정치를 제공할 수 있습니다.