시스템개발읽기 6분소제목 11

결제 시스템 상태값 정의 기준: 학회·행사 등록비 도메인 설계

핵심 요약 학회 및 행사 등록비 결제 시스템 개발 시 데이터 무결성을 보장하고 PG사 연동에 대비하기 위한 결제 시스템 상태값 정의 기준과 상태 전이 설계 가이드를 확인해 보세요. 결제 상태값(ENUM) 정의 및 PG사 응답 코드 매핑 전략 [비교] 단순 상태 저장 vs 상태 전이(Transition) 정책 및 DB 테이

결제 시스템 상태값 정의 기준: 학회·행사 등록비 도메인 설계
핵심 요약

학회 및 행사 등록비 결제 시스템 개발 시 데이터 무결성을 보장하고 PG사 연동에 대비하기 위한 결제 시스템 상태값 정의 기준과 상태 전이 설계 가이드를 확인해 보세요.

  • 결제 상태값(ENUM) 정의 및 PG사 응답 코드 매핑 전략
  • [비교] 단순 상태 저장 vs 상태 전이(Transition) 정책 및 DB 테이블 설계
판단 포인트등록·결제·체크인 데이터가 한 흐름으로 이어지는지 먼저 확인하세요.

결제 상태값(ENUM) 정의 및 PG사 응답 코드 매핑 전략

홍커뮤니케이션 MICE 포트폴리오 현장 레퍼런스 40
홍커뮤니케이션 MICE 포트폴리오 현장 레퍼런스 40

행사 당일 접수대 앞에서 참가자가 "이미 결제했는데 완료 처리가 안 돼 있다"고 항의하는 상황을 상상해 보자. 신용카드 결제라면 승인 즉시 확인이 가능하지만, 가상계좌의 경우 발급 시점과 실제 입금 시점 사이에 반드시 시차가 생긴다. 이때 결제 상태값이 "성공/실패" 이분법으로만 설계되어 있으면, 운영자는 현장에서 참가자에게 현재 상태를 설명할 길이 없다.

e-Regi 플랫폼이 지원하는 결제 수단을 나열해 보면, 설계의 복잡도가 한눈에 보인다. - 신용카드·카카오페이·네이버페이: 결제 승인 응답 즉시 상태 확정

  • 가상계좌: 발급 후 실제 입금이 확인되어야 최종 완료 판정
  • 계좌이체: 즉시 처리가 원칙이나 PG사 응답 지연 대비 필요

이 차이를 무시하고 "결제 완료"라는 단일 상태를 쓰면, 가상계좌 발급 직후에 참가자에게 QR 바우처가 담긴 알림톡이 발송되는 불상사가 생길 수 있다. 따라서 최소한 아래 구조를 가져야 한다.

[비교] 단순 상태 저장 vs 상태 전이(Transition) 정책 및 DB 테이블 설계

행사 마스터 컨트롤러 통합 운영 시스템
행사 마스터 컨트롤러 통합 운영 시스템

학생회원이 조기등록 마감일을 넘겨 결제를 시도하다가 오류가 발생했다고 가정해 봅시다. 관리자가 단순히 결제 칼럼 값을 '완료'로 바꿔주면 끝일까요? 이때 시스템은 이것이 정상적인 조기등록 요금인지, 학생회원 할인이 적용된 금액인지 스스로 검증할 수 있어야 합니다. 결제 데이터의 무결성은 단순히 DB 칼럼의 값을 덮어쓰는 것만으로는 절대 보장되지 않습니다.

단순 저장과 상태 전이 정책의 차이

결제 로직을 설계할 때는 단순히 상태를 기록할 것인지, 엄격한 상태 전이(Transition) 규칙을 적용할 것인지 기준을 명확히 해야 합니다.

비교 항목단순 상태 저장 방식상태 전이 정책 적용 방식
상태 변경 권한관리자나 시스템이 임의로 상태 변경 가능허용된 흐름도(예: 대기→완료) 외의 전이는 강제 차단
오결제 방지 로직금액 검증 없이 상태만 업데이트하여 오류 발생 위험결제 확정 전 주문 요금과 실제 입금액 정합성 검증
중복결제 처리동일한 결제 요청이 여러 건 저장될 가능성 높음고유한 결제 참조값으로 중복 트랜잭션 원천 차단
트랜잭션 롤백부분 실패 시 이전 데이터가 남아 불일치 발생결제 실패 시 트랜잭션 단위로 원자성 보장 및 복구

조기등록 할인과 회원 등급을 매핑하는 정규화

브라우저 종료 및 가상계좌 만료 대응: 고아(Orphan) 주문 스케줄러 구축

홍커뮤니케이션 MICE 포트폴리오 현장 레퍼런스 20
홍커뮤니케이션 MICE 포트폴리오 현장 레퍼런스 20

결제창을 띄워놓고 브라우저를 닫거나, 카카오페이 화면에서 이탈하는 참가자는 결제 운영에서 가장 흔한 예외 케이스다. 주문 레코드는 결제 대기로 생성되어 있지만 실제 결제는 일어나지 않은 — 이른바 고아(Orphan) 주문이 남는다. 방치하면 실시간 대시보드의 결제 통계가 부풀려지고, 행사 종료 후 내보내는 엑셀 보고서까지 오염된다.

즉시 결제 수단: 고아 주문 자동 취소

신용카드, 카카오페이, 네이버페이 등 즉시 승인 방식에서는 PG사(NICEPAY·토스페이먼츠) 응답이 돌아오지 않은 주문을 스케줄러가 주기적으로 스캔해야 한다.

  • 스캔 조건: 결제 대기 상태 + 생성 후 특정 시간 경과
  • 상태 전이: 결제 대기자동 취소
  • 후속 처리: 자동 취소된 주문은 실시간 대시보드 집계에서 제외

기준 시간을 너무 짧게 잡으면 정상 결제 중인 참가자의 주문까지 취소되고, 너무 길면 대시보드에 유령 주문이 오래 남는다. 결제창 평균 체류 시간과 PG사 응답 지연을 감안해 실행 주기와 기준 시간을 분리해 설정하는 것이 핵심이다.

가상계좌: 입금 기한 만료 배치

가상계좌는 카드 결제와 메커니즘이 근본적으로 다르다. 발급 시점부터 입금 기한이 존재하며, 기한 내 입금이 확인되지 않으면 별도의 상태 전이가 필요하다.

운영자 수동 상태 변경 권한 및 Audit Log(변경 이력) 추적 설계

홍커뮤니케이션 MICE 포트폴리오 현장 레퍼런스 48
홍커뮤니케이션 MICE 포트폴리오 현장 레퍼런스 48

현장에서 상태값을 손으로 바꿔야 하는 순간

행사 당일, 가장 많이 터지는 구간이다. 무통장입금자가 몰려오고, PG사가 일시적으로 응답을 안 하는 사이 참가자가 접수대 앞에 줄을 서기 시작한다. 이때 운영자가 관리자 페이지에서 결제 상태를 수동으로 바꿔줄 수 없으면, 행사 전체가 멈춘다.

그래서 수동 상태 변경 권한은 현장 운영의 필수 안전장치다. 하지만 권한을 열어두는 순간 발생하는 문제가 더 크다.

권한 없는 다중 사용자가 상태를 바꿀 때 일어나는 일

담당자 A는 입금 확인을 했지만, B가 같은 건을 다시 결제 완료로 돌리고, C가 환불 처리를 누르는 식의 충돌이 생긴다. 가장 흔한 실수는 권한 제어 없이 여러 계정이 자유롭게 상태값을 변경하도록 두는 것이다.

결제 상태값 ENUM이 아무리 정교하게 설계돼 있어도, 수동 변경 경로에 통제가 없으면 결제 데이터의 신뢰성이 순식간에 무너진다.

항목통제 없는 수동 변경Audit Log 기반 수동 변경
변경 권한다수 계정 자유 변경지정된 권한 보유자만
변경 이력남지 않거나 부분 기록변경자·전후 상태·시간 전수 기록
충돌 처리중복·누락 발생선행 변경 건은 후속 변경자에게 표시
사후 추적추적 불가, 책임 불분명로그 기반 원인 파악 가능

결제 취소·환불 시 명찰 발급 명단 동기화 트랜잭션 및 요약 체크리스트

학회 현장 모바일 디지털 명찰 시스템 화면
학회 현장 모바일 디지털 명찰 시스템 화면

현장 접수대에서 가장 당황스러운 순간은 결제를 취소한 참가자의 명단이 여전히 발권 대상에 남아있을 때입니다. 취소된 참가자가 모바일 QR 바우처를 스캔하거나 명찰를 출력하려 하면, 단순한 시스템 오류를 넘어 행사 운영의 신뢰도에 큰 타격을 줍니다.

이러한 사고를 막으려면 결제 취소·환불 같은 역방향 상태값 변경이 발생할 때, 하위 시스템의 데이터를 하나의 트랜잭션으로 묶어 처리해야 합니다.

데이터 처리 항목정상 결제 승인 시 (정방향)결제 취소 및 환불 시 (역방향)
QR 모바일 바우처즉시 생성 및 알림톡 발송바우처 권한 회수 및 활성화 정지
명찰 발급 명단관리자 대시보드에 실시간 반영발권 대상 명단에서 즉시 제거
참가 현황 통계결제 완료 건수 가산참가 확정 인원 및 출결률 데이터에서 차감
#결제 시스템 상태값 정의#결제 상태 전이 설계#PG사 연동#가상계좌 입금 확인#데이터 무결성#고아 주문 스케줄러

함께 읽으면 좋은 글