문제: 베타테스터가 스토어 프로모션 코드로 결제했는데 S코인을 받지 못했고, 영구히 실패하는 영수증은 앱을 켤 때마다 서버로 재전송됐다. 결정: 서버가 "다시 보내도 소용없다"는 신호( terminal )를 응답에 싣고 실패한 영수증을 거부 기록으로 남겨 재전송을 끊었다. 막힌 정당한 결제는 예외 규칙과 수동 적립으로 구제했다. 결과: 영구 실패 영수증을 재전송하면 그 다음부터 terminal 응답을 받고 앱이 더 보내…
서비스를 고도화하는 작업을 진행하면 할수록 초기에 잘 동작하는 것처럼 보였던 설계가 발목을 잡는 순간이 온다. 최근 우리 서비스의 결제 및 가격 구조를 개편하면서 이 사실을 다시 한번 느꼈다. 기존에는 콘텐츠마다 가격을 따로 정할 수 있게 설계돼 있었다. 그런데 출시를 앞두고 프로모션을 기획해야 하는 시점이 오자 이 구조가 기술 부채로 돌아왔다. 이 글에서는 흩어진 가격 데이터를 SSoT(Single Source of Truth, 단일 진실 …
문제 안드로이드와 영수증 형식이 전혀 다른 iOS(StoreKit 2 JWS)를 같은 원칙, 같은 지급 로직 위에 올려야 했다. 결정 JWS는 로컬에서 풀어 값싼 사전 거절에만 쓰고, 진위는 App Store Server API 조회로 판단한다. 플랫폼별 검증은 따로 두고 재화 지급은 공통 함수 하나로 모았다. 대가 결제마다 애플 서버 왕복이 필요하고, 플랫폼별 검증 코드라는 유지보수 대상이 하나 늘었다. 결과 두 플랫폼이 같은…
문제 클라이언트가 "결제했다"고 알리면 그대로 재화를 주는 구조는 패킷 변조나 재전송 한 번으로 무너진다. 결정 클라이언트는 Purchase Token만 넘기고, 서버가 Google Play Developer API로 직접 검증한 뒤 Firestore 트랜잭션 밖·안 이중 체크로 한 번만 지급한다. 대가 결제마다 스토어 API 왕복이 한 번 늘고, 대기(Pending) 결제와 환불은 이 설계 범위 밖에 남았다. …
Our website uses cookies to improve your experience. Learn more
확인