앱에서 결제한 주문, 서버는 어떻게 결제 완료로 확정할까요?

시연의 주문은 원두 1개, 결제할 금액은 18,000원입니다. 서버가 상품 정보로 계산한 금액과 고유한 주문번호를 먼저 저장합니다. 화면에 적힌 금액과 나중에 돌아오는 금액을 비교할 기준을 마련하는 것입니다. 실서비스에서는 할인·배송비·재고와 주문의 유효 조건도 서버에서 계산하고 확인합니다.

앱은 이 주문번호와 금액으로 결제창을 엽니다. 화면에서 상품명이나 금액을 고쳤다고 서버의 주문 금액까지 바뀌어서는 안 됩니다. 결제를 승인할 수 있는 서버 전용 인증 정보도 앱 화면이나 앱에 포함된 코드에 넣지 않습니다. 이 시연은 실제 결제 키를 사용하지 않습니다.

여기서는 결제창에서 인증을 마친 뒤 상점 서버가 승인을 요청하는 연동 방식을 다룹니다. 토스페이먼츠의 이 방식에서는 인증 후 돌아오는 주문번호·금액·결제 식별값을 사용해 서버가 승인 요청을 이어갑니다. ‘성공 주소로 이동했다’는 사실과 ‘승인된 결제 내역이 확인됐다’는 사실을 나누는 이유입니다.

시연의 ‘인증 결과만 받기’를 누르면 앱은 인증 후 돌아온 주문 정보를 받지만, 주문은 여전히 결제 대기입니다. ‘결제 승인·주문 저장’을 누르면 그다음 확인이 시작됩니다. 앱 하단의 ‘18,000원 결제하기’는 이 두 동작을 순서대로 이어서 보여줍니다. 결제 시스템 영역에는 인증 준비, 우리 서버가 보낸 승인 요청, 승인 기록과 응답을 따로 표시합니다. 결제창의 카드 정보 입력 단계는 생략합니다. 좁은 화면에서는 위쪽 상태 카드를 눌러 앱·우리 서버·결제 시스템의 상세 화면을 선택할 수 있습니다.

서버는 현재 회원의 주문을 찾고, 돌아온 금액이 저장된 18,000원과 같은지 확인합니다. ‘돌아온 금액 불일치’를 선택하면 앱이 9,000원을 보내도록 바뀝니다. 서버는 금액을 거절하며 결제 시스템에 승인 요청을 보내지 않습니다. 앱이 보낸 금액으로 기존 주문 금액을 덮어쓰지도 않습니다.

정상 값이라면 서버가 별도의 결제 시스템에 승인을 요청합니다. 응답에서도 주문번호·결제 식별값·금액과 승인 상태를 대조한 뒤, 같은 데이터베이스 작업 안에서 결제 기록을 남기고 주문을 결제 완료로 바꿉니다. 그다음 앱은 저장된 주문을 별도 조회합니다. 한 번의 서버 응답을 보고 끝내지 않고 저장 결과까지 확인하는 구조입니다.

결제 시스템은 승인했지만 상점 서버가 응답을 제때 받지 못할 수 있습니다. ‘승인 응답 지연’에서는 별도 결제 서버에 승인 기록을 남긴 뒤 응답을 지연시킵니다. 상점 서버는 결과를 아직 확인하지 못했으므로 주문을 결제 완료나 실패로 단정하지 않고 ‘결제 확인 중’으로 둡니다.

이때 ‘기존 결제 다시 확인’을 누르면 새 결제를 만들지 않고 기존 주문의 결제 결과를 조회합니다. 같은 주문·금액·승인 결과가 확인되면 주문을 반영합니다. 실제 시스템에서는 자동 재확인, 결제사 알림과 운영자 확인 등 복구 경로를 결제 방식에 맞춰 설계합니다. 확인 중인 거래를 새 결제로 바꾸는 버튼만 추가해서는 이 간격을 해결할 수 없습니다.

앱에서 같은 승인 결과를 다시 보내거나 확인 버튼을 다시 눌러도 이미 반영한 결제를 새 기록으로 추가하지 않습니다. 시연은 결제 식별값과 주문의 연결을 고유하게 저장하고, 완료된 주문이면 저장된 결과를 돌려줍니다. 결제 완료 뒤 ‘기존 결제 다시 확인’을 반복해 결제 기록이 1건으로 유지되는지 볼 수 있습니다.

결제사 승인과 상점 데이터베이스 저장을 하나의 데이터베이스 작업으로 묶을 수는 없습니다. 따라서 승인 이후 상점 저장이 실패하는 간격도 복구할 수 있어야 합니다. 같은 DB 안의 결제·주문은 함께 저장하되, 외부 승인과의 불일치는 기존 거래 조회와 재처리 기록으로 연결합니다. 일반적인 요청 번호·재시도의 원리는 관련 글에서 이어서 볼 수 있습니다.

시연은 브라우저의 글자만 바꾸는 방식이 아닙니다. 앱과 상점 서버는 HTTP로 통신하고, 상점 서버도 별도 시연용 결제 서버에 승인·조회를 요청합니다. 주문과 결제 시스템은 서로 다른 저장소를 사용합니다. ‘실제 요청과 저장 결과’를 열면 응답 내용과 마지막 주문 조회 결과를 볼 수 있습니다.

정상 승인에서는 결제 기록 1건과 결제 완료 주문, 금액 불일치에서는 승인 0회와 주문 금액 유지, 응답 지연에서는 결제 확인 중과 기존 승인 복구를 확인합니다. 다시 열어도 같은 주문을 조회하며 다른 검토 세션의 주문과 섞이지 않도록 구분합니다. 상품의 배송 상태는 결제와 별도로 접수 대기를 유지합니다.

실제 서비스에 적용할 때는 사용할 결제사의 연동 규격·계약과 테스트/운영 환경, 결제 수단별 추가 흐름을 확인합니다. 이 글은 인증 후 승인을 요청하는 한 주문의 구현 과정을 다루며, 실제 결제사 연결 완료나 전체 취소·부분 환불·가상계좌·앱 마켓 결제 구현을 뜻하지 않습니다.