모바일 게임 결제(IAP)에 관한 내용 정리

인디팀을 구성한 후 게임을 힘들게 완성시켰었다.
출시 하기전 IAP를 앱에 적용하기 위해 고민했던 내용과 결론에 대해 말하려고 한다.

우선 비소비형 아이템으로 구성된 게임의 경우에는 결제 서버를 넣지 않는 경우가 있다.
(비소비형 아이템은 길건너친구들(초창기를 말하고 바꼈는지는 모름)과 같이 케릭들을 결제를 통해 구입할 수 있지만 물약과 다르게 소비하지 않고 하나 이상 구매할 수 없게 구성된 게임을 말함. 아이템 구매시 구매 여부를 구글서버에서 저장하고 있기때문에 해당정보를 통해 클라내에서 복구해줄수 있음.)

유저가 아이템을 구매후 문제가 생겨 복구를 해줘야 할때 클라자체에서 해결할수 있기 때문이다.

하지만 소비형 아이템을 가진 게임의 경우에는 클라에서 해결해주기가 애매하다.
경험을 해보시거나 평점댓글에서 보신 적이 있으실 건데 "결제했는데 아이템이 안들어 왔어요" 와 같은 문제를 해결해 줘야 하는데 보통 이런 문제는 서버와 DB를 사용해야 한다고들 말한다.

그 이유가 Java의 dex파일, C# dll파일이 해킹에 취약하기 때문이다.
(나중에 이부분에 대해 글을 쓰려고 한다.)

각종 결제 해킹 방법에 대해 클라에 적용해봤자 단순(난독화 X)하게 구성되어있을수록 초심자도 쉽게 우회하거나 무력화 시킬수 있기때문이다.
Java로 구성되어있으면 쉽고 C#으로 구성되어 있으면 좀더 귀찮은 정도의 차이가 있긴하다.

하여간 유저의 항의와 해킹때문에 결제 서버가 있어야 된다고 결론이 났다.
(해킹에 대해서는 무시하고 유저의 항의에만 대응하는 방법으로는 무조건 환불이라는 방법도.....)

그래서 서버는 어떻게 구성해야 할까?
이전에 이미 개발을 해봐서 직접 구성하는 것에는 문제가 없었다.
하지만 직접 결제서버를 구성하는게 귀찮은 일이고(또한 IOS는 해본적도 없다) 유저의 정보를 DB로 관리하는 것또한 작은 프로젝트, 인디팀에서는 선택하기 껄끄럽다고 생각했다.

내가 내린 결론은 이렇다.
결제관련은 TOAST IAP를 사용 - 결제 해킹에 대한 것은 모두 이것으로 해결(클라 IAP에셋을 구매할 필요도 없어짐)
결제 오류 유저에 대한 대응 - TOAST IAP 로그 확인 후 환불
유저 정보(젬같은) - 암호화한 후 클라에 저장
간단한 결제로그를 저장할수 있는 DB서버
(TOAST에 로그 작성후 아이템을 발급하는 형식이기 때문에 이부분에서 오류가 발생해도 결제는 성공했지만 아이템을 발급받지 못하는 경우가 엄청나게 낮은 확률로 발생할수도 있다. 이런 경우에도 환불을 해주면 되긴 하지만 유저가 거짓말을 하는 경우가 있을수도 있다. 그리고 계속 반복하는 경우에 어떻하지?라는 고민에 빠졌다. 그래서 여기에 DB를 추가해 아이템 발급로그를 남기도록 했다. 아이템 발급로그가 없을때만 환불을 해주기로 했다. DB서버를 구성했음에도 유저 정보를 클라에 저장하는 것은 서버를 최대한 단순하게 구성하기 위함이다.)

참고) http://cloud.toast.com/service/iap