ADR-DS-065_발행자 PG 연결 및 등록 정책

ADR-DS-065_발행자 PG 연결 및 등록 정책

1. 기본 정보

Conforms to: ADR-DS-000 v1 Effective from: ADR-DS-060+ If conflict: ADR-DS-000 wins. Deprecated terms in this scope: arrived, checkin/check_in.

  • ADR ID: ADR-DS-065
  • 제목: 발행자 PG 연결 및 등록 정책
  • 상태: Accepted
  • 작성일: 2026-03-07
  • 작성자: YSY

관련 ADR

  • ADR-DS-060 : 선결제 기능 도입
  • ADR-DS-061 : 결제 중 슬롯 임시 확보 정책
  • ADR-DS-062 : PG 리다이렉트 결제 확인 정책
  • ADR-DS-063 : 선결제 픽업 슬롯 운영 정책
  • ADR-DS-064 : 슬롯 수량 관리 및 동시성 제어 정책

2. 배경 (Context)

플랫폼은 발행자 직접 결제 구조를 채택한다.

결제 구조는 다음과 같다.

사용자
→ 발행자 PG 결제
→ 발행자 계좌 정산

플랫폼은 다음 기능을 수행하지 않는다.

결제 수령
정산 관리
거래 중개

플랫폼은 단지

슬롯 노출
예약 관리
결제 상태 반영
사용 처리

만 수행한다.

따라서 선결제 기능을 사용하려면 발행자가 자체 PG(Payment Gateway)를 보유해야 한다.


3. 결정 (Decision)

플랫폼은 발행자 PG 연결 방식을 채택한다.

선결제 슬롯은 PG가 연결된 발행자만 사용 가능하다.


4. PG 연결 조건

발행자가 선결제 기능을 사용하려면 다음 조건을 충족해야 한다.

사업자 등록
온라인 PG 계약
결제 리다이렉트 URL 설정 가능

오프라인 카드 단말기 보유 여부는 PG 연결 여부와 무관하다.

토스 카드 단말기
POS 단말기
FaceID 결제 단말기

위 장비는 온라인 PG를 의미하지 않는다.


5. 지원 PG

플랫폼은 특정 PG를 강제하지 않는다.

단, 다음 조건을 충족해야 한다.

웹 결제창 제공
결제 완료 후 redirect 지원
결제 결과 검증 가능

발행자 가이드에서는 다음 PG를 추천한다.

추천 PG 예

  • Toss Payments
  • KG Inicis
  • NHN KCP

추천 기준

소상공인 가입 용이성
결제창 안정성
간편결제 지원

6. 발행자 PG 등록 절차

발행자가 PG를 확보하는 일반적인 절차는 다음과 같다.

6.1 PG 선택

발행자는 원하는 PG를 선택한다.

추천

Toss Payments

6.2 PG 가입

PG 사이트에서 사업자 회원가입을 진행한다.

입력 정보

사업자등록번호
상호
대표자
사업장 주소
업종

6.3 정산 계좌 등록

정산 계좌를 등록한다.

대표자 계좌
또는
법인 계좌

해당 계좌로 결제 금액이 정산된다.


6.4 서류 제출

PG 심사를 위해 다음 서류를 제출한다.

사업자등록증
대표자 신분증
통장 사본

6.5 PG 심사

PG는 다음 정보를 검증한다.

사업자 실존 여부
업종
정산 계좌

심사 기간

1~3일

6.6 Merchant ID 발급

심사 완료 후 PG는 다음 정보를 발급한다.

Merchant ID (MID)
API Key
Secret Key

MID = merchant_123456

7. 플랫폼 PG 등록

PG 연결 이후 발행자는 플랫폼에 PG 정보를 등록한다.

발행자 설정 화면

PG 종류
Merchant ID
결제 Redirect URL
Webhook URL (선택)

플랫폼 DB 저장 정보

publisher_id
pg_type
pg_mid
pg_redirect_url
pg_api_key_ref
pg_secret_key_ref
pg_webhook_secret_ref (선택)

*_key_ref는 원문 키를 저장하지 않고 시크릿 스토리지 참조값만 저장한다.

플랫폼은 발행자 키 원문을 로그/화면에 노출하지 않는다.


8. 결제 요청 구조

플랫폼은 결제 라우팅에 필요한 식별 정보만 전달한다. 결제 결과 확정/검증 절차는 ADR-DS-062를 따른다.

플랫폼이 결제를 요청할 때 기본적으로 다음 정보가 PG로 전달된다.

order_id
reservation_id
amount
return_url

결제 흐름

슬롯 선택
→ PG 결제창 이동
→ 결제 진행
→ PG → 플랫폼 redirect/webhook
→ 서버 검증
→ reservation 상태 반영

9. 선결제 기능 사용 조건

PG 연결은 선결제 기능 활성화의 필수 조건이다. 플랜 노출/판매 정책 자체는 Product 정책 문서를 단일 원천으로 따른다.


10. 결과 (Consequences)

긍정적 영향

플랫폼 정산 시스템 불필요
결제 리스크 최소화
구독 기반 수익 모델 유지

제한 사항

발행자 PG 가입 필요
PG 이해도 필요
초기 온보딩 안내 필요

따라서 발행자 가이드 문서 제공이 필수적이다.


11. 구조적 의미

본 정책은 플랫폼의 핵심 철학을 유지하기 위한 결정이다.

플랫폼은

거래 플랫폼

이 아니라

시간 슬롯 인프라

이다.

따라서 결제 구조는 다음 원칙을 따른다.

결제 책임 = 발행자
시간 관리 = 플랫폼


Template v2 Addendum

In Scope

  • Prepaid slot operations (reservation, payment confirmation, pickup, quantity, PG connection)

Out of Scope

  • Order brokering, settlement handling, refund amount calculation

Boundaries

  • Payment responsibility is on publisher. Time/state management is on platform.

Source of Truth (SoT)

  • Base: ADR-DS-060; Temporary hold: ADR-DS-061; Payment verification/reconcile: ADR-DS-062; Pickup ops: ADR-DS-063; Quantity/concurrency: ADR-DS-064; PG registration/secret handling: ADR-DS-065.

Validation

  • Detect state/constraint violations via tests and batch checks.
  • Recovery and reprocessing must be idempotent.

Revisit Conditions

  • KPI threshold breach (reservation failure, expiry ratio, payment confirmation failure)
  • External dependency change (PG, regulation, location API)

DS-000 v1 정합성 개정 (2026-03-08)

이 문서는 ADR-DS-000 v1에 정합되도록 다음 규칙을 우선 적용한다.

  1. Reservation 상태 집합은 reserved | redeemed | expired | cancelled만 사용한다.
  2. paid, payment_failed, no_show는 Reservation 상태로 사용하지 않는다.
  3. 결제 중 임시 점유는 Reservation 상태가 아니라 hold 도메인으로 분리한다.
  4. 수량 차감은 reserved -> redeemed 전이 트랜잭션에서만 수행한다.
  5. prepaid + verification_method=none은 결제 성공 시 즉시 redeemed 전이를 허용할 수 있다.
  6. prepaid + (location|qr)는 결제 성공 후 검증 성공 시 redeemed로 전이한다.
  7. 만료 시각은 운영 상한을 강제한다: expires_at <= store_close_at.

본 섹션과 기존 본문이 충돌하면 본 섹션(DS-000 정합성 개정)이 우선한다.