IAP 검증

http://www.jeremyfuller.net/2012/04/handling-iap-on-your-server-using-c/

 

도움되는  관련 글 

Advertisements

iTunes Connect Developer Guide [ In-App Purchase ] section

원문

IAP 의 관리는 App Summary 페이지의 Manage In-App Purchases  버튼을 클릭하여 이루어짐. 이 버튼은 계정이 어드민, 기술 역할 등에 할당되었을 때 ‘보여진다’

About In-App Purchase

스토어-킷 을 통해 구현한다. 스토어-킷은 당신의 앱을 대신하여 앱 스토어에 연결하고, 결재를 위한 UI 제공,  ..

>> 추가적인 성능
>> 북 리더앱의 새 책.
>> 게임의 뉴 레벨
>> 온라인 게임에서의 가상 특성 구입
>> turn-by-turn 맵 서비스 접속
>> 전자 잡지 / 뉴스레터

앱내구매를 앱에서 구현하려면 ‘최신 Paid Applications contract’ 가 유효하고, 팀 요원이 프로그램 라이센스에 동의해야 함.
애플에 리뷰를 위해 보내기전에, 모든 앱내구매는 ‘아이튠즈 커넥트’ 에 등록되고 샌드박스 환경에서 테스트 되어야 한다.

Registering In-App Purchases

무료/유료 앱에 적용 가능.  제품은 먼저 ‘아 – 커넥트’에 등록되어야 함. 등록 시 ‘이름, 설명, 가격’ 와 다른 메타 데이터 추가.
제품은 ‘product indentifier’ 라는 유니크한 문자로 구별함. 앱이 스토어킷을 사용 시 이 ‘구별자’ 를 사용.
당신은 앱내구매를  ‘생성, 수정, 삭제’ 할 수 있고 리뷰를 위해 애플에 제출할 수 있다.
앱내 구매에는 10,000 개 까지 다른 ‘구별자’를 생성할 수 있다. 이것은 거래 숫자가 아님.
앱 서머리 페이지에서 생성 시작할 수 있다.

Creating In-App Purchases

>> Log into iTunes Connect
>> Manage Your Applications
>> Click the App
>> Manage IAP click  (이 버튼이 보이지 않으면 계약에 동의하지 않은 것임)
>> Create New
>> Select Type .. consumable, Non-consumable, Auto-Renewable Subscriptions, Free Subscription, Non-renewing subscription
>> Fill out the form
>> Click Save.  앱내 구매가 ‘관리’ 페이지에서 보인다.

Entering In-App Purchase Information

표 12-2 의 내용 입력.

>> Free Subscription form [ 언어 추가, 스크린 샷 … ]

>> Non-Renewable Subscription or Consumable form..

Table 12-2 Common IAP properties
Reference Name, Product ID < unique UTF-8 alphanumerical identifier > Not editable, Pricing and Availability, Languages, Review Notes < for Apple review >, Screenshot

Privacy Policy URL input…

Testing Your IAP

샌드박스 환경 -> 금융 결재 발생 안함.  앱 스토어를 이요하지만 결재 하지는 않음. 실제 결제와 동일한 값 리턴.  앱내구매에 한정된 특별한 ‘아-커넥트’ 계정 사용.  일반 계정은 샌드박스에서 쓸 수 없음.

Creating Test User Accounts

커넥트를 이용하여 1개 이상의 테스트 계정 생성. 각 언어에 대하여 1개 이상의 계정 생성해야. 테스트 유저 계정은 새롭고, 유니크한 애플 계정이어야하고, 기존 계정을 이용할 수 없다.
어드민, 기술 역할로 어사인 되어 있어야 생성 가능. ‘커넥트’ 에 접근 불가, 하지만 앱내구매에서 테스트 가능. 개발 환경의 등록된 테스트 기기에서만..

>> Log into iTunes Connect.
>> Manage Users..
>> Click Test User.
>> Add New User.

<<주의>> 실수로 테스트 유저 계정으로  (테스트 환경 대신) 기기에서 제품 환경에  로그인하면, 테스트 계정은 invalid 되고 다시 사용할 수 없게 됨.

Using Test User Accounts

#1. 테스트 유저 계정 셋업. 아이디(이메일), 비번 입력.
#2. 테스트 기기의 계정 정보 초기화 할것. 테스팅 중에 실제 계정이 쓰일 염려때문.
<< 주의 >> 테스트 계정 정보를 ‘스토어 세팅’ 패널에서 넣지 말것. 이것은 테스트 계정을 폐기할 수 있음.
#3. 샌드박스에 대비한( against ) 기능을 테스트하려면 기기를 개발 웤스테이션에 연결하고 기기를 Active SDK 로 선택할 것.
#4. 앱이 스토어킷 API 를 통해 결재를 요청할 때, 결재 확인 창이 뜨고 Sign In 패널이 또 뜬다. ‘Use Existing Account’ 선택하고 테스트 유저네임과 비번을 넣은 후 구매 테스트를 완료함. 금융거래는 일어나지 않지만 영수증을 포함한 완전한 구매가 생성. 테스트 계정에는 신용카드정보가 없으므로 실제 금융 거래는 일어나지 않음.

Sandbox Testing Your IAP

애플에 리뷰를 위해 제출하기 전에 샌드박스 환경에서 테스트 해야 함. 샌드박스로 테스트 하기 전에 아이튠즈 계정에서 로그 아웃 해야 함. 테스트 유저 계정을 테스트 디바이스에서 로그인 하면 계정이 폐기된다.
오토-리뉴어블 앱내구매를 테스팅할 때는 지속 시간이 짧아진다. 부가적으로 샌드박스 제출은 6번 까지만 ‘오토-리뉴’ 된다.

Submitting Your In-App Purchases

새로 만든 ‘앱내구매’를 다음 바이너리 업로드 때 써밋 할 지, 지금 바로 리뷰에 들어갈 지 결정해야 한다.
첫번째 앱내구매는 앱 버전과 같이 제출되어야 한다. Version Details 페이지에 해야 한다. (적어야 한다) 바이너리가 업로드 되고, 첫번째 앱내구매가 리뷰에 들어간 후 추가적인 앱내구매는 앰내구매 ‘관리’ 뷰의 테이블을 통해 제출될 수 있다.
바이너리와 함께 서밋하려면 Version Details Page 에서 선택해야 한다.
스크린 샷에서 에디트 를 클릭하여 어느 놈이 리뷰되야 하는지 선택한다.
세이브. 바이너리와 함께 제출되었다.
대규모 제출도 가능.  제출할 놈을 체크.. Ready to Submit 으로 만든다.   “Submit for Review” 클릭..
<개별 제출> 앱내구매 페이지에서 개별적으로 제출 가능. “Ready to Submit” 에서 “Waiting for Review” 로 바뀌고 즉시 리뷰를 위해 보내진다.

Tracking Your IAP Status

제출한 후에는 “Waiting for Review” 로 상태가 바뀐다. 리뷰를 기다리는 동안 수정이 가능하다.

“In Review” 로 바뀜. 수정 불가.이 상태에서는 삭제도 불가.

“Approved” 바이너리 없이 …. 암튼 완료..

바이너리와 함께 제출하기로 선택했다면, 애플에서 심사 후에 앱 심사가 끝날 때까지 approved 가 안 나옴.
리뷰 과정에서 앱내구매가 리젝되면 애플에서 연락이 간다.  커넥트의 Contact Us 를 통해 물어볼 수 있다. 리젝되면 다시 만들어야 한다.

IAP plugin 설명..

일단 iTunesConnect 에서 제품 셋업을 하고 테스트 유저 1 ~ 2를 생성하면 테스트 할 준비가 된 것.

씬에 StoreKitManager.cs 스크립트가 연결된 게임 오브젝트가 있어야 한다.

네이티브 코드로 부터의 콜백함수는 그 클래스의 메소드를 부를 것이다.

애플은 구매를 ‘초기화’ 하기 전에 먼저 ‘리트리브’ 하는 앱들을 리젝 시켜왔다.

사용자에게 구매를 허용하기 전에 항상 requestProductData 를 불러주도록.

Server Product model Overview Image

스토어킷은 비동기적으로 이루어지므로 실패 유무의 콜백 함수를 유심히 봐야 한다.

중요한 함수는  productPuchased()  임..  이것이 오면 구매가 원활히 이루어진 것임.

StoreKitManager 네이티브로부터의 콜백을 모두 노출함.

[ storeKitEventListener ] 프리팹을 당신의 씬에 가져다 놓으면 미리 연결된 함수를 통해 모니터링 가능하다.

Xcode 의 로그를 보는 것이 가장 도움이 됨.

또한, StoreKitManager  프리팹은 처음 로딩 씬에 추가되어 있어야 함.

아래는 애플의 가이드라인.  다음의 이유로 product identifier 가 in valid 로 리턴될 수 있음.

# 테스팅 하지 않는 애플 아이디는 완전히 로그아웃 할 것.. ( 세팅 -> 스토어 -> 사인 아웃 )

# 금융 동의에 완전히 서명하지 않음.

# 적당한 ‘제품 아이디’를 쓰지 않음.

# IAP 제품을 for sale 로 클리어 하지 않음.

# 제품 수정이 모든 서버에 전파 되지 않았음.

# 아이튠즈 커넥트의 제품을 리젝했음.

# 앱 리뷰가 준비될때까지 바이너리를 업로드 하지 말것.  개발용 바이너리가 있으면 리젝될 것임.  방법은 :: 앱내구매 없이 올려서 승인을 받고,  바이너리가 승인을 받으면 앱내구매 기능을 테스트 한다. ??

앱내구매 테스트 팁

# 번들 아이디를 유니티 /   Xcode 에서 이중 체크 할 것.

# 프로비저닝 파일 유효

# 테스트 유저만 아이튠즈 커넥트 포탈을 사용할 것.

# 테스트 사이에는 앱을 지울 것..  requestProductData 로부터 데이터를 받을  수 있으므로.

샘플소스는 작동 안될 것임.. 참고용.

IAP (2) Making a purchase

Making a Purchase

Collecting Payment

결재를 위해 어플이 payment object 생성하여 페이먼트 큐에 ‘큐’ 한다. 그림 3-1 참조.
서버에서 paymentQueue:updatedTransaction 을 받음..
Payment 가 생성되면 persistent transaction 생성하여 갖고 있음. 지불한 후에 transaction 이 업데이트 되고 어플에서 이것을 반영하는 옵서버 구현.   옵저버는 사용자에게 구매한 아이템 제공하고 큐에서 transaction제거.

SKPayment

결재는 payment object 에서 시작.  PI와 수량 포함. 같은 객체를 한번 이상 ‘큐’ 가능. 각각은 다른 결재로 인식.
유저는 세팅에서 구매를 비활성 시킬 수 있다. 구매를 큐하기 전에, 어플은 구매가 진행될 수 있는지 확인해야 함.  [paymentQueueu :: canMakePayment] 메서드를 통해.

SKPaymentQueue

앱 스토어와 통신하는 객체. [payment]가 큐에 추가되면 스토어킷은 앱 스토어에 요청 전송. 스토어킷이 사용자가 결재를 확인하는 대화상자 제공. 완성된 결재는 옵서버에 리턴함.

SKPaymentTransaction

구매 시 생성. 어플이 transaction 의 상태를 결정하도록 하는 속성을 갖고 있다. 결재가 성공하면 성공에 관한 디테일 정보를 담는다. 큐에 지연된 액션을 물어볼 수 있지만, 옵서버가 기다리는 게 일반적.

SKPaymentTransactionObserver 프로토콜

어플이 구현하여 옵서버에 등록. 옵서버의 주된 임무는 완성된 액션을 검사하고 구매한 아이템을 유저에게 전달하며 큐에서 제거.
사용자가 아이템 구매를 시도할 때까지 기다리기 보다,  어플 런칭 시 큐와 옵서버와 연결되어 있어야 한다. 어플이 끝날 때 트랜잭션은 잃지 않음. 다음에 런칭할 때 스토어 킷은 트랜잭션 재개.  어플 초기화 시 옵저버 추가는 모든 트랜잭션이 어플에 돌아왔는 지 확인한다.

Restoring Transactions

액션이 진행되서 큐에서 제거되면 다시 볼 수 없다. 하지만, 어플이 결과를 저장해야 할 속성이 있으면 그 인터페이스를 구현해야 한다. 이 인터페이스는 다른 기기에 제품을 추가할 수 있으며, 기기가 지워지면, 원 기기에서 거래를 복구할 수 있다.
스토어킷은 비-소비성 제품, 오토-리뉴어블 구독,  프리-구독 에 대해 빌트-인 복구 기능 지원.
트랜잭션을 복구하려면 당신 어플은 큐의 restoreCompleltedTransactions 메서드 콜. 큐는 앱 스토어에 복구위한 요청을 보냄. 앱스토어는 새로운 트랜잭션 복구를 생성. 복구 트랜잭션 객체의 originalTransaction은 원래의 정보를 담고 있다.  어플에서는 이것을 통해 구매한 아이템을 풀어준다.  스토어킷이 복구를 마친 후 큐 옵서버에 paymentQueueRestoreCompletedTransactionsFinished: 메서드를 보낸다.

유저가 복구가능한 아이템을 구매하려고 하면  (당신이 구현한 복구 인터페이스 대신) 보통 트랜잭션을 받는다. 하지만, 유저는 같은 아이템에 대해 다시 과금 받지는 않는다. 당신 어플은 이 액션을 원래 액션과 똑같이 취급해야 한다.

넌-리뉴잉 구독, 소비성 제품은 복구되지 않는다. 하지만, 넌-리뉴잉은 복구되야 한다. 이것은 당신 서버에서 알아서 해라.

In App Purchase 매뉴얼..

In-App Purchase Programming Guide

Overview of In-App Purchase

Product

팔고 싶은 특성 모두. iTunes Connect 를 통해 새로운 앱을 만들때 처럼 연결.  4가지 방법. & 컨텐트 : 전자첵. 잡지, 사진, 아트웤, 게임레벨, 케릭 등등  어플에 배달 가능한 컨텐트. & 기능 : 이미 구현되어 있는 기능을 언락 / 기능 확장. & 서비스 : 1회성 서비스에 대해 과금. 음성 받아적기 등. & Subscriptions : 확장에 기반한 컨텐트/서비스 접속. 금융 정보에 1달간 접속 가능, 온라인 게임 포털에 접속 가능… 등.. 제품 설계 시 중요한 가이드라인. > 실제 제품 판매에는 사용하지 말것. > 전자머니를 나타내는 아이템을 제공하지 말라.. 사용자가 특정 아이템/서비스를 구매하는 것으로 아는 것이 중요 > 포르노, 도박, 혐오 에 관련되지 않도록..

Registering Products with the App Store

모든 아이템은 iTunes Connect 를 통해 먼저 등록 되어야 함.  이름/설명/가격 이 있어야 함. 특정 제품을 <product identifier> 라는 스트링으로 구별할 수 있다. 스토어킷을 이용하면 제품에 제공한 데이터를 가져올 때 PI 를 사용. 나중에 고객이 구매하고자 할 때, 어플은 PI 를 이용하여 그 제품이 구매된 것인 지 구별한다. 앱 스토어가 제공하는 제품의 종류 > Consumable : 매번 사야 하는 것. 1회성. > Non-consumable : 특정 유저가 한번만 구매.  모든 디바이스에 적용. 스토어킷은 이러한 기능 제공. > Auto-renewable subscriptions : 앞의 것처럼 모든 기기에 적용. subscription 의 기간 선택. 당신의 앱이 유효한지 안한지 책임진다. 가장 최근의 결재를 업데이트… > Free subscriptions : 뉴스 스탠드에 무료 자료. 폐기되지 않고 ‘뉴스 스탠드’ 가능한 앱에서만 사용 가능. > Non-renewing subscriptions : 제한된 기간을 갖는 제품. 오토-리뉴어블 과 다른 점. >> 아이튠즈커낵트에 제품 생성 시 섭스크립션 이란 단어가 선언되지 않음. 당신의 앱이 제공. 보통 제품 설명에 포함. >> 넌-리뉴잉 은 여러번 구매할 수 있다. 앱스토어에 의해 자동으로 ‘리뉴’ 되지 않음. 리뉴얼 프로세스를 앱 안에서 구현해라. >> 넌 리뉴잉  을 모든 기기에서 보여줘야. 자동으로 싱크되지 않음.

Feature Delivery

Buil-in / sever model..

Built-in Product Model

앱 내부에 모든 것이 이미 구현. [풀어 주는] 기능. 즉시 제공 가능. 대부분은 non-consumable.. *** IAP 는 결재 성공 후 어플을 패치하는 것은 하지 않음. 어플의 번들에 변화가 필요하면 업데이트된 버전을 앱스토어에 배달해야 함. 제품을 구별하기 위해 당신의 어플은 PI를 번들에 저장. Plist 를 권장. 컨텐트 주도 어플은 소스를 바꾸지 않고 새로운 컨텐트를 추가 가능. 구배 성공 후 언락하고 기능을 제공해야 한다. 가장 쉬운 방법은 preferences 를 바꾸는 것..  Implementing Application Preferences어플 프레퍼런스는 백업 된다. 유저에게 백업하라고 추천할 수도 있음.  도표 참조..

Server Product Model

당신이 제품을 공급할 서버를 운영.  게임 등에서는 뉴 레벨 등을 배달 가능. 스토어 킷은 어떤 것도 제공하지 않음. 당근.. 특정 유저를 구별하는 메카니즘도 제공 안 함.  도표 참조 …

## 사용자 스토어에서 아이템 선택 -> 어플이 앱 스토어에 결재 요청 전송 -> 앱 스토어 결재한 후 결재완료 리턴 -> 어플이 영수증 받고 서버로 보냄 …
—-> ** 서버가 앱 스토어로 확인 영수증 데이터 보냄. -> ** 앱 스토어가  영수증이 유효한지 확인한 후 영수증과 확인 되었는지 보냄 -> 서버가 반환된 영수증을 통해 구매 물품 확인 -> 서버가 구매 물품 어플에 전달.

애플은 서버로부터 PI를 받는 것을 추천.. plist에 저장은 비추.. >> 업데이트 없이 물품 추가하는 유연성 제공.

서버가 영수증을 받고 물품 확인 하는 절차.. Verifying Store Receipts..

서버 모델은 추가적인 보안, 신뢰성 부가… 보안코딩 가이드 참조할것..

Non-consumable 제품은 스토어 킷의 기능을 이용해 회복 가능하지만, non-renewing 제품은 당신의 서버에 저장되야 한다. 이 정보를 저장하는 것은 네 책임이다. Consumable 제품 역시 당신 서버에 의해 추적가능하다.  이 제품이 서버에 의해 제공되는 것이면, 사용자가 각 기기에서 수습하게 할 수 있다.

Retrieving Product Information

어플이 스토어를 보여줄 준비가 되면, 앱 스토어로부터의 정보를 UI 에 덧붙여야 함.  이 장은 앱 스토어에 제품 디테일을 요청하는 방법에 관한 것임.

Sending Requests to the App Store

스토어 킷은 요청하는 메카니즘 제공.  request 객체를 생성, 초기화 딜리깃을 붙이고 요청 시작. 시작하면 앱 스토어에 전달. 앱 스토어가 요청을 실행하면 딜리깃이 비동기적으로 불려서 결과를 전달함.

SKRequest : abstract base class

SKRequestDelegate : protocol  : 구현할 부분. 성공/실패 에 대하여

Requesting Information About Products

어플은 제품에 대해 로컬 정보를 얻기 위해 products request 를 사용.
어플이 product identifier string 의 리스트를 포함하는 request 를 생성. 앞에서 설명한대로 어플은 PI를 어플 내부에 임베드하거나 혹은 서버를 통해 갱신할 수 있다.  request 를 시작하면 identifier string 이 앱 스토어에 넘겨진다. 앱 스토어가 iTunes Connect 에서 입력한 로컬화된 정보로 응답한다. 이 디테일로 당신 스토어의 UI에 덧붙여라.

##** 중요 : 제품 구매를 허락하기 전에 특정 제품 identifier 를 요청해야 함. 앱 스토어로부터 제품 정보를 갱신하므로 제대로 된 제품을 파는 것을 보장할 수 있음.

SKProductsRequest

product identifier 의 리스트와 함께 생성.  상점에 진열될..

SKProductsRequestDelegate  프로토콜

상점으로부터의 반응을 받기 위해 구현.  요청이 성공되면 대답을 받음.

SKProductsResponse

스토어에 의해 인식되지 않은 PI의 리스트 뿐만 아니라 원래 요청의 유효한 PI 마다 하나의 SKProduct 객체를 갖고 있음. 스토어는 여러 이유로 식별하지 못할 수도 있음 : 오타, 판매 불가로 표시,  iTunes Connect 에서의 변경이 모든 앱 스토어 서버로 전달되지 않아서.

SKProduct

앱 스토어에 등록한 제품에 대해 로컬 정보를 제공함.

Address Book Programming Guide..

http://developer.apple.com/library/ios/#documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/Chapters/QuickStart.html

주소록 관련 기술은 다음 4가지 기술로 이루어져 있슴.

# Address Book Framework (ABF)는 연락처에 대한 접근을 제공함.
#  AB UI Framework. 은 유저 인터페이스 제공
# AB Database 는 자료 저장
# Contact Application

Quick Start Tutorial

AB, AB UI 프레임워크 추가.
ABPeoplePickerNavigationControllerDelegate 사용
ABPeoplePickerNavigationController .. 모달 뷰로 띄우기.

ABRecordCopyCompositeName 사용해서 이름 전체 보여주기. 이름과 성의순서를 사용자가 정한대로 보여줌. 일관성 있슴.

- (BOOL)peoplePickerNavigationController:(ABPeoplePickerNavigationController *)peoplePicker
      shouldContinueAfterSelectingPerson:(ABRecordRef)person
{
    NSString* name = (NSString *)ABRecordCopyValue(person, kABPersonFirstNameProperty);

프로토콜에 한 메서드 더 필요. 연락처의 어떤 속성을 선택했는지 알 필요가 있을 때. 이 앱은 사람만 선택하면 그냥 닫히므로 그냥 리턴하는 함수만 둠.

Building Blocks

주소록을 다루기 위해 알아야 할 4가지 객체..

address books, records, single-value properties, and multivalue properties

Address books

ABAddressBookRef  객체 생성,  ABAddressBookCreate 의 리턴을 받음. 여러 쓰레드에서 사용 불가.

ABAddressBookSafe ; 저장..
ABAddressBookHas UnsavedChanges ; 변한게 있는지..

체인지 콜백..

Records

연락처 또는 그룹을 표시. kABPersonType / kABGroupType

레코드 객체는 쓰레드 간 전달 불가.. 레코드 식별자 사용.

Person Records, Group Records

Single Value ; 이름 등의 단일 값
MultiValue ; 여러 값 저장

Properties