In App Purchase (2)

✔ Apple 기준으로 작성된 글입니다. 변경사항이 있을 수 있으니, 공식문서를 꼭 확인해주세요.

 

이번에는 조금 자세히 Client와 Server 그리고 Store가 어떻게 동작하는지 살펴보겠습니다. 현재 진행 중인 프로젝트 기준으로 설계되었지만, 서버를 통한 서비스를 제공하는 앱이라면 대부분 비슷하게 구현될 것이라고 생각합니다.

 

Consumable 상품의 내부 프로세스는 아래와 같습니다.

 

IAP Consumable Process

 

보시다시피 인앱결제 이벤트가 발생하고 종료되는 시점까지 총 13번의 과정으로 이루어져 있습니다.

결제 과정이 복잡해 보이지만, 클라이언트에서는 사실 크게 신경 쓸 부분이 없습니다. 결제 라이브러리가 워낙 잘 되어있기도 하고 인앱결제의 핵심인 영수증 검증은 백엔드에서 이루어집니다.(검증 단계에서 클라이언트는 응답 결과에 대한 처리만 담당합니다.)

 

내부 프로세스를 크게 3단계로 나누고, 'Reqeust Products' 단계부터 시작하겠습니다. (사진 참고)

 

• phase(1) Reqeust Products
• phase(2) Reqeust Purchase
• phase(3) Validating Receipt

 

1. Request Products

'상품 요청' 단계는 사용자가 상품 목록을 확인할 때 이벤트가 발생합니다.

 

 

a. App Store Connect에 상품 등록

상품 목록을 스토어에 요청하기 전, 각 스토어에 판매 상품 등록이 우선 선행되어야 하며,
등록된 각각의 상품들은 고유 ID(product id) 가지게 됩니다. (id는 직접 지정합니다.)

b. 서버에 상품 목록 요청

서버 역시 스토어와 동일한 product id에 대한 목록이 있어야 합니다.
클라이언트는 Store에 product id를 전달해 상품 목록을 조회합니다.

c. 상품 고유 ID로 스토어에 상품 요청

현재 App Store에 있는 모든 상품 목록을 가져오는 방법은 없으며, 상품 id를 사용하여 product request를 해야 합니다.
상품 id 목록을 자체적으로 관리하지 않으면 스토어에 등록된 상품 정보를 요청할 수 있는 방법이 없다는 얘기인 것 같습니다.
만약 상품 id 목록을 클라이언트에서 관리한다면 나중에 상품이 추가됐을 때, 앱을 업데이트 해야하는 상황이 생기겠죠..?

애플에서는 다음 경우에 해당했을 때, 상품 id를 앱에 저장하도록 권장합니다.

• IAP 상품들의 리스트가 고정되어 있는 경우 (상품 갯수가 한정적이고 정적)
• 사용자가 새로운 IAP 상품을 사용하려면 앱을 업데이트해야 하는 경우
• 앱, 상품이 서버를 필요로 하지 않는 경우

저희는 서버를 사용하고 나중에 상품이 변경됐을 때를 대비해서 서버에 저장하도록 합니다.
아래는 FE에서 구현된 코드 예제입니다.

우선 스토어 연결 상태 확인 후, 

 

서버 API를 통해 받아 온 상품 id로 스토어에 상품 목록을 요청합니다. 

 

d. 상품 목록 UI에 표출

만약 사용자가 아래 이미지의 수강권 선택 목록들을 확인했다면, 이미 a~c의 프로세스를 거친 이후입니다.

 

 

이 단계에서는 서버와의 작업은 이루어지지 않습니다.
서버와의 작업은 다음 포스팅인 'Reqeust Purchase' 단계부터 시작됩니다.

 

---

[참고]
https://pub.dev/packages/in_app_purchase