2025년 7월 02일·8분
웹사이트에 온라인 결제 추가하기: Stripe vs PayPal
웹사이트에 온라인 결제를 추가하는 기본과 Stripe와 PayPal의 설정, 체크아웃 경험, 수수료, 그리고 적합한 사용 사례의 차이를 알아봅니다.
웹사이트에 온라인 결제를 추가하는 기본과 Stripe와 PayPal의 설정, 체크아웃 경험, 수수료, 그리고 적합한 사용 사례의 차이를 알아봅니다.
사람들이 웹사이트에 "온라인 결제"를 추가하고 싶다고 말할 때, 보통은 몇 가지 구성요소로 이루어진 작은 시스템을 말합니다. 그 구성 요소들을 이해하면 용어에 혼란스러워하지 않고 Stripe와 PayPal을 비교하기가 훨씬 쉬워집니다.
실제론 제공업체들이 이들 역할을 결합하는 경우가 많습니다. 당신이 "설정"하는 것은 대부분 계정, 체크아웃 방식, 그리고 사이트가 그 제공업체와 통신하는 방식입니다.
대부분의 웹사이트는 신용/직불카드로 시작합니다. 국가와 제공업체 설정에 따라 다음을 추가할 수 있습니다:
어떤 조합을 제공할지는 판매 지역, 고객이 주로 있는 곳, 그리고 제공업체가 귀하의 계정에 대해 지원하는 방식에 따라 달라집니다.
일반적인 카드 결제 흐름은 다음과 같습니다:
핵심 요약: 단순히 "버튼을 추가"하는 것이 아니라 고객이 어떻게 결제하는지, 승인 과정이 어떻게 되는지, 돈이 은행으로 어떻게 도달하는지 — 그리고 체크아웃 경험을 얼마나 통제할지 결정하는 일입니다.
Stripe와 PayPal을 비교하기 전에, 사이트가 어색한 우회 없이 결제를 받을 준비가 되었는지 확인하세요. 이 "사전 점검"은 잘못된 체크아웃 유형을 선택하거나 나중에 제품/가격/흐름이 실제 구매 방식과 맞지 않는 것을 방지합니다.
다른 결제 설정이 다른 비즈니스 유형에 적합합니다. 자신이 어느 버킷에 속하는지 명확히 하세요:
이유: 구독 도구, 정산 기능, 분쟁 처리 방식은 모델에 따라 매우 다를 수 있습니다 — 두 제공업체 모두 카드를 받을 수 있어도 세부 기능은 다릅니다.
두 가지 간단한 숫자를 적어보세요: 평균 주문 금액(AOV) 과 주요 고객 국가.
곧 해외 판매를 계획 중이라면 나중에 재설계를 강제하지 않는 체크아웃 접근을 선택하세요.
온사이트에서의 무결점 체크아웃이 얼마나 중요한지 결정하세요.
이 선택은 전환율, 브랜딩, 신뢰에 영향을 줍니다. 어떤 고객층은 친숙한 "지갑 스타일" 옵션을 선호하고, 다른 고객층은 표준 카드 폼을 기대합니다.
속도와 커스터마이즈의 균형에 솔직해지세요:
실용 팁: 업데이트를 누가 담당할지(당신, 개발자, 웹사이트 빌더/플러그인) 결정하세요. 유지보수 용이성에 큰 영향을 줍니다.
이 네 가지를 문장으로 요약할 수 있으면 Stripe와 PayPal을 비교할 준비가 된 것입니다.
Stripe와 PayPal은 둘 다 온라인 결제를 허용하지만 일상 사용감은 다릅니다. Stripe는 사이트에 자연스럽게 녹아드는 유연한 결제 플랫폼으로 생각하고, PayPal은 고객에게 이미 친숙한 지갑 브랜드로 생각하세요.
브랜드와 일체화되는 깔끔하고 커스터마이즈 가능한 체크아웃을 원하는 비즈니스에서 인기입니다. 여러 결제 수단을 제공하거나 구독, 송장, 리포팅 같은 다른 도구와 결합해 확장하려는 경우 특히 강력합니다.
빠르게 론칭할 수 있고 지갑 기반 체크아웃을 제공하는 점으로 알려져 있습니다. 많은 쇼핑객은 PayPal 잔액이나 연결된 은행/카드로 별도 입력 없이 결제할 수 있습니다. 일부 고객에게는 PayPal 버튼 자체가 신뢰 신호로 작용합니다.
실무적으로 Stripe는 "내 체크아웃"처럼 느껴지는 반면 PayPal은 고객이 선택하는 친숙한 별도 옵션처럼 느껴집니다.
많은 사이트는 카드 결제엔 Stripe를 쓰고 PayPal은 추가 버튼으로 둡니다. 다양한 연령대나 국제 고객을 상대한다면 한 가지로 강제하지 않고 마찰을 줄이는 좋은 방법입니다.
Stripe나 PayPal 설정은 단순한 계정 생성이 아닙니다. 금융 서비스 관계를 여는 일이므로 사업자 정보, 판매 상품, 정산 방식 등을 확인하기 위해 여러 정보를 요구합니다.
Stripe 계정 생성은 빠르지만 인증 단계에서 시간이 걸릴 수 있습니다. 보통 기본 사업 정보(법적 명칭, 주소, 세무 정보 등)와 정산용 은행 계좌를 제출해야 합니다.
Stripe 대시보드에서 주로 사용하는 항목:
소유자 신원 확인이나 추가 서류를 요청받을 수 있습니다.
PayPal은 보통 PayPal 비즈니스 계정으로 시작합니다. 제한을 해제하고 원활히 처리하려면 다음을 확인하세요:
PayPal은 분쟁 및 판매자 보호 규정을 강조하므로 가입 후 계정 제한과 알림을 확인하세요.
많은 비즈니스는 첫 결제를 같은 날 받을 수 있습니다 — 특히 PayPal이 빠른 편입니다. Stripe도 빠르지만 걸리는 시간은 비즈니스 유형, 국가, 거래량, 인증 서류 제출 속도에 따라 달라집니다.
불일치한 사업자 정보, 은행 계좌 인증 문제, 누락된 신원 문서, 제한된 상품 카테고리 등이 지연을 초래합니다. 문서를 미리 준비하고 이름/주소를 정확히 입력하면 며칠의 시간을 절약할 수 있습니다.
체크아웃은 방문자가 실제로 결제할지 말지를 결정하는 곳입니다. Stripe와 PayPal 모두 카드를 처리할 수 있지만, 결제 수행 방식(어디에서 결제하는지)이 신뢰도·속도·전환율에 큰 영향을 줍니다 — 특히 모바일에서 그렇습니다.
호스티드 체크아웃은 고객을 Stripe나 PayPal이 관리하는 결제 페이지로 보냅니다. 보통 설정이 빠르고 유지보수가 적습니다.
임베디드/온사이트 체크아웃은 고객이 사이트를 떠나지 않고 결제 정보를 입력하게 합니다. 더 매끄럽지만 구현 작업과 예외 처리, 업데이트 책임이 늘어납니다.
한마디로:
Stripe Checkout은 Stripe의 호스티드 체크아웃 페이지입니다. 로고/색상 등으로 스타일링할 수 있고 모바일에서 주소 자동완성, 저장된 결제 수단 같은 기능을 제공합니다. 자체적으로 모든 것을 만들기 부담스러울 때 흔히 선택됩니다.
Stripe Payment Links는 공유 가능한 URL로 호스티드 체크아웃을 엽니다. 단일 상품, 서비스, 인보이스, 소셜 판매 등 간단한 판매 시 유용합니다.
PayPal Smart Buttons는 상품이나 장바구니 페이지에 표시되어 고객이 PayPal 계정(또는 설정에 따라 카드)을 이용해 결제하게 합니다. 장점은 익숙함과 신뢰성입니다.
PayPal Checkout은 PayPal 인증 과정을 거친 뒤 결제가 확정되는 PayPal 브랜드 플로우를 말합니다. 카드 정보를 사이트에 입력할 필요가 없어 타이핑을 줄일 수 있습니다.
모바일에서는 작은 마찰도 큰 이탈로 이어집니다. 빠르고 읽기 쉬우며 불필요한 계정 생성 요구가 없는 체크아웃이 보통 전환이 좋습니다.
중요 포인트:
확신이 없다면 호스티드 체크아웃(Stripe Checkout 또는 PayPal Checkout)으로 빠르게 론칭한 뒤, 고객의 행동을 보고 필요하면 온사이트로 옮기세요.
웹사이트, 체크아웃, 백엔드 이 모두를 동시에 개발 중이라면 Koder.ai 같은 비브 코딩(vibe-coding) 플랫폼이 빠른 배포에 도움이 될 수 있습니다: 채팅으로 플로우를 설명하면 React 프런트엔드와 Go + PostgreSQL 백엔드를 생성하고 웹후크, 주문 상태, 확인 이메일 등을 반복해서 개선할 수 있습니다.
수수료는 결제 활성화 후 가장 놀라는 항목 중 하나입니다 — 숨기기 때문이 아니라 실제 비용은 고객이 어떻게 결제하는지에 따라 달라지기 때문입니다.
비교할 때 같은 카테고리를 맞춰보세요:
또한 즉시 정산, 고급 사기 방지 도구, 소액결제 요율 같은 "추가 항목"도 총비용에 영향을 미칠 수 있습니다.
요금은 국가, 카드 유형(직불 vs 신용, 리워드 카드), 결제 수단(카드 vs 월렛 vs 은행 이체)에 따라 달라집니다. 예: 미국 내 직불카드 위주 상점과 국제 판매가 많은 고가 주문 상점은 비용 구조가 완전히 다릅니다.
평균 주문금액(AOV)과 결제 수단 비율로 시작하세요.
예: AOV가 $50이고 제공업체가 2.9% + $0.30을 부과하면 기본 처리 비용은:
여기에 20%의 주문이 국제 거래로 +1% 비용이 든다면(20% × $50 × 1% = $0.10) 평균 비용에 추가합니다. 환불, 차지백, 통화 변환도 고려하세요.
온라인 결제를 받는다는 건 카드 데이터를 안전하게 다루는 것을 의미합니다 — 비록 당신이 카드 번호를 직접 보지 않더라도요. 좋은 소식은 Stripe와 PayPal이 특히 호스티드 체크아웃을 사용할 경우 많은 무거운 작업을 처리해준다는 점입니다.
PCI DSS는 카드 네트워크가 만든 보안 규칙 모음입니다. 요지는: "카드 정보를 안전하지 않게 저장하거나 노출하지 않는다는 것을 증명"하는 것입니다. 결제 정보를 어떻게 수집하느냐에 따라 의무가 달라집니다.
고객이 Stripe Checkout이나 PayPal Checkout에서 카드 정보를 입력하면 민감한 데이터는 제공업체 시스템에 머물러 귀하의 PCI 범위가 줄어듭니다. 이 경우 간단한 자기평가로 충분한 경우가 많습니다.
커스텀 카드 폼을 사이트에 직접 구축하면 준수 부담이 커집니다. 더 많은 결제 흐름이 귀하의 서버와 페이지를 거치기 때문입니다.
두 제공업체는 사기 방지와 실패 결제 감소를 위한 도구를 제공합니다:
호스티드 체크아웃을 써도 기본적인 사이트 보안은 귀하 책임입니다:
환불과 분쟁은 결제 운영의 일부입니다 — 무엇이 정상인지, 비용은 어떤지, 어떻게 예방할 수 있는지 이해하면 도움이 됩니다.
전액 환불은 전체 구매 금액을 되돌려줍니다. 부분 환불은 일부만 반환합니다(반품, 가격 조정, "상품 유지 + 할인" 상황에 유용).
타임라인: 대시보드에서 즉시 환불을 발행할 수 있지만 고객 은행은 환불을 계좌에 반영하는 데 5–10영업일(또는 카드/국가에 따라 더 길게) 걸립니다.
중요: 일부 프로세서는 환불 시 원래 부과된 처리 수수료를 반환하지 않을 수 있으니 정책을 확인하세요.
차지백은 고객이 자신의 발급사에 요금 취소를 요청하는 경우입니다. 흔한 원인:
차지백에 대응하려면 보통 다음 증빙이 필요합니다:
Stripe와 PayPal은 모두 분쟁 워크플로를 제공하지만 일상적 경험은 다를 수 있습니다. 비교할 때 살펴볼 점:
고객이 PayPal 지갑으로 결제하는 경우 PayPal의 Resolution Center를 통해 처리해야 할 수도 있습니다. 카드 결제(종종 Stripe 사용)는 카드 네트워크 규칙을 따릅니다.
/support 같은 경로)잘 처리하면 환불은 단순한 고객 서비스지만 분쟁은 시간과 비용을 소모합니다 — 그래서 예방이 최고의 전략입니다.
정기 결제는 결제 도구가 단순한 "사이트 버튼"이 아니라 갱신, 플랜 변경, 결제 실패, 고객 기대 관리를 다루는 시스템처럼 느껴지게 합니다.
Stripe Subscriptions는 제품과 가격(보통 플랜이라고 부름)을 중심으로 설계되어 있습니다. 월별/연별 과금, 사용량 기반 청구, 인보이스/영수증 자동 발송 등을 설정할 수 있습니다.
핵심 개념은 비례정산(proration) 입니다: 사이클 중간에 업그레이드하면 Stripe가 차액을 자동 청구하거나 크레딧을 적용할 수 있습니다. 계층형 멤버십과 SaaS 업그레이드에 유용합니다.
Stripe는 실패 카드 재시도, 던잉(dunning) 이메일, 세금 옵션(설정에 따라), 고객 셀프서비스 포털 같은 일반적인 구독 플로우도 처리합니다.
PayPal도 구독 기능과 버튼 기반 플로우를 통해 정기 과금을 지원합니다. PayPal 잔액으로 결제하길 선호하는 고객이 많은 경우 적합할 수 있습니다.
다만 지역/계정 유형에 따라 플랜 변경 방식, 비례정산 지원 여부, 고객의 업데이트/취소 흐름이 달라질 수 있으니 사전에 확인하세요.
무료 체험, 쿠폰/할인, 또는 인보이스(특히 B2B용)는 사전에 요구사항을 매핑하세요. 일부 비즈니스는 VAT/세금 필드가 포함된 다운로드 가능한 인보이스, 구매 주문 참조, 또는 은행 이체용 수동 인보이스가 필요합니다.
다중 요금제, 잦은 업그레이드/다운그레이드, 인보이스·비례정산에 대한 더 많은 제어가 필요하면 Stripe가 보통 수월합니다. 고객층이 PayPal을 강하게 선호하고 플랜이 단순하다면 PayPal 구독도 충분할 수 있으나, 엣지 케이스를 런칭 전에 확인하세요.
해외 판매에서 중요한 실무 질문 세 가지는: 고객이 어떤 통화로 결제할 수 있는지, 당신이 어떤 통화로 정산받을지, 그리고 자금이 은행에 얼마나 빨리 도착하는지입니다.
둘 다 많은 통화를 지원하지만 사람들을 놀라게 하는 세부는 정산 통화입니다.
Stripe는 여러 통화로 가격을 표시할 수 있으며, 사업자 위치에 따라 하나(또는 때로는 여러) 정산 통화로 받을 수 있습니다. 청구한 통화가 정산 통화와 다르면 Stripe가 환전(환전 수수료 적용)합니다.
PayPal은 고객이 여러 통화로 결제할 수 있고 계정 내 다중 통화 잔액을 보유할 수 있습니다. 출금 시나 거래 완료 시 PayPal이 변환을 수행할 수 있습니다.
실용 팁: 1–2개의 기본 통화를 정하고 다른 통화는 마진이 여유 있을 때만 부가적으로 제공하세요.
Stripe 정산은 보통 자동 스케줄(일간/주간 등)로 이루어지며 국가와 리스크 히스토리에 따라 지연이 있습니다. 자금은 연결된 은행 계좌로 바로 갑니다.
PayPal은 잔액에 돈이 빠르게 표시되는 느낌을 주지만, 이를 은행으로 옮기는 데는 인출 방식과 표준 이체 시간에 따라 추가 시간이 필요합니다(즉시 이체는 비용이 들 수 있음).
어떤 것이 중요한지 결정하세요: "지금 당장 잔고에 보이는 돈"(PayPal 잔액) vs "예측 가능한 은행 입금"(정기적 정산).
두 도구 모두 세금을 대신 처리해주진 않습니다. 회계사와 협의하세요:
론칭 전에 회계 구조를 계획하세요:
약간의 구조화가 첫 세무 신고나 분쟁 검토 시 많은 시간을 절약합니다.
최종 선택은 브랜드 이름보다는 체크아웃의 느낌, 판매 품목, 제어 필요성에 달려 있습니다. 다음은 결정을 쉽게 해주는 일반적 시나리오입니다.
결제 요구가 성장할 것으로 예상하고 체크아웃을 세밀하게 맞추고 싶다면 Stripe를 선택하세요.
고객이 PayPal을 이미 신뢰하고 선호한다면 PayPal이 빠른 승리 요인일 수 있습니다.
가능하면 **Stripe(카드/Apple Pay/Google Pay)**와 PayPal을 함께 제공하면 전환율이 올라갑니다. 고객이 익숙한 옵션을 직접 선택하게 하세요.
헤드라인 처리 수수료만으로 결정하는 것이 가장 큰 실수입니다. 수수료는 카드 유형, 국가, 환불, 차지백, 통화 변환에 따라 달라지므로 실제로는 종종 달라집니다.
또한 보이지 않는 비용(엉성한 체크아웃으로 인한 전환 감소, 제한적인 구독 도구로 인한 수동 작업 증가)을 고려하세요. 확실하지 않다면 오늘의 체크아웃 요구에 가장 잘 맞는 옵션으로 시작하되, 6개월 후에 막히지 않도록 확장 가능성도 따져보세요.
"카드를 받습니다"라고 알리기 전에 빠르게 점검하세요. 작은 설정 문제(누락된 웹후크, 혼란스러운 오류 메시지, 전송되지 않는 이메일) 때문에 결제 흐름이 실패하는 경우가 많습니다.
Stripe와 PayPal은 테스트 환경(“샌드박스” 또는 “테스트 모드”)을 제공하므로 실거래 없이 시나리오를 시뮬레이션하세요. 확인할 것:
웹후크에 의존한다면(Stripe Checkout 등) 이벤트가 수신되고 처리되는지 테스트하세요 — 많은 론칭 실패는 여기서 발생합니다.
실제 모드로 전환한 뒤에는 엔드투엔드 고객 경험을 다시 확인하세요:
드랍오프 포인트를 파악할 수 있게 기본 측정 설정을 하세요:
설정(계정, 키, 웹후크, 환불 절차)을 문서화해 향후 변경이 결제에 문제를 일으키지 않게 하세요. 그다음 30일 후 리뷰를 스케줄하세요: 수수료, 전환율, 체크아웃 마찰을 다시 보고 가격이나 UX를 조정하세요.
론칭 후 반복을 원활히 하려면 결제 흐름을 버전 관리하고 롤백할 수 있게 설계하세요. 예를 들어 Koder.ai는 스냅샷과 롤백, 소스 코드 내보내기를 지원해 체크아웃 UX, 웹후크 처리, 구독 로직을 조정할 때 안전한 복원 경로를 제공합니다.
일반적으로 세 가지를 설정하는 것입니다:
단순히 "버튼을 추가"하는 것이 아니라 고객이 어떻게 결제하고 돈이 은행으로 어떻게 도달할지 결정하는 과정입니다.
결제 프로세서는 카드 네트워크와 은행을 통해 돈을 이동시키는 역할을 합니다.
결제 게이트웨이는 결제 정보를 안전하게 전달하고 승인/거부 결과를 반환합니다.
체크아웃은 고객이 결제하는 고객용 페이지나 폼입니다.
현대의 많은 제공업체는 프로세서와 게이트웨이를 번들로 제공하므로 실제로는 어떤 체크아웃 경험을 운영할지 선택하는 것이 가장 큰 결정이 됩니다.
Stripe는 주로 카드 처리 + 게이트웨이 계층으로 사용되며 호스티드 또는 임베디드 등 유연한 체크아웃 옵션을 제공합니다.
PayPal은 주로 지갑 결제 수단(PayPal 버튼/플로우)으로 알려져 있고, 일부 지역에서는 카드 처리 기능도 제공합니다.
실무적으로는 Stripe가 "자신의" 체크아웃처럼 느껴지는 반면 PayPal은 고객이 추가로 선택하는 친숙한 옵션처럼 느껴집니다.
우선 다음을 제공하는 것이 일반적입니다:
어떤 조합을 제공할지는 고객의 위치, 사용 기기(모바일 vs 데스크톱), 그리고 제공업체 계정에서 지원하는 기능에 달려 있습니다.
호스티드 체크아웃은 Stripe나 PayPal이 관리하는 결제 페이지로 고객을 보냅니다(때로는 팝업 형태). 보통 빠르게 론칭하고 유지보수가 적습니다.
임베디드/온사이트 체크아웃은 고객이 사이트에 머물면서 결제 정보를 입력하게 합니다. 더 매끄럽게 느껴질 수 있지만 구현 작업과 예외 처리가 더 많이 필요합니다.
요약:
일반적으로 빠르게 시작하려면 호스티드를, 브랜드 일체화가 중요하면 임베디드를 선택하세요.
많은 경우에 그렇습니다. 일반적인 설정은:
두 가지를 함께 제공하면 특히 국제 고객이나 연령대가 섞여 있는 대상에서 전환율을 올리는 데 도움이 됩니다.
두 제공업체 모두 일반적으로 다음을 요구합니다:
지연의 대부분은 이름/주소 불일치, 누락된 서류, 또는 제한된 상품 카테고리 때문입니다. 서류를 미리 준비하고 정보를 일관되게 입력하면 수일의 시간을 절약할 수 있습니다.
헤드라인 요금만 보지 말고 다음을 비교하세요:
실용적인 방법은 **평균 주문금액(AOV)**과 국내/국제 결제 비율을 가정해 총비용을 추정하는 것입니다.
고객이 Stripe Checkout이나 PayPal Checkout(호스티드)에서 카드 정보를 입력하면 민감한 카드 데이터는 그들의 시스템에 남게 되어 보통 상점의 PCI 범위가 줄어듭니다.
하지만 다음은 여전히 책임입니다:
환불은 일반적으로 대시보드에서 쉽게 처리할 수 있지만 고객의 은행처리로 인해 5–10 영업일(또는 그 이상)이 걸릴 수 있습니다.
차지백/분쟁은 더 많은 작업이 필요하며, 다음과 같은 증빙이 필요합니다:
분쟁을 줄이려면 청구명세서(descriptor)를 명확히 하고, 체크아웃 근처와 확인 이메일에 반품/배송 정책을 표시하며, 추적 정보를 빠르게 발송하세요. 또한 고객이 쉽게 연락할 수 있게 해두면 도움이 됩니다 (예: 상대 경로 ).
또한 가능한 경우 3D Secure와 기본적인 사기 방지 도구를 활성화하는 것을 고려하세요.
/support