결제·정산이 끼어 있는 외주 프로젝트는 인계 직후에 분쟁으로 번지기 쉬워요. 이유는 코드 품질이 아니에요. 코드는 멀쩡한데 PG 가맹점 명의·간편결제 키·웹훅 시크릿·세금계산서 발급 권한이 한 줄도 제대로 안 넘어와 있어서 그래요. 결제 시스템은 "완성도"가 아니라 "권한 이전"이 진짜 인계의 본체예요. 소스 코드는 저장소 권한만 넘기면 끝나지만, 결제는 심사·명의·계좌·세무가 얽혀 있어서 넘기는 절차 자체가 별도의 프로젝트예요.
그래서 인계 후에야 문제가 드러나요. 개발이 끝난 시점에는 결제가 잘 되니까 아무도 이상을 못 느끼는데, 첫 정산일과 첫 세무 마감이 지나면서 "이 돈이 왜 우리 계좌에 안 들어오지", "이 세금계산서는 누가 발급하지"가 한꺼번에 터집니다. 검수 항목이 "결제가 되는가"에만 걸려 있으면 이 구멍은 절대 안 잡혀요.
확인해야 할 조건은 회사마다 다르고 시점마다 바뀝니다. PG사와 간편결제사는 각자 별도의 가맹점 심사 요건을 두고 있고, 정산 주기도 서비스·업종·계약 조건에 따라 다르게 적용돼요. 인계 계획을 세우기 전에 각 사 콘솔과 계약서에서 지금 적용 중인 심사 요건·정산 주기·수수료 조건을 직접 확인하는 게 먼저예요. 남이 정리해둔 요약이나 몇 달 전 자료를 그대로 옮겨 적으면 일정이 반드시 어긋납니다.
특히 가맹점 명의 이관은 코드 인계보다 훨씬 오래 걸려요. 명의를 바꾸는 건 계정 정보를 수정하는 일이 아니라 심사를 처음부터 다시 받는 일이기 때문이에요. 서류 준비, 심사 대기, 계좌 등록, 기존 정산 잔액 정리가 순서대로 붙습니다. 이 기간을 일정표에 별도 라인으로 잡아두지 않으면 잔금 시점을 그냥 넘어가고, 그때부터는 협상력이 발주사 쪽에 없어요.
이 글은 외주 계약서에 넣어야 할 8가지 항목을 체크리스트로 정리했어요. 결제 시스템을 안전하게 받아오기 위한 최소 합의입니다.
국내 PG사는 가맹점 심사 시 사업자등록증·통장사본·대표자 신분증을 본인 명의로 요구해요. 외주사가 "임시로 우리 명의로 시작"하면 매출과 정산이 외주사 계좌로 들어가고, 분쟁 시 발주사가 결제 시스템을 한 줄도 못 만집니다.
이게 왜 위험한지는 자금 흐름을 따라가 보면 분명해요. 가맹점이 외주사 명의로 개설돼 있으면 서비스에서 발생한 매출 정산금이 전부 외주사 계좌에 쌓여요. 발주사는 자기 서비스에서 나온 돈인데도 명의 이관이 끝날 때까지 그 자금에 손을 못 대고, 외주사가 정산 이체를 미루면 독촉 말고는 수단이 없습니다. 여기에 이관 심사 기간까지 겹치면 자금이 묶여 있는 상태가 길어져요.
국내 온라인 결제에서 간편결제가 차지하는 비중은 계속 커지고 있어요. PG 가맹점만 넘겨받고 간편결제 가맹점을 빼놓으면, 실제로 돈이 들어오는 경로의 상당 부분을 발주사가 못 만지는 상태가 됩니다. 그런데 카카오페이·네이버페이는 PG와 별개의 가맹점 심사를 거칩니다.
결제 사고는 반복적으로 웹훅 구간에서 터져요. 외주사 코드는 "결제 완료 200 OK"만 받고 끝나는 경우가 많은데, 그 코드로는 망 장애·재시도·중복 처리를 하나도 못 막습니다. PG 망이 순간 불안정해지면 결제사는 같은 이벤트를 여러 번 보내요. 이때 idempotency key가 없으면 같은 주문이 여러 번 승인되고, 사용자는 한 번 산 물건에 결제가 여러 건 찍힌 걸 보게 됩니다.
중복 결제의 비용은 환불 수수료만이 아니에요. 앱 리뷰와 CS 채널에 곧바로 흔적이 남고, 신뢰를 되돌리는 데는 환불보다 훨씬 오래 걸립니다. 그리고 코드 레벨에서만 막으면 언젠가 뚫려요. 동시에 들어온 두 요청이 각자 "아직 없네"를 확인하고 둘 다 삽입해 버리기 때문이에요. DB unique constraint로 강제해야 그 경합에서 한쪽이 확실히 실패합니다.
orderId 또는 paymentId) 기반 중복 결제 차단. DB unique constraint로 강제.운영팀이 가장 자주 쓰는 작업이지만, 외주 인계 시 가장 자주 빠지는 부분이에요.
결제는 받았는데 정산이 어긋나면 매월 회계가 깨져요. PG·간편결제·세금이 3축으로 묶입니다.
/v1/settlements API) → 자체 DB 적재 → 차이 1원 이상 알람.cardNumber·cvc·expiryDate 0건 확인.아래는 특정 사건 기록이 아니라, 결제 인계에서 반복적으로 관찰되는 유형이에요. 어떤 서비스에서 어떤 항목이 빠지면 어떤 결과로 이어지는지를 보는 용도로 읽으면 됩니다.
4가지 중 1개라도 빨간불이면, 정산 차액·세금계산서 미발급·중복 결제 중 하나가 실제로 터지기 쉬운 상태예요. 이 항목들은 사고가 나야 드러나는 종류라, 평소에 조용하다는 게 안전하다는 뜻이 아닙니다.
코드를 다 받았다고 결제를 받은 게 아니에요. PG 명의·키·시크릿·콘솔 권한·정산 자동화·세금계산서 발급·SLO·SOP의 8개 축이 같이 넘어와야 진짜 인계입니다. 계약서 8개 항목과 12자산 인계 체크리스트를 RFP에 미리 박아두면, 인계 시점의 논의가 "이걸 해주느냐 마느냐"라는 협상이 아니라 "합의한 항목이 이행됐는가"라는 확인 문제로 바뀌어요. 분쟁의 상당수는 그 성격 전환만으로 사라집니다.
포텐랩은 결제·정산이 포함된 인계를 이 8개 표준 항목으로 처리하고, 정산 데이터를 Notion으로 발주사와 정기적으로 공유해요. 포텐랩의 수행완수율은 97%입니다. 결제·정산 시스템을 안전하게 받아오는 IT 외주 파트너가 필요하다면 포텐랩 상담으로 30분만 이야기해 보세요. AI·챗봇·RAG가 결제 플로우에 얽혀 있는 경우라면 AI 특화 팀인 트리숲(TreeSoop) 쪽이 더 맞을 수 있고, 맞지 않는 쪽으로 보내지 않는 게 서로에게 이득이에요.
코드 품질 문제가 아니에요. 코드는 멀쩡한데 PG 가맹점 명의·간편결제 키·웹훅 시크릿·세금계산서 발급 권한이 제대로 안 넘어와서 생깁니다. 결제 시스템은 완성도가 아니라 권한 이전이 인계의 본체예요. 개발이 끝난 시점에는 결제가 잘 되니 아무도 이상을 못 느끼다가, 첫 정산일과 첫 세무 마감이 지나면서 한꺼번에 드러납니다.
서비스에서 발생한 매출 정산금이 전부 외주사 계좌에 쌓입니다. 발주사는 자기 서비스에서 나온 돈인데도 명의 이관이 끝날 때까지 그 자금에 손을 못 대고, 외주사가 이체를 미루면 독촉 말고는 수단이 없어요. 계약서에 이관 착수 시점·완료 기한·미이관 시 잔금 유보 조항을 함께 박아두어야 합니다.
명의를 바꾸는 건 계정 정보를 수정하는 일이 아니라 심사를 처음부터 다시 받는 일이기 때문이에요. 서류 준비, 심사 대기, 계좌 등록, 기존 정산 잔액 정리가 순서대로 붙습니다. 이 기간을 일정표에 별도 라인으로 잡아두지 않으면 잔금 시점을 그냥 넘어가고, 그때부터는 협상력이 발주사 쪽에 없어요.
네. 카카오페이·네이버페이는 PG와 별개의 가맹점 심사를 거칩니다. PG 가맹점만 넘겨받고 간편결제를 빼놓으면 실제로 돈이 들어오는 경로의 상당 부분을 발주사가 못 만지는 상태가 돼요. 4종 모두 발주사 명의로 등록하고 콘솔 owner 권한을 받으세요. 정기결제·빌링키를 쓴다면 PG 교체 시 빌링키 재발급이 불가능하므로 백업과 마이그레이션 절차도 인계 문서에 포함해야 합니다.
PG 망이 순간 불안정해지면 결제사가 같은 이벤트를 여러 번 보냅니다. idempotency key가 없으면 같은 주문이 여러 번 승인돼요. 중요한 건 코드 레벨 방어만으로는 부족하다는 점입니다. 동시에 들어온 두 요청이 각자 '아직 없네'를 확인하고 둘 다 삽입해 버리기 때문에, DB unique constraint로 강제해야 그 경합에서 한쪽이 확실히 실패합니다.
PG사와 간편결제사는 각자 별도의 심사 요건을 두고 있고 정산 주기도 서비스·업종·계약 조건에 따라 다르게 적용됩니다. 인계 계획을 세우기 전에 각 사 콘솔과 계약서에서 지금 적용 중인 심사 요건·정산 주기·수수료 조건을 직접 확인하세요. 남이 정리해둔 요약이나 몇 달 전 자료를 그대로 옮겨 적으면 일정이 반드시 어긋납니다.