인앱 결제(In-App Purchase, IAP)

출처: https://www.donga.com/news/amp/all/20210927/109443475/1

모바일 서비스에서 ‘어떻게 돈을 벌지’는 기획의 핵심 과제이다.

인앱 결제(IAP)는 단순 결제 기능이 아니라 비즈니스 모델·UX·서버 아키텍처·정책 준수·운영 프로세스가 모두 맞물려 돌아가는 시스템이다.

---

1. 요약: 핵심 개념 한 문장

인앱 결제(IAP)는 앱 내부에서 디지털 상품(소모성·비소모성·구독 등)을 유료로 제공하고, 플랫폼(Apple/Google)의 결제 인프라를 통해 거래·검증·정산을 수행하는 서비스이다.

앱스토어 규정·플랫폼 가이드를 반드시 따라야 한다.

---

2. 기획 관점에서 상품 타입 분류

• 소모성(Consumable): 충전 재화, 포인트 등 — 재구매 유도 핵심
• 비소모성(Non-consumable): 광고 제거, 영구 기능 해제 — 복원(restore) 기능 필수
• 구독(Subscription): 주기적 과금(월/년) — 무료체험, 프로모션, 갱신 정책 기재 필요
• 패키지/번들: 한정판·묶음 상품 — 한시적 판매 전략

각 상품은 SKU, 플랫폼 SKU ID, 가격(지역별), 환불·복원 정책, 제공 권한(플랫폼·서버상) 표기한 상품 시트로 정리가 필요하다.

---

3. 플랫폼 규정

• Apple (App Store): 디지털 상품/구독은 기본적으로 App Store 인앱 결제(IAP)를 사용해야 한다. 상세 정책·심사 가이드는 Apple 공식 문서에서 확인한다. (정책은 수시로 변경되므로 배포 전 최신 가이드 재확인 필수)
• Google (Play): Play Billing 라이브러리를 통해 결제 연동해야 하며, 서버 연동(Subscriptions & Purchases API)으로 상태 관리를 권장한다.  

주의: 플랫폼 수수료·정책·지역 규제(예: EU DMA 등)로 인해 외부 결제 허용/제한이 계속 변하고 있다. 운영 전에 최신 공지·뉴스를 확인이 필요하다.  

---

4. 권장 아키텍처

1) 클라이언트(앱)

• 상품 목록 조회(플랫폼과 동기화된 가격/설명)
• 결제 UI(스토어 결제창 호출)
• 결제 완료 시 영수증/토큰을 앱 → 서버 전송

2) 서버(백엔드)

• 플랫폼(Apple/Google)으로 receipt/token 검증(서버 검증 필수)
• 구매 기록·구독 상태(DB) 보관 및 권한(엔터티) 발급/회수
• 웹훅/서버 알림 수신(플랫폼에서 보내는 상태 변경 통지 처리)
• 환불/차지백/복원 시 자동화된 대응 로직

3. 운영·분석

• 구매 로그·에러 로그·환불 로그 집계 대시보드
• 이벤트 추적: view_product, begin_checkout, purchase_success, purchase_failed, restore_purchases 등

---

5. 서버 검증(Receipt / Purchases 검증) — 왜 반드시 서버에서 검증해야 하는가

클라이언트만 신뢰하면 조작(위조 영수증)이 가능하므로 서버에서 플랫폼(Apple/Google)에 직접 영수증·토큰을 검증해야 한다.

Apple은 App Store Server API/receipt validation 가이드를 제공하며, Google은 purchases API(Subscriptions/Products)를 통해 상태를 조회한다.  

간단한 서버 검증 흐름(의사코드)

1. 앱 → 서버: {user_id, sku, platform, receiptData}
2. 서버: platform에 따라 검증 API 호출
Apple: App Store Server API → transaction 상태 확인
Google: purchases.products / purchases.subscriptions → 상태 확인
3. 검증 결과가 정상이면 DB에 저장(구매 시각·transaction_id·expiry 등)
4. 사용자 권한(콘텐츠, 아이템) 부여
5. 실패/환불 시 권한 회수 로직 수행

(세부 구현은 플랫폼 문서 및 보안 권장사항을 따르세요.)

---

6. UX 설계(결제 흐름)

• 결제 전 화면(요약): 항목별 가격, 세금(노출 필요 시), 총액, 환불/복원·자동갱신 안내(구독) 명확 표기
• CTA 버튼: Primary(주문) 버튼은 하단 고정, 텍스트에 가격 포함(예: “지금 결제하기 — ₩3,900”)
• 결제 실패/대기 처리: 네트워크 문제 발생 시 단계별 안내와 재시도 버튼 제공
• 구독 안내 문구: “자동 갱신 여부, 해지 방법(설정→구독관리), 무료 체험 이후 과금 시점” 명확 표기
• 비소모성 복원 버튼: “구매 복원/Restore Purchases” 항목을 설정 메뉴에 항시 노출
• 영수증/주문 확인: 구매 직후 영수증(거래ID) 또는 주문확인 화면 및 고객센터 연동

* 예시 카피

• 결제 버튼: “지금 구매하기 — ₩3,900”
• 구독 설명: “첫 7일 무료 체험, 체험 종료 후 자동으로 월 ₩4,900가 청구됩니다. 구독은 언제든지 설정에서 취소할 수 있습니다.”
• 실패 메시지: “결제에 실패했습니다. 네트워크를 확인하거나 결제 수단을 변경해 주세요.”

---

7. 가격·프로모션 설계 (예시)

• 심리 가격(End-digit pricing): 4,900원 vs 5,000원 테스트
• Intro & Promo: 첫 결제 할인(Intro price), 시간 한정 번들로 ARPU 실험
• 구독 패키지: 월 vs 연 할인(예: 연간 20% 할인)
• 프리미엄 트라이얼 관리: trial → trial expiry 알림(48시간·24시간 전)로 전환 유도

---

8. QA / 테스트 체크리스트

1. 샌드박스 결제(Apple sandbox / Google license testing) 정상 동작 확인
2. 구매 성공 시 서버 검증, DB 저장, 권한 발급 확인
3. 구매 실패/네트워크 단절 → 적절한 오류 메시지 및 재시도 가능 여부
4. 환불/차지백 발생 시 권한 회수 절차 테스트
5. 비소모성 복원(restore) 케이스 검증(다른 기기 포함)
6. 구독 갱신/취소/무료체험→유료 전환 시나리오 검증
7. 동시 트랜잭션·중복 결제 방지 로직 확인
8. 로그·알림(운영자용) 정상 수신 확인

---

9. 운영(고객지원) 프로세스

• 고객 문의 폼 항목: 사용자 ID, 거래ID(플랫폼 거래ID), 결제일, 결제화면 스크린샷(있다면)
• 환불 안내: “플랫폼(Apple/Google) 규정에 따라 처리됩니다. 지원에 필요한 경우 주문ID를 제출해 주세요.”
• 환불 후 처리: 플랫폼 영수증 재검증 → DB 상태 갱신 → 권한 회수 후 고객 알림

---

10. 보안·사기 대응 포인트

• Receipt/Token 검증은 서버에서만 수행(클라이언트 검증은 보조)
• 비정상 거래 탐지: 동일 IP·짧은 시간 다결제·동일 카드 반복 사용 등 룰 적용
• 민감 키(플랫폼 서비스 계정 키)는 Secret Manager에 보관(환경변수에 평문 저장 금지)
• 로그 보관 및 모니터링으로 차지백·환불 급증 조기감지

---

11. 운영 중 자주 마주치는 문제와 권장 대응

• 외부 결제 안내 문제: 플랫폼 정책 위반 경고 가능 — 문구·링크 사용 전 정책 확인
• 구독 갱신 실패(카드 만료): 결제 업데이트 요청 이메일·푸시 발송, grace period 운영 검토
• 차지백/환불 급증: 자동 차단 룰, 고객지원 스크립트 표준화, Fraud 분석 팀 연계

---

12. 참고(정책·기술)

• Apple App Store Review Guidelines (Business / Payments 섹션)
• Apple: Validating receipts with the App Store (서버 검증 권장 가이드)
• Google: Integrate the Google Play Billing Library / Subscriptions & Purchases API
• Google Play Service fees(수수료 정책) — Play Console Help
• 최신 정책·법률 변동(예: EU DMA 등)은 운영 이슈가 발생할 수 있으니 관련 뉴스·공지를 주기적으로 확인 필수

---

13. 마무리

1. 정책을 먼저 확인: 플랫폼 정책 위반은 앱 심사 거부나 수익 차단으로 직결된다.
2. 서버 검증을 반드시 구현: 클라이언트만의 검증으로는 보안·사기 문제에서 자유로울 수 없다.  
3. 측정·실험을 설계: 가격·카피·타이밍은 실험을 통해 최적값을 찾아야 한다.
4. 운영 프로세스를 자동화: 환불·차지백·구독 상태 변화 처리 자동화가 운영 리스크를 줄인다.