주문 유실 문제 관련 기술 검토 요청 건

2026-07-14 (화) 23:11:25 162

안녕하세요 담당자님
저희는 YoungCart를 통해 독립 쇼핑 플랫폼을 구축하여 운영중입니다 .

금년 4월쯤부터 저희 플랫폼에서 발생하는 주문 건 중 일부가 정상적으로 접수되지 않고 유실되는 사례가 지속적으로 확인되고 있습니다. 이에 따라 주문 누락 및 고객 서비스 차질이 우려되어 해당 문제에 대한 정확한 원인 파악과 신속한 조치가 필요한 상황입니다.

이와 관련하여

  1. 현재 시스템 중 주문 처리 프로세스의 어느 부분에서 취약점이 발생하고 있는지

  2. 주문 유실 문제를 해결하기 위해 어떠한 방식으로 수정 또는 보완이 필요한지

에 대해 기술 검토를 요청드립니다.

가능하신 대로 해당 내용을 확인하신 후  회신을 부탁드립니다.

감사합니다

|

답변 6개 / 댓글 3개

혹시 PG사가 어디이실까요?
일반적인 메이저PG사가 아닌경우 가끔 유실이 발생합니다

해당 부분에 대해서 보완해본 경험이 있는데, 간단히 설명드리기 어려운부분이라 쪽지주시면 말씀드리곘습니다
 

답변에 대한 댓글 2개

2026-08-02 (일) 11:18:42
안녕하세요
답변 해주셔서 감사드립니다
저희 KG이니시스 결제서비스 사용하고 있습니다 감사합니다
원인에 대해서는 좀더 분석해봐야할것같고, 주문 전 후 모두 저장하고 비교해봐야할것같네요. 일반적인 방법으론 해결이 힘들것같습니다.
영카트 기본 주문 흐름은 PG 승인과 주문·장바구니·쿠폰·포인트 등의 DB 변경이 하나의 원자적 작업으로 묶여 있지 않습니다. 따라서 결제 승인 후 PHP 오류, DB 오류, 타임아웃 등이 발생하면 “PG 결제는 완료됐지만 g5_shop_order에는 주문이 없는” 불일치가 생길 수 있습니다.

먼저 누락 건을 다음처럼 분류해야 합니다.

1. PG 승인내역도 없고 g5_shop_order에도 없음: 결제창 이탈, 네트워크/프론트 오류 또는 세션 유실 가능성
2. PG 승인은 있는데 g5_shop_order에 없음: shop/orderformupdate.php의 승인 이후 주문 INSERT·장바구니 상태 변경 구간 문제
3. g5_shop_order에는 있는데 관리자에서 안 보임: 주문 상태·검색 필터 또는 커스텀 조회 문제
4. PG 승인 후 자동취소됨: 주문 저장 검증 실패와 PG 취소 처리 내역 확인

보완하려면 아래 두 가지를 함께 적용하는 것이 좋습니다.

1. 주문 DB 처리에 트랜잭션 추가

주문, 장바구니 상태, 쿠폰, 포인트, 재고 등 서로 연관된 DB 변경을 하나의 트랜잭션으로 묶고, 전부 성공할 때만 COMMIT, 하나라도 실패하면 ROLLBACK 해야 합니다. 다만 실제 운영 테이블이 MyISAM이면 트랜잭션이 동작하지 않으므로 g5_shop_order, g5_shop_cart 및 함께 갱신되는 관련 테이블의 스토리지 엔진을 먼저 확인하고, 백업·호환성 검증 후 InnoDB로 전환해야 합니다.

PG 승인 요청처럼 외부 네트워크 호출을 긴 DB 트랜잭션 안에 넣는 것은 피해야 합니다. PG 승인 후 수행하는 로컬 DB 변경만 짧은 트랜잭션으로 묶고, DB COMMIT이 실패하면 이미 승인된 결제는 별도의 취소 대기 상태로 남겨 재시도하거나 PG 취소를 수행해야 합니다. od_id와 PG 거래번호(TID)에는 중복 처리를 막는 유일성·멱등성 검사도 필요합니다.

2. 중간 결제 상태를 DB에 영구 저장

PG 결제창으로 이동하기 전 결제 시도 레코드를 먼저 만들고, 다음과 같은 상태값으로 갱신하는 별도 결제 원장을 두는 방식이 안전합니다.

INIT → APPROVAL_REQUESTED → APPROVED_PENDING_ORDER → ORDER_COMMITTED
실패 시 CANCEL_PENDING → CANCELLED 또는 ERROR

최소한 내부 결제시도 ID(correlation ID), od_id 후보값, 장바구니 ID, PG사, 결제수단, 요청금액, PG TID, 상태, 오류코드·메시지, 생성·수정시각, 재시도 횟수를 저장해야 합니다. 브라우저 리턴뿐 아니라 PG 서버 통보가 있다면 동일 ID로 멱등하게 갱신해야 합니다.

g5_shop_order_post_log는 장애 분석에는 유용하지만 성공 로그가 정리되고 기본 코드상 보관기간도 짧아 영구적인 중간 결제 원장으로는 부족합니다. 별도 결제 상태 테이블을 기준으로 PG 승인 건과 g5_shop_order를 주기적으로 대조하고, APPROVED_PENDING_ORDER가 일정 시간 이상 남으면 관리자에게 알림을 보내 주문 확정 재시도 또는 결제 취소를 처리하도록 해야 합니다.

누락 사례별로 발생시각, PG사/TID, 금액, 회원·비회원, PC·모바일 정보를 모아 PG 관리자 내역, g5_shop_order, g5_shop_cart, g5_shop_order_post_log, 웹서버·PHP-FPM·DB 로그를 같은 시간대로 대조하면 실제 실패 지점을 찾을 수 있습니다. 서버가 여러 대라면 세션 공유 또는 sticky session 상태도 확인해야 합니다.

결론적으로 트랜잭션은 DB 내부의 부분 저장을 막고, 중간 결제 상태 원장은 외부 PG 승인과 DB COMMIT 사이의 불일치를 추적·복구합니다. 두 장치를 함께 적용해야 주문 유실을 구조적으로 줄일 수 있습니다.

윗분들 처럼 어느정도 정보를 주셔야할거같아요. 

pg사에 따라 유실되는경우들도 있고, 원인이 다양하거든요.

주문 부분에 코드를 수정하신게 있다면 도와 드리기 어렵지만
원본 그대로 사용중이시라면
아래 문의하기에

사용중인 도메인과 결제대행사를 내용에 포함하여 문의해 주십시오

https://sir.kr/boards/co_qa

답변에 대한 댓글 1개

2026-07-15 (수) 11:22:44
네 감사합니다
어떠한 경우에 발생하는 지 원인 찾기
PG 사 통신 확인
서버 확인
홈페이지 소스 확인
 
그것은 사이트 최하단의 문의하기 기능을 이용하세요
여기는 그누보드 유저들이 질문과 답변을 하는곳입니다
그리고 영카트 소스를 건드려 커스텀을 하셨다면 그 내용도 적어주시면 좋습니다

답변을 작성하려면 로그인이 필요합니다.