Today I Learned

날짜

2024년 4월 29일 월요일

내용

데모스토어의 결제

고객들에게 우리 서비스의 사용 예시를 보여주기 위한 데모버전 스토어가 있다. 이 스토어에선 당연히 우리 서비스에서 유료 플랜을 사용할 때만 접근 가능한 기능들도 보여준다. 따라서 구독 중으로 처리해야 하는데, 결제는 되면 안된다. 굳이 우리가 쓰는 서비스를 결제처리할 이유가 없다.

결제 관련된 로직은 처음 들여다봤는데, 예상과 다르게 처리가 쇼피파이쪽에서 이루어지고 있었다. app_subscribtion으로 처리되고 있었는데, 우리가 결제 간격과 가격 등을 설정하면 됐다. 무료 체험기간, 각 플랜의 이름 등등.. 쇼피파이는 이 설정에 따라 알맞은 때에 결제를 하고 웹훅으로 우리에게 보내준다. 우리가 저장한 데이터는 쇼피파이에 요청으로 보낸 설정과 동일하게 되어있다. 쇼피파이에 요청을 보내고(1) 그대로 우리 서버에도 저장해두는 것. 핵심은, 우리 데이터베이스를 이용해 결제를 처리하는게 아니라는 것과 결국 결제는 쇼피파이쪽에 보내진 데이터에 따라 이뤄진다는 것이다.

데모버전 스토어가 결제가 되지 않도록 우리 데이터베이스에서 무료체험기간을 충분히(몇 년) 늘려놓았는데 그래도 결제가 되고 있었다. 위에서 말했듯, 결제는 쇼피파이쪽에 설정한 값대로 이루어지기 때문이다. GraphQL로 해당 스토어의 결제 정보를 바꿔주었다. 무료체험 기간은 최대 1000일이고, 결제 금액은 0원은 불가능해서 약 3년 뒤 1원이 결제되도록 조정해놨다. 결제를 우리 서버에서 책임질 줄 알았는데 아니여서 놀랐다.

데이터 예외처리

elastic apm은 실서버나 테스트 서버에서 발생하는 오류들을 slack 알람으로 보내준다. 실서버에서 지속적으로 오류가 발생하고 있었는데, 심각한건 아니지만 꽤나 거슬렸다. 분명 테스트서버에서 이상없이 돌아가는걸 확인했는데..

주로 예상하지 못한 데이터가 없거나(shop), 형식이 다르거나(dict가 아닌 str) 중 하나였다. 특히 쇼피파이에서 오는 데이터는 모든 경우를 확신할 수 없으니 좀 더 예외처리를 추가해주었다.

불필요한 에러 알람을 줄여야 elastic apm을 쓰는 의미가 있으니, 간과해선 안되겠다.

회고

다시 Browse Booster로 돌아왔다. 고새 다까먹었다.

---

---