주문은 만료됐는데 돈이 들어왔다: P2P 주문의 라이프사이클

가상의 10 000 결제로 지연 입금 사례를 살펴보겠습니다. 결제 안내의 유효 기한은 10:15에 끝났습니다. 구매자는 10:14에 송금했고, 수취 은행은 10:17에 이를 반영했으며, 운영자는 10:20에 기록을 확인했습니다. 그 사이 상점은 주문을 취소했습니다. 누가 늦은 것이고, 이 결제를 없던 것으로 볼 수 있을까요? 답은 해당 거래의 시각과 규칙에 따라 다르지만, 주문이 어떤 색으로 표시되든 돈은 이미 장부에 반영되어야 합니다.

P2P 주문의 라이프사이클은 '생성, 결제, 완료'라는 하나의 사슬로 설명하기 어렵습니다. 그 안에서 계좌 정보의 유효성, 은행 송금의 상태, 입금의 입증 정도, 가맹점에 대한 의무가 동시에 바뀝니다. 예외는 바로 이 중 하나의 프로세스가 나머지보다 앞서 나간 곳에서 생깁니다.

주문과 입금은 식별자가 다르다

주문은 예상되는 이벤트를 설명합니다. 누가, 얼마를, 어떤 통화로, 어디로, 언제까지 내야 하는지입니다. 은행 기록은 감지된 이벤트를 설명합니다. 돈이 어느 계좌로, 얼마나, 어떤 참조 번호와 송금인 정보와 함께 들어왔는지입니다. 하나의 주문에 여러 입금이 대응할 수 있지만, 하나의 입금을 통제 없이 여러 주문의 마감에 써서는 안 됩니다.

그래서 주문 번호 옆에 독립된 입금 객체가 필요합니다. 여기에는 원래의 은행 식별자, 수취 계좌, 통화, 금액, 거래 시각, 감지 시각을 저장합니다. 참조 번호의 고유성 범위는 출처가 정합니다. 서로 다른 두 시스템에 같은 문자열이 있다고 같은 송금을 뜻하지는 않습니다. 정정된 은행 기록 역시 문구가 바뀌었다는 이유만으로 새 결제처럼 보여서는 안 됩니다.

주문과 입금의 연결은 별도의 결정으로 만듭니다. 여기에는 발급한 계좌 정보의 버전, 허용된 결제 출처, 일치의 증빙이 중요합니다. 이 연결에 자체 번호를 붙이면 돈을 받은 사실 자체는 지우지 않고 잘못된 매칭만 취소할 수 있습니다. 이력에는 누가 기록을 연결했는지, 어떤 근거를 썼는지, 왜 나중에 결정을 다시 검토했는지가 남습니다.

중간 상태가 유용하다

생성된 주문은 배정을 기다리고, 그다음 처리 담당자와 예약이 붙습니다. 계좌 정보가 고객에게 공개됩니다. 구매자가 "결제했다"고 알리면 주문은 확인 대기로 넘어가지만, 그것이 곧바로 확정 매출을 만들 필요는 없습니다. 감지된 입금은 먼저 검증을 거치고, 그다음 주문에 배분됩니다. 그 후에야 계약에 정한 금융적 인정이 이루어집니다.

그 뒤에 참여자와의 정산과 가맹점 지급이 따로 이어집니다. 분쟁, 환불, 정정은 나중에 생길 수 있습니다. 이 구조는 운영 모델로 제안하는 것이며, 상태 이름은 공급자마다 다릅니다. 중요한 것은 전환의 의미를 지키고, 하나의 상태가 SMS 수신, 돈의 수령, 최종 정산을 동시에 뜻하게 만들지 않는 것입니다.

특정 API에는 문서화된 예외도 있습니다. PayStar 설명에 따르면 P2P 주문은 문의 후 기존 식별자를 유지한 채 Failed에서 Success로 바뀔 수 있습니다. 같은 문서는 이벤트 이력이 완전한 추적을 보장한다고 밝히지도 않습니다. 이는 설명된 인터페이스의 특성으로, 자신의 연동에서 확인해야 하며 모든 P2P 플랫폼의 보편적 규칙이 아닙니다.

늦게 들어온 입금을 분 단위로 따져 보기

10 000 송금으로 돌아갑시다. 로그에는 최소한 안내 만료 시각 10:15, 은행 입금 시각 10:17, 감지 시각 10:20이 남습니다. 송금 시각 10:14는 구매자의 증빙으로 알게 된 것이며 검증이 필요할 수 있습니다. 이 시각들은 서로를 대신하지 않습니다. 계약이 수취인 계좌에 입금된 시점을 기준으로 한다면, 구매자가 버튼을 일찍 눌렀다는 사실만으로 기한이 연장되지는 않습니다.

운영자는 원래 주문을 찾아 은행 기록을 확인하고, 지연 입금에 대해 정해진 예외 상태로 옮깁니다. 그다음 금융 조치를 정합니다. 원거래에 대한 입금으로 인정할지, 합의된 정정을 보낼지, 환불 처리할지입니다. 결정이 나기 전까지 이 금액은 사용하는 회계 모델에 따라 미배분 입금 또는 정리 대상 입금으로 관리합니다.

이때 가맹점은 자기 주문을 점검합니다. 상품이 품절되었거나, 예약이 사라졌거나, 고객이 이미 대체품을 샀을 수 있습니다. 결제 사실이 복구되었다고 해서 자동으로 이행을 반복할 권리가 생기지는 않습니다. 금융 상태와 상점의 결정은 명시적인 예외 처리를 통해 연결됩니다. 그래야 결제 정정이 예상치 못한 중복 배송이나 두 번째 상품 활성화로 이어지지 않습니다.

하나의 결제, 두 조각

고객은 10 000을 내야 했지만 6 000이 들어왔습니다. 송금 메모에 주문 번호가 있다고 이 기록이 전액 결제가 되지는 않습니다. 운영자는 받은 6 000과 모자라는 4 000을 기록합니다. 이후 조치는 조건에 따라 다릅니다. 허용된 추가 입금 대기, 당사자 동의에 따른 주문 변경, 또는 환불입니다. 사용하는 결제 수단의 규칙이 부분 결제를 금지한다면, 이를 조용히 허용된 것으로 선언해서는 안 됩니다.

나중에 4 000 송금이 들어옵니다. 모델이 여러 건의 송금을 허용하고 두 출처 모두 검증을 통과했다면, 두 개의 별도 기록을 하나의 주문에 배분할 수 있습니다. 합계는 10 000이 되지만 증빙과 은행 참조 번호는 따로 남습니다. 두 번째 송금이 다른 사람에게서 왔거나 다른 계좌로 들어왔다면, 합계 금액이 맞는다는 것만으로 자동 완료하기에는 부족합니다.

돈이 없는데 모자라는 부분을 '시스템 보상'으로 수기 입력하는 것은 특히 위험합니다. 이는 거래의 경제 구조를 바꾸며, 누가 왜 차액을 부담하는지에 대한 명시적 결정이 필요합니다. 그렇지 않으면 지원팀은 화면상 전환율을 높이는 대신 정산에 설명할 수 없는 채무를 만들게 됩니다.

메시지 중복과 두 번째 송금은 비슷해 보인다

하나의 은행 입금에 대해 SMS, 푸시, 거래 내역 기록, 재업로드 데이터가 모두 들어올 수 있습니다. 이는 한 이벤트에 대한 여러 관찰입니다. 확실히 매칭되고 나면 이들은 증빙을 보강할 뿐 받은 금액을 늘리지 않습니다. 각 관찰은 자기 출처를 유지하지만, 금융적 인정은 하나의 입금에 귀속됩니다.

10 000짜리 실제 송금 두 건은 다른 상황입니다. 금액과 이름이 같다고 두 번째를 기술적 중복으로 지울 수는 없습니다. 은행 식별자와 실제 기록을 확인해야 합니다. 별개의 입금이라면 하나는 주문 대금이 되고, 다른 하나는 별도의 정리 의무를 가진 초과 입금이 됩니다. 여기서 '5분 내 같은 금액' 기준의 중복 제거는 장부에서 고객의 돈을 잃어버리게 만듭니다.

무엇을 충분한 증빙으로 볼 것인가

입금 사실에 대해서는 이용 가능한 수취인의 권한 있는 은행 데이터와, 서비스 사업자가 자기 역할 범위 안에서 주는 확인이 가장 중요합니다. 가맹점에 대한 의무에는 여기에 계약 조건과 합의된 인정 규칙이 더해집니다. 결제자의 스크린숏, SMS, 트레이더의 메시지는 거래를 찾는 데 도움이 되지만, 그 신뢰성과 완전성은 따로 평가해야 합니다.

매칭은 금액, 통화, 수취인, 은행 참조 번호, 시간 범위, 허용된 송금인을 고려해야 합니다. 이름이 일치하더라도 자금 출처의 적법성이 증명되지는 않습니다. 출처 간 모순이 있으면 가장 편한 상태를 고르는 것이 아니라 검토로 넘깁니다.

종결된 주문은 재현 가능한 이력을 남겨야 합니다. 무엇을 예상했는지, 실제로 무엇이 들어왔는지, 어떤 증빙을 확인했는지, 금액을 어떻게 배분했는지, 어떤 의무가 생겼는지입니다. 그러면 늦은 송금은 관리 가능한 예외가 됩니다. 이 이력이 없으면 그것은 스크린숏 세 장과 채팅 속 확신에 찬 두 목소리 사이의 다툼이 됩니다.