피드로 돌아가기
I built my own IAP backend instead of using RevenueCat — what 3 weeks of pain taught me
Dev.toDev.to
Backend

RevenueCat 의존성 제거 및 자체 IAP 백엔드 구축을 통한 데이터 소유권 확보

I built my own IAP backend instead of using RevenueCat — what 3 weeks of pain taught me

Lucas2026년 5월 6일4분advanced

AI 요약

Context

RevenueCat 사용 시 발생하는 Revenue Share 비용 부담과 외부 DB 의존성으로 인한 데이터 동기화 오버헤드 발생. 구독 상태 확인을 위해 Webhook 핸들러를 중복 운영해야 하는 아키텍처적 비효율 해결 필요.

Technical Solution

  • Apple StoreKit 2 JWS 검증 시 x5c 체인을 통해 Apple Root CA G3까지 모든 인증서 경로를 검증하는 보안 체계 구축
  • Google Play Developer API v3의 subscriptionState enum을 활용하여 복잡한 상태 추론 로직을 단순화한 상태 머신 설계
  • Apple과 Google의 서로 다른 Grace Period 및 Hold 상태를 통합하여 서비스 권한 제어용 boolean과 UX 노출용 raw state로 분리 관리
  • Google IAP의 3일 이내 acknowledgePurchase 미처리 시 발생하는 자동 환불 이슈를 방지하기 위한 승인 로직 구현
  • Webhook의 유실 가능성을 고려하여 API 직접 호출(Pull)을 기본 경로로 설정하고 Webhook을 빠른 업데이트를 위한 Fast Path로 활용하는 하이브리드 동기화 전략 채택

실천 포인트

- IAP 구현 시 단순 페이로드 디코딩이 아닌 전체 인증서 체인(x5c) 검증 여부 확인 - Google Play API v1 대신 subscriptionState enum을 제공하는 v3 사용 검토 - Webhook 단일 의존성을 지양하고 서버 API를 통한 상태 재검증(Polling/Fetch) 로직 필수 포함 - 구독 상품의 acknowledgePurchase 호출 누락으로 인한 자동 환불 가능성 체크

태그

#StoreKit 2#JWS#IAP#State Machine#Webhook
원문 읽기