Creem — 토스도 Stripe도 막혔을 때 붙이는 결제

왜 국내 PG가 아니라 Creem을 봤나

만들던 서비스에 결제를 붙이려고 토스페이먼츠에 가맹점 신청을 여섯 번 했고 여섯 번 다 거절당했다. 그런데 여섯 번 중 사유를 들은 것은 한 번뿐이다. 마지막 한 번은 "확인 중"이라는 답만 왔고, 나머지 네 번은 지금도 왜 떨어졌는지 모른다. 카드사 심사 기준이 비공개라 구체적인 항목을 통보하지 않기 때문이다. 여섯 번을 떨어지고도 다섯 번은 이유를 모른다는 것이 이 심사의 성격이다. 서류를 보완하는 문제가 아니라 통과 여부를 예측할 수 없는 문제라, 재신청으로 뚫는 계획 자체가 서지 않는다.

그다음 후보가 Stripe였다. 그런데 Stripe는 한국 사업자가 계정을 만들 수 없다. 공식 지원 국가 페이지(stripe.com/global)에는 오스트리아부터 영국까지 유럽 32개국, 아시아태평양에서는 호주·홍콩·일본·말레이시아·뉴질랜드·싱가포르·태국이 올라 있고 인도·인도네시아가 초대 전용으로 표시돼 있는데, 한국은 지원 목록에도 초대 목록에도 없다(2026-08-06 확인).

이 두 문장이 합쳐지면 선택지가 좁아진다. 국내 PG는 심사가 막고 Stripe는 국가가 막는다. 남는 길이 해외 머천트 오브 레코드 플랫폼이고, 그중 하나가 Creem이다.

덧붙이면 이건 기술 문제가 아니라 제도 문제다. 코드를 아무리 잘 짜도 결제 계약이 안 나오면 서비스는 돈을 받을 수 없다. 바이브 코딩으로 로그인과 기능까지 다 만들어 놓고 마지막에 멈추는 지점이 대개 여기다.

머천트 오브 레코드가 정확히 무엇인가

머천트 오브 레코드(Merchant of Record, 줄여서 MoR)는 최종 고객에게 상품을 파는 법적 주체를 뜻한다. Creem 문서는 자기 역할을 "the legal entity responsible for selling goods or services to end customers"라고 적는다. 즉 고객은 서류상 나에게서 사는 것이 아니라 Creem에게서 산다.

이게 흔히 쓰는 PG(결제대행사)와 다른 지점이다. PG는 카드 결제라는 통로만 빌려준다. 파는 사람은 여전히 나이고, 그래서 세금 신고도 환불 처리도 분쟁 대응도 내가 한다. MoR은 파는 사람 자리를 통째로 대신 선다.

그래서 Creem이 지는 항목이 구체적이다. 결제 처리, 시장별 세무 준수, 판매세 징수와 납부, 환불과 차지백 관리, 190여 관할의 세금 계산과 징수, 규정에 맞는 인보이스 발행, 세무 신고. 해외 고객에게 소프트웨어를 팔아 본 적이 있으면 이 목록이 왜 반가운지 안다. EU 부가가치세 하나만 해도 나라마다 세율과 신고 주기가 다르다.

대가는 두 가지다. 하나는 수수료가 국내 카드 수수료보다 높다는 것이고, 다른 하나는 고객 카드 명세서에 내 서비스 이름이 아니라 CREEM이 찍힌다는 것이다. 두 번째는 실제로 문의가 잦은지 Creem 문서에 "Why did Creem charge me"라는 고객용 페이지가 따로 있다. 결제 확인 메일이나 상품 페이지에 "결제는 Creem을 통해 처리됩니다"라고 미리 적어 두면 문의가 줄어든다.

코드 없이 파는 가장 짧은 길

개발을 하지 않아도 결제까지 갈 수 있다. Creem이 무코드 경로를 따로 두고 있고, 문서에서 그 대상을 "creators, vibe coders"라고 부른다.

첫째, creem.io에서 가입한다. 계정을 만들 때 신용카드를 요구하지 않는다. 로그인하면 스토어를 하나 만든다.

둘째, 테스트 모드를 켠다. 실제 돈이 오가지 않는 상태로 결제 흐름 전체를 끝까지 돌려 볼 수 있다. 실서비스로 넘기기 전까지는 이 상태로 작업하는 편이 안전하다.

셋째, 대시보드의 Products 탭에서 상품을 만든다. 이름, 설명, 가격을 넣는다. 단일 결제(single payment)와 구독(subscription) 중에 고르고, 통화와 카테고리를 지정한다. 전자책이나 템플릿처럼 파일로 주는 상품이면 여기서 파일을 올려 둔다. 결제가 끝나면 그 파일 다운로드 링크가 구매자 메일로 자동으로 나간다.

넷째, 만들어진 상품의 Share 버튼을 누르면 결제 링크가 나온다. 이 주소를 메일이든 인스타그램 프로필이든 블로그 글 끝이든 어디에 붙여도 결제가 열린다. 여기까지가 코드 한 줄 없이 도달할 수 있는 지점이다.

이 경로만으로도 전자책·템플릿·강의자료 판매는 성립한다. 사이트를 먼저 만들고 결제를 붙이는 순서가 아니라, 결제 링크로 먼저 팔아 보고 반응이 있으면 사이트를 만드는 순서도 가능하다는 뜻이다.

코드로 붙이기 — Next.js 기준 네 단계

내 사이트 안에서 결제창을 열려면 API 키와 product ID 두 개만 있으면 된다.

1단계, API 키를 받는다. 대시보드의 Developers 메뉴에 있다. 복사해서 프로젝트 루트의 .env 파일에 CREEM_API_KEY라는 이름으로 넣는다. 이 키는 절대 프론트엔드 코드나 깃 저장소에 올리면 안 된다. .env가 .gitignore에 들어 있는지 먼저 확인한다.

2단계, 어댑터를 설치한다. Next.js를 쓰면 전용 어댑터가 있어서 가장 짧다. 다른 프레임워크면 TypeScript SDK(npm install creem)를, 아예 다른 언어면 REST API를 직접 부르면 된다.

3단계, 결제 API 라우트를 만든다. app/api/checkout/route.ts 한 파일이면 된다. testMode: true는 테스트 모드일 때 켜 두고, 실서비스로 넘길 때 false로 바꾼다.

4단계, 버튼을 감싼다. 상품 페이지에서 만든 product ID(prod_로 시작한다)를 컴포넌트에 넘기면 그 버튼이 곧 결제 버튼이 된다.

여기까지 하고 npm run dev로 띄운 뒤 버튼을 눌러 보면 Creem 결제창이 열린다. 테스트 모드에서는 카드 번호 4111 1111 1111 1111에 만료일은 미래 아무 날짜, CVC는 아무 세 자리를 넣으면 결제가 통과한다. 결제가 끝나면 성공 페이지로 돌아오는데, 주소창에 checkout_id·order_id·customer_id·product_id가 쿼리 파라미터로 붙어 온다.

CREEM_API_KEY=creem_test_your_api_key
CREEM_WEBHOOK_SECRET=whsec_your_webhook_secret
NEXT_PUBLIC_APP_URL=http://localhost:3000

npm install @creem_io/nextjs

import { Checkout } from "@creem_io/nextjs";

export const GET = Checkout({
  apiKey: process.env.CREEM_API_KEY!,
  testMode: true,
  defaultSuccessUrl: "/success",
});

import { CreemCheckout } from "@creem_io/nextjs";

export default function Page() {
  return (
    <CreemCheckout productId="prod_YOUR_PRODUCT_ID">
      <button>결제하기</button>
    </CreemCheckout>
  );
}

결제 뒤를 자동화하는 웹훅

성공 페이지로 돌아온 것만 믿고 상품을 열어 주면 안 된다. 결제 직후에 사용자가 창을 닫아 버리면 내 서버는 결제가 됐는지 모른 채로 남는다. 반대로 성공 페이지 주소를 알아낸 사람이 직접 열어 볼 수도 있다. 그래서 실서비스에서는 웹훅을 쓴다.

웹훅은 Creem 서버가 내 서버로 "이 결제가 끝났다"고 직접 알려 주는 통로다. 사용자의 브라우저를 거치지 않으니 창을 닫아도 도착한다.

대시보드에서 웹훅 시크릿을 받아 .env의 CREEM_WEBHOOK_SECRET에 넣고, 라우트 하나를 더 만든다. 서명 검증에 실패하면 401로 끊는 부분이 중요하다. 이 검증이 없으면 아무나 결제 완료 요청을 흉내 내 상품을 가져갈 수 있다.

받아 볼 이벤트는 세 개로 시작하면 충분하다. checkout.completed는 결제가 끝난 순간, subscription.active는 구독이 시작되거나 갱신된 순간, subscription.canceled는 구독이 해지된 순간이다. 각각의 자리에서 접근 권한을 열고, 유지하고, 거둔다.

import { NextRequest, NextResponse } from "next/server";
import { constructWebhookEventEntity } from "creem/webhooks";

export async function POST(request: NextRequest) {
  const body = await request.text();
  const event = await constructWebhookEventEntity(body, request.headers, {
    secret: process.env.CREEM_WEBHOOK_SECRET!,
  }).catch(() => null);

  if (!event) {
    return NextResponse.json({ error: "Invalid signature" }, { status: 401 });
  }

  switch (event.eventType) {
    case "checkout.completed":
      // 접근 권한 부여, 메일 발송, DB 갱신
      break;
    case "subscription.active":
      break;
    case "subscription.canceled":
      // 접근 권한 회수
      break;
  }

  return NextResponse.json({ received: true });
}

실서비스로 넘기기 전에 확인할 것

테스트 모드를 끈다. REST API를 직접 부르고 있었다면 주소도 test-api.creem.io에서 api.creem.io로 바꾼다. 어댑터를 쓰고 있으면 testMode를 false로 내리면 된다. 이걸 안 바꾸면 실제 결제가 한 건도 들어오지 않는데 화면상으로는 아무 문제가 없어 보인다.

수수료를 계산에 넣는다. 성공한 결제 건당 3.9% + 0.40달러다. 월 이용료, 설치비, 숨은 비용이 없다고 문서가 명시한다. 다만 이 숫자는 국내 카드 수수료보다 싸지 않다. 대신 세무 신고와 환불·분쟁 처리를 넘긴 값이라고 보는 편이 맞다. 단가가 낮은 상품일수록 고정비 0.40달러의 비중이 커지니, 1~2달러짜리를 낱개로 파는 구조라면 묶음 판매나 구독으로 설계를 바꾸는 편이 낫다.

판매자 자격 요건은 직접 확인한다. Creem 공개 문서에는 어느 나라 판매자가 가입할 수 있는지, 사업자 등록이 필요한지, 어떤 신원 확인을 요구하는지가 적혀 있지 않다. 정산 방식과 주기도 마찬가지다. "190여 개국"이라는 숫자는 세금을 처리하는 고객 쪽 관할 수이지 판매자 자격 범위가 아니다. 그래서 이 글에서도 단정하지 않는다. 가입은 신용카드 없이 되니 계정을 먼저 만들어 온보딩 화면에서 무엇을 요구하는지 눈으로 확인하는 것이 가장 빠르다.

결제 수단을 확인한다. 달러 결제와 국제 카드가 중심이라 카카오페이·네이버페이·계좌이체 같은 국내 수단이 약하다. 고객이 대부분 한국인이고 소액 결제가 많다면 이 구조가 잘 안 맞을 수 있다. 반대로 해외 고객에게 소프트웨어나 디지털 상품을 파는 구조라면 원래 이쪽이 맞는 도구다.

명세서 표기를 미리 알린다. 앞에서 말한 CREEM 표기 문제다. 상품 페이지와 결제 완료 메일에 한 줄 적어 두는 것으로 대부분 해결된다.