AI로 결제 추가: Stripe 개요
결제 코드는 '되는 것처럼 보이는' 것만으론 안 된다. 초보자가 알아야 할 핵심: 호스팅 체크아웃, webhook이 기준, 프런트에 맡기면 안 되는 것.
한 문장으로
금액·성공 여부·이중 결제 모두 정확해야 한다. 결제의 핵심 부품과 '결제 성공'을 백엔드 webhook으로 판단하는 이유를 다룬다.
만들 결과물
결제의 핵심 부품(Checkout·webhook·대사)을 이해하고, 프런트에 맡기면 안 되는 판단이 무엇인지 알게 된다.
결제는 생각보다 복잡하다
일반 기능을 틀리면 화면이 좀 이상할 뿐이지만, 결제를 틀리면 진짜 돈이 깨집니다—금액 오류, 결제했는데 활성화 안 됨, 더블클릭 이중 청구. 그래서 '되는 것처럼 보인다'로는 한참 부족합니다. 좋은 소식은 신용카드를 직접 다룰 필요가 없다는 것. 가장 어려운 부분은 Stripe 같은 결제 사업자에게 맡깁니다.
가장 편한 길: 호스팅 체크아웃(Checkout)
Stripe가 체크아웃 페이지를 제공(Hosted Checkout)하고, 사용자는 Stripe의 페이지에서 카드를 입력해 결제한 뒤 내 사이트로 돌아옵니다. 이렇게 하면 카드 번호가 내 서버를 전혀 거치지 않아 가장 번거로운 PCI 준수를 피할 수 있습니다. 초보자는 거의 여기서 시작해야 합니다.
핵심: 결제 성공은 프런트가 아니라 webhook으로 판단
가장 흔하고 가장 위험한 실수: '사용자가 성공 페이지로 돌아왔으니 상품을 활성화'. 실제로 결제 안 했거나 중간에 닫았을 수 있습니다. 신뢰할 신호는 Stripe가 백엔드로 보내는 webhook 이벤트입니다. 흐름:
빼면 안 되는 세 가지
- webhook 서명 검증 + eventId 중복 제거: 이벤트가 정말 Stripe에서 왔는지(서명), 같은 이벤트는 한 번만 처리(eventId 기록으로 재전송에 의한 이중 활성화 방지).
- 멱등성(idempotency): 같은 결제 요청 재전송은 같은 결과여야 하며 이중 청구하지 않습니다. Stripe에 idempotency key 메커니즘이 있습니다.
- 카드 번호를 직접 저장하지 않기: 카드는 Stripe에 맡기고 돌려받은 id만 저장. 직접 저장은 거대한 준수·유출 위험.
Stripe는 거래당 수수료 방식으로 월 최소 금액은 없지만 청구마다 수수료가 붙습니다—출시 전 요율을 확인하세요.
AI에게 이렇게 말하세요
요구할 것: Stripe 호스팅 Checkout 사용, 활성화 로직은 webhook에(서명 검증 + eventId 중복 제거), 멱등성 추가, 결제 성공을 프런트에서 판단하지 않기, 카드 번호 직접 저장 안 하기. 이를 인수 기준으로 삼지 않으면 '프런트가 결제됐다고 했으니 활성화'라는 위험한 버전을 받기 쉽습니다.
다음 단계
- 먼저 계정/권한을 정비: AI로 로그인 시스템 만들기
- 주문/결제 데이터 설계: AI로 데이터베이스 설계하기
자주 묻는 질문
초보자가 결제를 넣어도 안전한가요? 신용카드 준수(PCI)에 걸리나요?
Stripe의 호스팅 체크아웃이면 비교적 안전합니다. 카드는 Stripe 페이지에서 입력되어 당신 서버를 전혀 거치지 않고, 카드를 저장하지 않으며, 가장 무거운 PCI 준수는 Stripe가 집니다. 초보자는 자체 카드 입력란을 만들지 말고 호스팅부터 시작하세요.
왜 프런트의 ‘성공 페이지’로 상품을 활성화하면 안 되나요?
성공 페이지에 도착했다고 결제가 된 건 아니기 때문입니다—중간 취소, 연결 끊김, 심지어 그 페이지 위조도 가능합니다. 신뢰할 유일한 신호는 Stripe가 백엔드로 보내는 webhook 이벤트(서명 검증 + 중복 제거)입니다. 프런트 성공 페이지는 UI 표시일 뿐 활성화 근거가 될 수 없습니다.
참고 자료
- Stripe Documentation — Stripe
- Stripe Payments — Stripe
SaaS 경로 다음 단계: 랜딩에서 SaaS로 →