결제 책임 지도: 고객지원부터 재무까지

"저희 쪽은 다 성공입니다"라는 답은 고객이 이미 돈을 냈는데 창고가 주문을 출고하지 못할 때 아무 쓸모가 없습니다. PG사는 거래를 보고, 회계팀은 지급을 찾고, 개발자는 알림을 확인합니다. 문제는 흔히 이 기록들의 경계에서 멈춥니다. 이를 풀어 주는 것이 책임 분담표, 즉 결정 지도입니다. 누가 사실을 확인하고, 누가 조치할 권한이 있으며, 누가 결과가 나올 때까지 고객 곁에 남는지를 정합니다.

실무 사례: 120유로는 어디에 있는가

가상의 예시입니다. 쇼핑몰이 120유로짜리 주문을 받았습니다. PG사 화면에는 성공한 거래가 보이지만, 정산 계좌에는 아직 그 금액이 없습니다. 상담원은 "돈이 사라졌다"고 적어 개발팀에 넘깁니다. 이런 설명은 너무 넓습니다. 결제 상태와 그 이후의 지급을 섞고 있기 때문입니다.

먼저 쇼핑몰 직원이 주문 번호를 거래 식별자와 연결합니다. 그다음 결제팀이 PG사에서 거래 상태와 그 거래가 들어가야 할 리포트를 확인합니다. 자금팀은 해당 지급과 은행 참조 번호를 찾습니다. PG사 데이터와 내부 시스템이 어긋나면 개발자가 합류합니다. 지급액에는 많은 거래와 조정이 합쳐질 수 있으므로, 은행 거래내역에서 정확히 120유로를 찾는 것만으로는 아무것도 해결되지 않습니다.

가상의 리포트에 120유로의 판매와 별도의 수수료 3유로가 있다고 합시다. 다른 움직임이 없다면 정산 금액은 117유로입니다. 이는 예시의 계산이지 어떤 서비스의 요율이 아닙니다. 자금 사용 가능일과 지급 구성을 확인하기 전에는 구매자가 3유로를 덜 냈다고 결론 내리면 안 됩니다.

회사 이름보다 역할이 먼저다

가맹점은 상품이나 서비스를 판매합니다. 가맹점 시스템에는 주문, 구매 조건, 이행 정보, 고객과의 소통 이력이 있습니다. 그래서 아무리 자세한 은행 거래내역도 특정 택배가 발송됐는지, 구독이 활성화됐는지는 설명하지 못합니다. 이런 질문에는 판매자 자체의 기록이 필요합니다.

PSP, 즉 payment service provider는 기업을 위한 결제 기능을 하나로 묶어 제공합니다. 구체적인 구성은 상품에 따라 다릅니다. 결제 수단 연결, 라우팅, 관리 화면, 리포트 등입니다. 프로세서는 결제 메시지의 기술적 처리를 맡습니다. 한 공급자가 여러 역할을 겸할 수 있으므로 "PSP"라는 이름만으로 계약 관계의 사슬을 설명할 수는 없습니다. 이런 겸업은 결제 서비스 제공자에 대한 Adyen의 개요에서 설명합니다.

매입사는 판매자 쪽에서 카드 결제 수납을 맡고 정산에 참여합니다. 발급사는 구매자의 카드를 발급합니다. 카드 모델에서는 그 사이에서 카드 네트워크가 작동합니다. 매입사와 발급사의 간단한 정의는 Adyen의 공식 용어집에 있습니다. 직접 계좌이체라면 구조가 다릅니다. 카드 용어를 모두 그대로 옮겨 쓸 수는 없습니다.

책임을 행동 단위로 적어라

• 주문과 이행: 누가 출고를 멈추고, 주문 구성을 바로잡고, 상품 수령을 확인할 수 있는가?
• 결제: 누가 공식 상태를 읽고, 금액과 통화를 확인하고, 거절 사유를 보는가?
• 환불: 누가 쇼핑몰 규정에 따라 승인하고, 누가 PG사에서 결과를 확인하는가?
• 지급: 누가 리포트를 은행 거래내역과 대사하고, 불일치가 있을 때 문의를 여는가?
• 장애: 최종 답이 아직 없더라도 누가 고객에게 다음 업데이트 시점을 알리는가?

각 행동마다 주 담당자, 대체자, 특정 데이터 출처에 대한 접근 권한이 필요합니다. "혹시 몰라서" 모두에게 전체 권한을 주지 마세요. 고객지원 직원은 보통 거래 상태와 주문과의 연결만 보면 충분합니다. 지급 계좌 정보를 바꿀 권한은 따로 검토해야 합니다.

조사는 질문과 함께 넘겨라

"결제가 사라졌다"는 문의에는 검증할 수 있는 경계가 없습니다. 이렇게 바꿔 쓰세요. "주문 O-120은 결제 P-817과 연결되어 있음. PG사는 청구를 확인했지만 내부 주문은 대기 상태로 남아 있음. 이벤트를 받았는지, 주문이 왜 바뀌지 않았는지 확인 필요." 이제 대상, 마지막으로 확인된 상태, 빠진 사실이 분명합니다. 예시의 식별자는 가상입니다.

인계에는 짧은 패키지면 충분합니다. 주문 번호, 허용된 PG사 기록의 링크, 금액과 통화, 시간대를 포함한 시각, 기대한 동작과 실제 동작, 이미 한 조치입니다. 지금 무엇이 막혀 있는지도 따로 적으세요. 출고인지, 환불인지, 지급 추적인지입니다. 참조 번호 두 개로 해결되는 문제라면 고객 프로필 전체를 첨부하지 마세요.

받는 팀은 다음 단계를 확인해 주어야 합니다. 확인이 오기 전까지는 이전 담당자가 계속 문의를 맡습니다. 이것은 제안하는 업무 규칙이지 카드 네트워크의 특성이 아닙니다. 보낸 쪽은 이미 남의 티켓으로 여기는데 받은 쪽은 아직 자기 것으로 여기지 않는, 불편한 틈을 막아 줍니다.

담당자 한 명이 모든 권한을 가질 필요는 없다

세 가지 기능을 나누세요. 원인을 밝히는 것, 금전 조치를 승인하는 것, 결과를 알리는 것입니다. 예를 들어 개발자는 이벤트가 유실됐음을 증명할 수 있지만, 환불 결정은 권한 있는 직원이 내립니다. 고객지원은 고객과 소통하지만 지급 계좌 정보는 바꾸지 않습니다. 이런 구조는 모든 장애를 권한 확대의 계기로 만들지 않으면서도 속도를 유지합니다.

당직 교대 시점에 이 지도를 점검하세요. 18:00에 주 담당자가 퇴근하면, 대체자는 증거를 찾고, 조치가 중복될 위험을 이해하고, 다음 업데이트 시각을 말할 수 있어야 합니다. 그러려면 퇴근한 직원의 개인 채팅이 필요하다면, 프로세스는 생각보다 훨씬 사람에게 의존하고 있는 것입니다.

주간 리뷰에서는 팀 간 인계 횟수와 다음 조치가 지정되지 않은 채 흐른 시간을 세세요. 이 지표는 조직 내부의 지연을 은행 대기와 구분해 보여 줍니다. 조사의 종료는 마지막으로 보낸 "그쪽에서 확인 부탁드립니다"라는 요청이 아니라, 기록 간 연결이 복원되고 출처로 확인된 조치가 실행된 시점으로 보세요.

중개사에 확인할 것

플랫폼을 통해 연동한다면 누가 계약 당사자이고 누가 돈을 송금하는지 물어보세요. 예를 들어 payment facilitator는 하위 가맹점을 연결하고, 이후 지급을 위해 정산 자금을 받을 수 있습니다. 이 모델은 Adyen 도움말에서 설명합니다. 국가와 법인을 포함해 우리 구성에 해당하는 구조도를 요청하세요.

카드 데이터 보호 의무도 따로 정리해 두세요. 처리를 외부 업체에 맡겨도 가맹점의 모든 의무가 사라지지는 않습니다. PCI SSC는 책임 분담을 이해할 필요가 있다고 지적합니다. 구체적인 점검 범위는 PCI 보고서를 받는 기관과 합의하세요.

출시 전에 다음 교대조에게 구두 설명 없이 미결 사례 하나를 건네 보세요. 직원이 빠진 사실, 확인할 곳, 다음 단계의 담당자를 말하게 하세요. 카드에서 이 세 가지 답을 얻을 수 없다면, 고쳐야 할 것은 업무 인계 그 자체입니다.