의외로 경력자 중에 결제 연동 경험이 없는 경우도 많았던 것 같고, 나도 개념을 까먹기 전에 기록해두기 위해, 아임포트의 공지가 어떤 내용이고 어떤 문제를 해결하는 것인지 짤막하게나마 정리를 해보려고 한다. 아래 내용은 나이스페이 기준으로 설명하는 것이지만 모바일 환경이기 때문에 발생하는 문제라서 꼭 어느 PG사에 국한되지는 않을 것이라 생각한다. (대충 기억하기로는 이니페이도 비슷한 방식이었다)
나이스페이 결제는 기본적으로 인증요청-인증결과응답-승인요청-승인응답 순서로 진행된다. 카드번호를 넣거나 카드사별 간편결제 절차를 진행하는 것이 인증요청에 해당하고, 인증 정보를 가지고 다시 서버가 PG사와 통신해서 실제로 결제를 일으키는 것이 승인요청이다. 승인까지 진행되면 '결제가 되었다'고 할 수 있고 카드사에서 문자나 푸시로 결제가 발생했음을 알려준다. (이 시점에 받은 승인응답을 DB 같은 자체 기록으로 남겨두면 된다)
PC 결제에서는 iframe 혹은 다른 방식으로 웹페이지 안에 다른 화면을 표시하는 것이 화면 구성상 크게 무리가 없기 때문에 위의 인증 및 승인 절차를 서비스의 URL을 벗어나지 않고도 진행할 수 있다.
하지만 모바일 결제는 얘기가 다르다. 나이스페이는 인증요청 시작 단계부터 서비스를 벗어나서 나이스페이 URL로 화면이 완전히 바뀌어야 하고, 그 안에서 카드사 간편결제 앱이라도 호출하면 현재의 브라우저 혹은 앱 조차도 벗어나게 된다. 따라서 결제 정보가 어디에서 어디로 가는지, 그때마다 화면은 어떻게 나오는지 신경을 써야 한다. 다시 돌아오는 것조차도 난관이다.
모바일 환경에서도 인증 및 승인 절차는 당연히 필요하고 사용자가 보면서 인증을 진행하는 건 바뀔 구석이 없다. 승인 절차가 어떻게 되는지가 문제다. 나이스페이의 모바일 결제에서 승인은 두 갈래로 나뉜다.
- 하나는 승인요청을 나이스페이가 미리 처리한 다음 승인응답 결과만을 서버로 직접 건내주는 방식이다. 그 뒤에 나이스페이는 사용자를 처음 인증요청할 때 지정했던 URL로 돌아가라고 보낸다. 돌아온 URL에서는 (아까 서버가 받은 승인응답 결과에 따라 처리가 끝난) 완료 화면을 보여주게 된다.
- 다른 하나는 PC와 동일하게 사용자가 돌아온 시점에서야 승인요청을 진행하는 것이다. 아임포트가 공지한 niceMobileV2: true 옵션은 이 방식을 따르도록 만든다.
첫번째 방식대로 진행이 되었을 때 생기는 문제는 이렇다. 모바일 결제에서 사용자가 인증을 마친 뒤에 화면이 완전히 바뀔 때까지 서버는 반드시 승인요청과 승인응답 및 그 기록 절차를 마쳐야 한다. 그런데 여러가지 이유로 가끔 이 전제가 지켜지지 못할 때가 있다. 이러면 이미 인증을 마쳤고 나이스페이가 카드사와의 승인 절차도 끝내서 카드결제 문자는 받았으니 사용자는 다 잘 된 걸로 아는데, 정작 서비스는 결제가 안된 상태로 남아있게 된다. 그렇게 누락된 결제건이 있다는 사실 자체도 모를 수 있다. 항의 전화가 들어올 차례다.
두번째 방식은 첫번째 방식에서 생기는 누락을 완전히 없앤다. 사용자가 다시 돌아오지 못해서 결제가 승인되지 못하면 그냥 그뿐이다. 서비스의 전환률이 낮아질지언정 (이건 고치면 된다) 고객 불만과 불필요한 환불 업무는 생기지 않는다. 덤으로 PC 결제에서 쓰는 코드를 그대로 가져다 쓸 수 있다는 장점도 있다. 해피 엔딩.
