학회·학술대회 등록비 결제 시스템에서 중복 등록과 이중결제를 방지하는 검증 규칙을 소개합니다. 동일인 판별 기준, PG 멱등성 키, 무통장 매칭 등 서버·DB 기반 구현 방법을 단계별로 정리했습니다.
- 왜 중복 결제가 발생하는가 — 결론부터: 프론트 검증만으론 안 됩니다
- 1단계 — 동일인 판별 기준 설계: 이름·이메일·휴대폰번호·회원번호 조합
왜 중복 결제가 발생하는가 — 결론부터: 프론트 검증만으론 안 됩니다
결론부터 말씀드리면, 중복 결제는 브라우저가 아니라 서버와 데이터베이스에서 막아야 합니다. 프론트 검증은 참가자를 위한 편의 장치일 뿐, 사고를 막는 방어선이 아닙니다.
사고는 이런 순서로 시작됩니다
- 연타와 새로고침: 조기등록 할인이 마감으로 달아오르면 참가자는 결제 버튼을 연타하고, 응답이 늦으면 새로고침을 누릅니다. 서버 입장에서는 서로 다른 요청 두 개라 같은 등록이 두 건 생깁니다.
- PG 콜백 재호출: 카드사·PG 사정으로 승인 결과 통지가 재시도되면, 결제는 한 번인데 시스템에 두 번 반영될 수 있습니다.
- 무통장 오매입: 입금자명이 잘못 들어오면 실시간 연동되는 가상계좌라도 어느 등록 건의 입금인지 매칭이 꼬입니다.
가장 먼저 드러나는 신호는 바우처 중복 발송입니다. 접수 완료 즉시 QR 바우처가 카카오 알림톡으로 자동 발송되는 구조라면 등록이 두 건일 때 알림톡도 두 통 가고, 운영팀이 확인하기 전에 참가자 문의가 먼저 도착합니다.
프론트 검증과 서버·DB 검증의 차이
자바스크립트 중복 클릭 방지는 새로고침이나 모바일 재접속으로 초기화되고, alert 안내는 지키는 사람을 위한 안내일 뿐입니다. 게다가 등록 오픈 직후 트래픽이 몰리는 순간이 정확히 중복 제출이 터지는 순간인데, 프론트는 그때의 서버 지연을 통제하지 못합니다.
1단계 — 동일인 판별 기준 설계: 이름·이메일·휴대폰번호·회원번호 조합
접수가 몰리는 마감 무렵, 사무국에 이런 문의가 들어옵니다. "같은 분 결제 내역이 두 건인데 취소해야 하나요?" 개인 이메일로 한 건, 연구실 공용 메일로 한 건. 이름은 같은데 이메일이 달라서 시스템이 서로 다른 인원으로 처리해버린 겁니다. 동일인 판별 기준이 흔들리면 이렇게 환불 문의까지 이어집니다.
이메일 단독 판별이 무너지는 지점
- 공유 이메일: 연구실·부서 공용 메일로 여러 명이 접수하면, 서로 다른 사람이 같은 이메일을 씁
2단계 — 참가유형별 정책과 PG 멱등성 키·무통장 매칭 규칙
결제가 "새로 되는" 사고는 대부분 두 지점에서 터집니다. 첫째는 정책 설계에서 같은 것을 두 번 살 수 있게 열어둔 경우, 둘째는 PG사 콜백이 두 번 도착하거나 참가자가 결제 완료 화면을 새로고침하는 순간입니다. 이 단계에서는 이 둘을 따로 잡아야 합니다.
참가유형별 정책 — "복수 신청 허용, 동일 유형 차단"
학술대회에서는 한 명이 본학술대회 + 워크숍을 함께 신청하는 게 정상적인 케이스입니다. 이걸 아무 조건 없이 막아버리면 오히려 민원이 생깁니다. 반대로 본학술대회를 두 번 결제하는 건 무조건 이상 신호죠. 그래서 정책은 이렇게 나눠 세우는 게 안전합니다.
- 허용: 동일 참가자(회원증번호 기준)의 서로 다른 참가유형 조합
- 차단: 동일 참가유형 + 동일 회차에 대한 두 번째 결제 시도
- 조건부 허용: 취소·환불 완료 이력이 있으면 같은 유형 재신청 가능
3단계 — 선착순 마감·동시 접수 상황의 동시 등록 방지 처리
선착순 마감 5분 전, 무슨 일이 벌어지나
요. 남은 자리 2석. 그런데 마감 직전 수백 명이 동시에 '결제하기' 버튼을 누르면 어떻게 될까요? 단순한 시스템이라면 그 순간 접수된 요청을 전부 승인해 버립니다. 결제는 성공했는데 정원은 초과됐고, 운영자는 환불 처리와 항의 응대에 매몰됩니다.
이 문제의 뿌리는 "정원 확인"과 "등록 확정" 사이의 시간 차입니다. 두 단계 사이에 다른 사람의 결제가 끼어들 수 있는 구조라면 언제든 초과접수는 발생합니다. 그래서 설계는 '확인 후 저장'이 아니라 '확인과 저장을 원자적으로 묶기'에서 출발해야 합니다.
기술적 방어선 두 겹: 유니크 제약 + 트랜잭션 락
| 항목 | 흔한 실수 (앱 로직만 사용) | 권장 구조 (DB까지 방어) |
|---|---|---|
| 정원 검사 | 앱 코드에서 남은 자리 조회 후 저장 | 트랜잭션 락으로 조회~확정 구간 잠금 |
| 중복 등록 | 폼에서 '이미 신청됨' 안내만 | DB 유니크 제약으로 동일 참가자 중복 저장 자체를 차단 |
| 동시 요청 처리 | 먼저 도착한 순서 무작위 | 대기열로 순서 보장, 정원 도달 시 즉시 마감 |
| 초과 발견 시점 | 결제 완료 후 수동 발견 | 등록 확정 단계에서 원천 차단 |
4단계 — 중복 발견 후 사후 정리·환불 프로세스와 사무국 체크리스트
4단계 — 중복 발견 후 사후 정리·환불 프로세스와 사무국 체크리스트
아무리 앞단에서 정규화, 유니크 제약, 멱등성 키로 막아도, 무통장 입금 지연이나 참가자의 재결제 시도로 중복 결제는 어느 정도는 발생합니다. 중요한 건 '안 생기게'만 하는 게 아니라, 생겼을 때 누가, 무엇을 기준으로, 몇 분 안에 정리하는지 미리 정해두는 겁니다.
e-Regi처럼 접수 완료 즉시 QR 코드가 담긴 모바일 바우처를 카카오 알림톡으로 자동 발송하는 흐름에서는, 중복 접수가 단순히 결제 문제로 끝나지 않습니다. 참가자 폰에 QR 바우처가 2개 떠 있게 되고, 현장에서는 어떤 바우처를 보여줄지 혼란이 생기죠. 다행히 QR 출결 시스템은 동일 QR 재사용을 실시간으로 차단하고, 스캔 3초 이내 입장 처리와 입·퇴장 시간 자동 기록까지 하니까 '한 명이 두 번 입장'하는 사고 자체는 막힙니다. 그런데 참가자 명단·평점 기록은 여전히 2줄로 남아요. 현장 체크인은 막혀도 **데이터 정리는 사람이 해야 합니다.