결제 webhook을 받았습니다. 서명 검증만 하면 중복·재생·순서 문제도 해결되나요?

서명은 payload의 출처·무결성을 확인하는 수단이고 이벤트의 단일 처리와 업무 순서는 별도입니다. 원문 바이트로 서명을 검증하고 시각·허용 오차·이벤트 ID·대상 상태를 함께 확인합니다.

동작 원리와 전제

JSON을 파싱해 다시 직렬화하면 공백·키 순서가 달라져 서명 입력이 바뀔 수 있습니다. 제공자 계약의 정확한 원문과 헤더를 사용하고 비밀키를 로그에 남기지 않습니다. 시각 검사는 재생 창을 줄이지만 정상 재전달과 지연을 고려합니다.

선택과 실패 처리

같은 이벤트가 여러 번 오면 처리 ID와 변경을 같은 transaction에서 멱등화합니다. 취소 이벤트가 승인보다 먼저 오는 경우 현재 상태와 버전·결제사 조회를 사용해 안전하게 정리합니다. HTTP 200을 빨리 반환하려면 먼저 내구 접수하고 이후 실패를 재처리할 경로가 있어야 합니다.

구체적인 사례와 검증

외부 서비스가 같은 결제 완료 이벤트를 열 번 보내도 원장에는 논리 이벤트 한 건만 반영되어야 합니다. 서명 검증은 매 전달의 진위를 확인하고 DB unique 조건은 효과의 중복을 막습니다. 둘은 순서대로 필요한 별도 검사입니다. 이벤트를 내구 큐에 넣기 전에 200을 반환하면 프로세스 중단 시 잃을 수 있으므로 접수 보장을 명시합니다. 반대로 처리 완료까지 길게 대기하면 제공자가 timeout으로 재전달할 수 있습니다. 빠른 ACK와 내구 접수·후속 재처리의 경계를 정하고, 처리 실패를 정상 접수 성공 뒤에도 운영자가 볼 수 있게 합니다.

중복·순서 역전·서명 오류·키 회전·접수 후 중단을 시험합니다. 이벤트의 URL을 무조건 방문하거나 payload의 사용자 ID를 인가 근거로 쓰지 않습니다. 인증된 메시지라도 실제 업무 상태와 원장에 맞는지 검증해야 합니다.