프론티아 글로벌 — 결제·정산 PRD

글로벌 유저가 스타를 충전하는 결제 채널·다통화·결제 데이터 저장과, 한국 디렉터가 글로벌 매출을 받는 정산을 다룬다. 유저의 마켓·국가·언어 판정, 통화 표시 포맷 자체는 각각 가입·온보딩 & 글로벌 토대 / UI 현지화 PRD 소관이다.

---

Status: draft Created: 2026-07-03 Last updated: 2026-07-03 대상 표면: 앱 / 웹 / 어드민

이 문서의 표기

• 마켓 코드: 콘텐츠 마켓 7개(NA·JP·KR·TW·LATAM·BR·ID). 마켓에 매핑되지 않은 나머지 국가(태국·베트남 등)는 NA로 매핑된다(별도 'ROW' 구분 없음). 전체 정의는 가입·온보딩 & 글로벌 토대 PRD.
• 결제 용어: 인앱 결제=앱 스토어를 통한 결제 · 결제 국가=결제가 발생한 스토어·결제사의 국가(예: 미국 스토어) · MoR=세금·환불 책임을 지는 판매 주체 · 정산 기준점=디렉터 정산을 계산하는 기준(유저가 소비한 1크레딧 = 1원).
• 되돌리기 비용 등급(R): R1=쉬움(UI/문구) · R2=중간(결제 플로우 재작업) · R3=비쌈(스키마·데이터 재이전, 계약·세무·정산 정합).
• 표시 약속: 검토 필요=아직 정해지지 않음(§7) · 후속=출시 후 디테일 패스.

---

Reversal Risk Summary

레이어	R등급	점검 초점
정책 / 규칙	R3	웹 결제 채널(Stripe vs 앱 유도)·MoR 아님(해외 세금 직접 부담)·정산을 한국 디렉터로 한정하는 정책은 계약·세무·정산 신뢰에 닿음
데이터 / 백엔드	R3	결제에 결제 국가·통화를 저장하는 일은 소급 불가(저장 안 한 거래는 영원히 복원 불가) → 출시 전 픽스
유저 대면 화면	R2	웹 결제 진입점·앱 유도·다통화 표시는 되돌릴 수 있으나 결제 플로우 재작업
문구 / 시각 표현	R1	통화 포맷은 UI 현지화 소관, 조정 쉬움

---

1. 목표 및 배경

1.1 목표

• 프론티아 사용자 층을 넓히는 확장의 일부로, 글로벌 유저가 자기 마켓에서 스타를 결제할 수 있게 하고, 한국 디렉터가 글로벌 매출을 정산받게 한다. 그리고 그 결제의 국가·통화를 저장해 세무·매출 분석의 토대를 만든다.

1.2 배경 (현황)

• 현재 결제는 한국 전용이다 — 웹 결제는 토스페이먼츠(국내), 앱은 인앱 결제, 통화는 원화 단일이다. 글로벌 유저가 스토어에서 외화로 충전은 되지만 그 거래의 결제 국가·통화가 기록에 저장되지 않는다.
• NA는 웹 비중이 높은데 글로벌 웹 결제 경로가 없다. 한국 디렉터는 글로벌 크레딧 소비로 이미 정산받지만, 결제 국가·통화가 안 남아 세무·분석을 할 수 없다.
• 미국·일본·한국 모두 웹·외부 결제 유도를 합법화했다 → 웹 결제(수수료 5~9%)와 앱 인앱 결제(30%)의 마진 격차가 크다.

1.3 접근

• 앱 인앱 결제를 글로벌 메인 채널로 둔다(특히 일본·대만·홍콩 — 스토어 계정이 편의점·통신사 청구를 흡수). 신규 결제부터 결제 국가·통화를 저장한다.
• 웹 결제는 두 모델 중 택1(분기점 = Stripe 온보딩): A. Stripe 국제 웹 결제 / B. 앱 유도(웹 결제 안 만들고 앱 다운로드 유도). 국내는 토스 유지.
• MoR가 아니라 해외 세금을 직접 부담한다(초기 감내). 콘텐츠를 성인 암시 선까지로 유지해 메인스트림 결제사 수용 범위에 둔다.
• 정산은 한국 디렉터만 받는다(정산 구조가 주민번호·한국계좌를 요구해 구조적으로 한국인 전용). 한국 디렉터는 글로벌 유저의 크레딧 소비로 이미 자동 정산된다(기준점 = 1크레딧=1원, 통화 변환 없음). 결제 국가·통화 저장은 세무·감사·분석용이다.

---

2. 타깃 사용자

2.1 주요 사용자

• 글로벌 결제자(전 마켓): 스타 충전(앱 인앱 결제·웹 결제), 웰컴·첫결제·웹 패키지 이벤트 구매, 유료 턴·선톡 소비. (웹 결제 검증 집중 = NA, 앱 IAP 메인 = JP/TW/HK 등.)
• 한국 디렉터(정산 대상): 글로벌 크레딧 소비로 자동 정산.
• 어드민/운영: 결제·환불 관리, 정산 명세.

2.2 핵심 시나리오

1. NA 유저가 웹에서 스타 패키지를 결제(모델 A=Stripe)하고 즉시 스타가 적립된다.
2. JP 유저가 앱 인앱 결제로 충전하면 결제 국가=일본·통화=엔이 결제 기록에 저장된다.
3. 한국 디렉터의 영어판 에피소드가 NA에서 플레이돼 유저가 크레딧을 소비하면, 그 소비가 정산 기준점(1크레딧=1원)으로 디렉터 정산에 자동 반영된다(결제 통화 무관).

---

3. 핵심 기능 요구사항

3.1 클라이언트 (앱/웹)

스타 충전 — 앱 인앱 결제

• 동작: 유저가 스토어 인앱 결제로 스타 패키지를 충전한다(글로벌 메인 채널).
• 비즈니스 룰:
  • 가입 국가별 스토어에서 결제 → 스토어 기본 가격대로 현지 환율이 자동 적용된다(1차 동일 상품). 같은 상품이라도 스토어 국가별로 상품 식별자·가격이 다를 수 있으며, 이 다른 가격 설정은 이미 지원된다.
  • 결제 검증·적립은 기존과 동일(같은 거래 1회만 적립).
  • 신규: 결제 완료 시 결제 국가·통화를 결제 기록에 저장(§3.3).

스타 충전 — 웹 결제

• 동작: 유저가 웹에서 스타를 충전한다.
• 비즈니스 룰:
  • 국내(한국): 토스페이먼츠 유지.
  • 국제(모델 A): Stripe 결제(카드·Apple Pay). 국제(모델 B 폴백): 웹 결제 미제공 — "앱에서 결제" 안내 + 앱 다운로드 유도. Stripe 온보딩이 거절되면 자동으로 모델 B로 폴백한다.
  • 웹 국가 판정은 토대 PRD의 IP 판정을 가져다 쓴다.

상품 / 가격 표시 (다통화)

• 동작: 유저에게 자기 마켓 통화로 가격을 보여준다.
• 비즈니스 룰:
  • 본 PRD는 **가격 틀(무엇을 가격 기준으로 삼는가)**만 정한다. 실제 가격 값(마켓·상품별 금액)은 별도 가격 문서에서 결정한다(본 PRD 범위 밖).
  • 가격 기준(SoT)은 채널별로 다르다 — 앱 IAP = 스토어 콘솔에 등록한 현지 가격(마켓·국가별 티어, 스토어 자동 환율)이 청구 기준이고, 서버 상품 카탈로그는 "상품 → 지급 스타 수량" 매핑을 맡는다. 웹 = 서버가 정한 가격(서버 권위, 주문 금액과 결제 승인액 일치 검증). 어느 쪽이든 실제 금액 값은 위 가격 문서에서 정한다.
  • ⚠️ 현행 코드는 서버 카탈로그의 단일 원화(KRW) 값을 결제 기록에 남기고 스토어 영수증의 실제 통화·국가·청구액을 버린다 → 글로벌은 영수증의 결제 국가·통화·청구액을 채택·저장하도록 바꾼다(§3.3), 통화도 원화 단일에서 다통화로 확장한다.
  • 1차 동일 상품 + 스토어 기본 가격대. 구매력 평가 가격 최적화·현지 프로모션은 2차. 통화 포맷(기호·자릿수)은 UI 현지화 소관.

웰컴스타 · 첫결제 · 웹 패키지 이벤트 (글로벌화)

• 비즈니스 룰:
  • 웰컴스타: 기기 식별자 + 계정 기준 1회 지급·만료 유지(기기 기준 누수는 1차 용인). 마켓 판정은 토대 PRD가 제공.
  • 비-KR 무료 스타 탭 미노출: 상점의 "무료 스타" 탭(일일미션 등 무료재화 획득 경로)은 비-KR 마켓 유저에게 노출하지 않는다(반복 누수원 차단, 해외 본인인증 불필요). 웰컴스타(위)는 별개로 지급. 마켓 판정은 토대 PRD가 제공.
  • 첫결제 웰컴패키지: 가입 후 자격 기간은 정확한 가입 시각 기준. 앱 인앱 결제 전용(기존).
  • 웹 패키지 이벤트: 글로벌 웹 채널에서 제공(모델 A일 때 Stripe, 모델 B일 때 미제공). 품목별 계정당 1회 제한 유지.

유료 턴 · 선톡 소비

• 비즈니스 룰: 잔액·차감 로직 동일, 가격대는 글로벌 동일 상품. 유료 턴 소비 기록이 정산 기준점이다(§3.3).

비-KR 유저에게 정산은 "준비중"

• 동작: 정산은 한국 디렉터 전용이라, 비-KR 유저에게는 정산 관련 진입점을 "준비중"으로 표시하거나 차단한다. 글로벌 유저에게 미제공 기능이 활성처럼 보이지 않게 한다.

3.2 어드민

결제·환불 운영

• 결제 조회/상태, 환불(어드민 직접 환불 = 토스 결제만, 기존 유지), 환불 어뷰저 목록/해제, 상품 운영.
• 신규: 결제 목록·상세에 결제 국가·통화·마켓 표시·필터. 모델 A일 때 Stripe 결제 출처 가시화.

정산 운영

• 정산 명세·환율·서버비·출금 운영(기존). 정산 대상 = 한국 디렉터만(구조적).
• 신규: 정산 명세에 결제 대행사 구분(인앱/Stripe/토스) + 외화 매출 출처 가시화(한국인 전용 정산임을 명시).
• 1차 정산은 환율 변환 없음(크레딧 소비 기준점). 현행 월별 환율(통화쌍, API 비용 환산용)은 유지.

3.3 백엔드 / 시스템

• 결제 국가·통화 저장 (신규, 소급 불가):
  • 신규 결제부터 결제 기록에 결제 국가·통화·실제 청구액을 저장한다. 앱 인앱 결제는 스토어 영수증의 결제 국가·통화, 웹은 결제사 통화·결제국.
  • ⚠️ 현행 IAP 검증은 영수증의 productId만 신뢰하고 영수증에 있는 결제 국가·통화·청구액을 쓰지 않고 버린다 → 이를 채택해 저장하도록 확장한다(결제 기록 통화는 지금 원화 enum 단일, 결제 국가 필드는 없음).
  • 지원 통화에 달러·엔·대만달러(+홍콩달러 검토) 추가. 결제 대행사에 (모델 A일 때) Stripe 추가.
  • 과거 거래는 저장돼 있지 않아 소급 복원 불가 → 외화 집계는 신규 거래부터.
• 환불 회수: 결제 대행사별(토스/앱스토어/구글 + 모델 A일 때 Stripe), 마켓 무관 동일 정책(원 적립량 기준 회수, 통화 무관).
• 정산 (크레딧 소비 기준점):
  • 정산 기준점 = 크레딧 소비(유료 턴, 1크레딧=1원) — 기존 그대로. 글로벌 크레딧 소비도 동일 경로로 자동 정산되며 통화 변환 없다. 매출을 통화별로 재집계하는 정산은 2차.
  • 정산 대상 = 한국 디렉터만(주민번호·한국계좌 구조로 자연 강제). 글로벌 외화 매출은 한국 디렉터에게 귀속된다(해외 결제 국가 매출 ≠ 해외 디렉터). 해외 디렉터 정산 기능 자체가 없다.

3.4 딥링크 / URL

• 기존 스타 상점 경로 재사용. 모델 B(앱 유도)는 상점 진입 시 앱 다운로드/딥링크 유도. 웹 결제 콜백 경로(Stripe 복귀)는 구현 시 확정.

3.5 Scope

포함 (In scope)

• 앱 인앱 결제 글로벌(결제 국가·통화 저장).
• 국제 웹 결제 모델 A(Stripe) / 모델 B(앱 유도 폴백), 국내 토스 유지.
• 다통화 가격 표시(클라 기준) + 지원 통화 확장.
• 웰컴스타·첫결제·웹 패키지 이벤트 글로벌화.
• 환불 회수 Stripe 확장(마켓 무관).
• 한국 디렉터 글로벌 매출 정산 = 크레딧 소비 기준점 자동. 비-KR 정산 "준비중" 표시.

제외 (Out of scope) — 인접 문서 경계

항목	소관
유저 마켓·국가·언어 판정, IP 위치, 마켓 필터	가입·온보딩 & 글로벌 토대
통화 포맷·가격 표시 문구	UI 현지화
구매 이벤트 마켓 속성 코호트 분석	각 PRD 로깅 / 토대 PRD 규칙
구매력 평가 가격 최적화·현지 프로모션, JP/TW/HK 현지 결제수단, MoR 전환, 매출-통화별 재집계 정산	2차
해외 디렉터 정산(기능 자체 없음)	본 PRD 밖

---

4. 에러 처리 및 예외 상황

상황	처리 방향
Stripe 온보딩 거절	자동 모델 B(앱 유도)로 폴백, 웹 "앱에서 결제" 안내
웹 결제 실패/취소	재시도 가능, 중복 청구 없이 멱등 재개
미지원 통화·결제 국가	결제 차단 + 안내, 결제 국가는 원값 그대로 저장
환불 후 잔액 부족	기존 회수 흐름 → 부족분 환불 어뷰저 등록(마켓 무관)
비-KR 유저의 정산 진입	"준비중" 표시 또는 차단

---

5. 데이터 분석

• 기존 결제 이벤트에 글로벌 속성을 추가한다: payment_country(결제 스토어프론트 국가)·payment_currency·user_market. 결제 완료·충전 진입·환불 이벤트가 대상.
• 신규 결제 결제 국가 채움률(데이터 품질 게이트)을 모니터한다. 속성 규칙 원본은 토대 PRD.

---

6. Ubiquitous Language

유저 마켓·국가·언어 등 토대 용어는 토대 PRD 용어표가 기준이다. 결제 고유 용어(결제 국가·정산 기준점·MoR)는 §표기 "결제 용어"에서 정의했으므로 별도 표를 두지 않는다.

---

7. 검토 필요 (미결정 항목·외부 의존)

• [ ] Stripe 온보딩(외부 의존) — 딥그로브 한국법인이 Stripe를 쓸 수 있는지 + 성인 암시 콘텐츠·가상재화(스타) 심사 통과 여부. 웹 결제 모델 A/B 분기점. (담당: PM/외부 영업)
• [ ] 결제 국가·통화 저장(소급 불가) — 출시 전 스키마 픽스 필수. (담당: 엔지니어/PM)
• [ ] 해외 세금 직접 부담 — 웹 결제(우리가 판매자)만 해당. 주로 미국 판매세·일본 소비세. 1차는 대부분 면세 기준선 아래라 초기 감내, 규모 확대가 MoR 전환 트리거. (담당: PM/세무사 확인)
• [ ] 지원 통화 확장(홍콩달러 여부) · 앱 인앱 결제 결제 국가 추출 경로 · 매출-통화별 재집계 정산(2차) · 결제 검증 추상화 도구 도입 여부. (담당: 엔지니어)

---

부록: 메타 정보

Required artifacts

• Spec — 웹 결제 플로우·다통화 표시·정산 어드민은 spec/디자인 단계에서 세부화.
• Design — 유저 대면 웹 결제 화면(Stripe 진입·앱 유도) + **비-KR 정산 "준비중" 상태/빈 화면(가벼운 디자인)**은 디자인 필요. 정산 어드민은 백엔드 직접 구현.
• Migration plan — 본문 §3.3에 포함(결제 국가·통화 컬럼, 통화·대행사 확장, 소급 불가). 별도 파일 아님.

Size & Risks

• Size: L / Confidence: medium — 결제 채널 신규(Stripe)·다통화 스키마 + 외부 의존(Stripe 온보딩) 불확실성. 모델 A/B 분기로 범위 가변.
• 위험: ①Stripe 온보딩 거절 → 모델 B 폴백(웹 결제 0) ②결제 국가 미저장 거래 소급 불가 ③해외 세금 복잡도.
• 의존: 가입·온보딩 & 글로벌 토대(결제 국가·마켓·IP 판정, 선행). UI 현지화(통화 포맷).

References

• 코드 근거(As-is): frontia-api 결제 스키마에 결제 국가 컬럼 없음, 통화 원화 단일, 결제 대행사 3종(Stripe 없음). 정산 신청 구조가 주민번호·한국계좌 요구.
• 유사 서비스: 단일 한국법인의 Stripe 글로벌 웹 결제 라이브 운영 선례.
• 결정 로그 원문: CLAUDE.md §8.