How Payments Work?
1.
Collect Payment Method
2.
Verify Payment Method
3.
Charge Payment Method
4.
Manage Payments
5.
Process Order in App
•
일반적으로 1~4 단계는 큰 기업이라고 할지라도 Outsourced 되는 경우가 많다.
•
그렇다면 Outsourced Solution을 쓰면서 이를 어떻게 작동 시키는가? Payment에 쓰이는 데이터들을 Client(Browser)에서 모은다. 수집한 데이터를 Third Party Server에 보내게 되는데, 보낸 데이터들이 Valid하다면 Token을 발급하게 된다. 해당 Token을 Node.js Application을 구동하고 있는 Server로 보낸다. Server는 Third Party Server에서 유효하게 작동하는 Token을 갖고 있으므로, Charge를 Token과 함께 보내서 Payment Data를 생성하게 된다.
Using Stripe in Your App
•
Code에 대한 것들은 동영상 및 Repository를 참조하는 것이 더 빠르므로 참고 사항만 적겠다.
•
View에 Third Party Script를 넣고, View에서 해당 Script를 쓸 수 잇도록 한다. 이후에 추가로 Script를 선언하여 Third Party Script의 Code를 이용하여 로직을 작성한다.
•
일반적으로 View에서 결제를 진행하기 위해서, Third Party에 대한 Session이 필요하므로 View를 뿌리기 전에 Controller에서 Third Party에 대한 Session을 생성하여 넘겨주도록 한다. (생성을 위한 Package, 생성 방법, 생상할 때 쓰이는 인자들은 Code를 참고할 것)
•
원리는 다음과 같다. View에 Third Party Script와 이를 활용하여 자체적으로 로직을 처리하는 Script가 있으므로, Order 버튼을 Click 시 Click에 대한 Event를 발생시킨다. (자체적으로 로직을 처리하는 Script는 Stripe에 대한 Instance 생성, 버튼에 Event Listener를 다는 Code들이 들어간다.) Event 발생 시, Stripe로 결제 요청이 넘어가게 된다. 이 때, 결제 성공 시 돌아올 URL, 실패 시 돌아올 URL에 대한 정보가 필요하다. 이런 정보들은 Hard하게 일일이 Controller에서 처리하여 넘기는 것이 아니라, Stripe에 대해서 설정한 sessionId를 넘김으로서 가능하게 한다. 즉, Controller에서는 response.render를 수행하기 전에, stripe.checkout.session.create()를 통해서 session을 생성하여 해당 정보를 View에 넘기게 하여 결제가 가능하도록 한다.
•
Success와 Cancel에 대한 Routing 들도 작성해야 하는데, 이 때 Success시 불러올 Page가 단순한 get을 통한 View가 아니라 Nested되어 post요청 후 get을 통해 Render하는 경우라면 매우 조심해야 한다. Success 시 요청되는 URL을 Manual하게 Typing하면 결제도 하지 않았는데도 불구하고 (즉, 결제 모듈을 통해서 Success를 받고 Page가 넘어간 것이 아님에도) 결과창으로 데이터들을 넘겨서 Render하게 된다는 것이다. 즉, URL Manual하게 Typing하는 것을 통해서 결제를 하지도 않았는데 결제가 된 것처럼 결과에 대해서 Hacking을 할 수 있는 것이다.
•
이렇게 원하지 않는 결과를 산출할 수도 있는 Hacking에 대해서는 어떻게 방지할까? → 추가 Validation이 필요하다. Payments를 살펴보면, 결제 날짜, 결제 시 사용한 Email, 총 결제 금액, 결제 방식, 결제를 시도한 사람의 이름 등의 정보를 얻을 수 있다. 데이터베이스에 존재하는 결과에 대한 정보들과 Payments의 정보들을 비교함으로써 위조된 결제가 있는지 Validation을 진행하면 된다. (실제로 큰 회사들에서는 이런 식으로 결제 정보에 대해서 일일이 비교하여 검증을 수행하지는 않는다. 동시에 결제를 진행하는 사람이 많은 경우에 부하가 클 수도 있기 때문이다. 또한 이렇게 Success URL이 문제가 되는 것처럼 실제 많은 결제 대행사들은 Success URL에 대해서 많은 의존성을 두는 것을 지양하라고 권고한다.)
•
실제로 많은 회사들은, 이와 같이 URL Telling을 통해서 결제가 완료 되었다는 것을 알리는 것 말고 Manual하게 Dashboard를 이용하여 결제가 완료되었음을 알리는 방법을 사용한다. 또한 점점 Application의 구조가 커져갈수록 Web Hook을 이용하는 것도 많이 선호되는 방법이다. Web Hook의 경우 Stripe에서 우리가 갖고 있는 Routing이 가능한 URL을 향해서 Request를 보내게 되고, 이 Request를 통해서 결제가 완료 되었음을 알리게 된다. 즉, 결제 대행사에서 보낸 Request를 통해서만 Valid함이 증명되어, 해당 Routing이 Active되기 때문에 Web Hook을 사용하면 Manual하게 URL을 통해서 접속하는 것에 대해서 결제 위조를 방지할 수 있다. (결제에 완료에 대한 Routing을 위해서는 결제 대행사의 특별한 Sign이 동반되어야 한다고 생각하면 된다.) 하지만 이런 Web Hook에 대한 검증은 Local에서는 불가능하다. (Web Hook이 동작하기 위해선 Stripe가 우리가 사용하는 View로 Request를 보낼 수 있어야한다. 즉, localhost IP가 아닌 Public IP로 서비스가 나와 있어야 한다는 것이다.)