문제 1:

결제 요청 - 카드사 인증 - 결제 승인 요청 - 카드사 결제 승인 - 백엔드의 승인 결과 처리로 이어지는 로직에서 결제는 처리되지만 DB의 결과 처리 과정이 제대로 이루어지지 않는 경우가 발생했습니다.

원인 분석 :

결제 승인이 성공한 후 트랜잭션 처리 중 에러가 발생하는 경우, 결제는 정상 처리되지만 DB에는 해당 결제 데이터가 적절하게 반영되지 않는 것이 원인이었고 이로 인해 토스 결제 부분과 DB의 결제 정보 간의 불일치가 발생했습니다.

해결 :

결제 승인 이후 트랜잭션이 실패하면, 승인된 결제를 자동으로 환불하는 로직을 추가했습니다. 이를 통해 결제 승인과 데이터베이스 업데이트 사이에 문제가 발생할 경우, 결제를 취소하여 시스템 상태를 일관성 있게 유지할 수 있었습니다. 이를 위해 트랜잭션 내에서 승인 요청을 처리하고, 승인 성공 후 발생하는 모든 에러에 대해 일관된 롤백 또는 보정 작업을 수행할 수 있도록 구조를 개선했습니다

문제 2 :

프로젝트의 결제 처리 로직에서 초기에는 결제 요청 전에 직접 orderId를 생성하고, 이 orderId를 기준으로 결제 정보를 미리 DB에 저장하고 결제 요청 시 비교하여 유효성 검사를 수행한 후, 결제 승인 요청을 진행했습니다.

그러나 버블로 프론트엔드를 작업하면서 토스(Toss)에서 제공하는 버블 결제 플러그인을 사용하는 것으로 결정했는데 플러그인을 사용하면 기존의 결제 로직을 그대로 사용할 수 없는 문제가 발생했습니다.

원인 분석

토스에서 제공하는 버블 플러그인은 결제 요청 시에 orderId를 자동으로 생성하도록 설계되어 있어, 개발자가 요청 전에 직접 orderId를 생성할 수 없는 문제가 있었습니다. 이는 기존 로직에서 필수적으로 사용하던 orderId 기반의 유효성 검사 방식, DB에서의 결제 처리 로직과 충돌을 일으켰습니다.

해결 과정 :

• 문제 분석 및 해결 방안 탐색: 처음에는 공식 문서와 다양한 온라인 자료를 통해 문제 해결 방법을 찾으려고 했습니다. 하지만, 버블 플러그인에 대한 정보는 많지 않았고, 문제를 해결하기에 충분한 정보를 얻지는 못했습니다.

• 커뮤니티 및 개발자 소통: 문제 해결에 필요한 정보를 찾는 데 한계가 있었기에, 결국 토스 개발자 커뮤니티에 이슈를 제기하기로 했습니다. 문의한 결과, 토스 개발자로부터 플러그인의 편의성을 위해 orderId는 자동으로 생성되며, 직접 설정할 수 있는 옵션이 따로 제공되지 않는다는 답변을 받았습니다.

• 대체 방안 모색 및 구현: 기존 로직을 그대로 유지할 수 없었기에, 대체 방안을 모색했습니다. 토스 플러그인이 제공하는 기능과 제한 사항을 감안하여, orderId 대신 orderName 필드를 활용하기로 결정했습니다. 구체적으로는, 요청 전에 클라이언트 측에서 컨트롤할 수 있는 orderName에 결제 품목의 ID를 포함시켜, 이 값을 기준으로 결제 요청 정보의 유효성을 검사하고, 결제한 품목들을 추적하여 토스 결제 승인 이후에 DB 처리를 할 수 있도록 로직을 변경했습니다.

  이를 통해 결제 프로세스의 유효성 검사를 유지하면서도, 토스 플러그인의 구조적인 제한 사항에 맞춘 새로운 로직을 구현할 수 있었습니다.