이 문서에는 많은 IAP 관련 규칙, 설계 개발 요점 및 실무 경험이 요약되어 있으며, 제품 요구 사항에 맞게 IAP 및 IAP 지식에 관심이 있는 모든 계획, 상호 작용, 개발, 테스트를 수행할 수 있습니다.
● ● ●
IAP 규칙 세부 정보
이 글에서 설명하는 IAP(In-App Purchase) 는 특히 애플 앱스토어의 앱 내 구매로 애플이 앱 내 가상상품이나 서비스를 구매할 수 있는 거래 시스템입니다.
먼저 IAP 의 기본 규칙과 그 중 몇 가지를 살펴보겠습니다.
1.1 적용 범위
앱 내에서 유료로 사용해야 하는 제품 기능 또는 가상 상품/서비스 (예: 게임 소품, 전자책, 음악, 동영상, 구독회원, 앱의 고급 기능 등).
App 내에서 물리적 상품 (예: 타오바오에서 옷을 사는 것) 을 구입하는 것은 IAP 에 적용되지 않으며, App 내에서 사용하지 않는 가상상품 (예: 충전비) 이나 서비스 (예: 방울방울 차) 도 IAP 에 적용되지 않습니다.
그렇다면 문제는 App 내에서 음악 앨범을 구입하면 App 에서 디지털 앨범을 들을 수 있을 뿐만 아니라 실물 상품 CD 도 받을 수 있다는 점이다. IAP 에 적용이 안 되나요? (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 예술명언)
대답은 적용 가능합니다. 앱 안의 디지털 앨범과 실물 상품 CD 는 사용에서 분리할 수 있기 때문에 디지털 앨범은 IAP 의 적용 범위에 부합하므로 구매하려면 IAP 를 사용해야 합니다. 그렇지 않으면 각종 게임에서 648 을 파는 소품은 상품에는 게임 소품뿐만 아니라 구매 후 5 마오짜리 실물기념품 (예) 을 받을 수 있다고 주장하며 직접 IAP 를 우회하면 애플이 알을 가지고 놀지 않겠는가? (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 게임명언)
애플은 적용 범위 내의 가상상품이나 서비스는 반드시 IAP 를 사용하여 지불해야 하며, 알리페이, 위챗 지불 등 기타 지불 방법 (Apple 종이비행기의 공식 홈페이지에서 다운로드한 방법 포함) 을 사용할 수 없으며, 앱에서 튀어나오는 것, 카피 등을 포함한 어떤 방식으로도 사용자가 외부 채널을 통해 구매하도록 안내할 수 없다고 규정하고 있다.
원칙적으로 애플도 외부 환전 코드 등을 통해 앱 내에서 가상상품이나 서비스를 잠금 해제하는 것을 허용하지 않지만, 실제 환전 코드 제한은 다소 모호하다. 일부 앱은 앱 내에서 환전 코드 (예: 행사 쿠폰 발행 또는 보너스 발급) 를 받을 수 있기 때문에 외부 환전 코드인지 콘텐츠 환전 코드인지 엄격하게 정의하기 어렵다. 따라서 IAP 구매시 쿠폰 공제를 사용하는 것은 일반적으로 허용되지만, App 외부에서 환전 코드를 구매하여 App 내에서 가상상품이나 서비스로 전환하도록 유도하는 것은 애플리제이트가 할 수 있다.
또한 App Store Review Guidelines 3.1.4 에는 다음과 같은 특수 규칙이 있습니다.
"app features that work in combination with an approved physical product (such as atoy) On an optional basis may unlock functionality without using IAP, provided that an IAP option is available as well. "
즉, 사용자가 App 내에서 기능을 구입하는데, 이 기능은 물리적 상품과 함께 사용해야 합니다. 이 경우 IAP 이외의 방식으로 기능을 잠금 해제할 수 있습니다. 단, IAP 구매 옵션을 계속 제공해야 합니다.
예를 들어, 사용자는 건강 관리 App 내에서 고급 타이머 기능을 구입하지만, 이 타이머 기능은 팔찌와 함께 사용해야 하며 팔찌와 함께 포장해서 구입해야 합니다. 이 경우 App 는 IAP 구매 옵션에 기초하여 다른 구매 방법을 제공할 수 있습니다.
그러나 현실에서는 이런 사례가 없는 것을 본 것 같다. App 는 미터기를 무료 기능으로 완전히 바꿀 수 있지만, 손고리가 없으면 실제 효과가 없고, 핸들링은 App 외부에서 사용되는 실물 상품으로 간주되기 때문에 IAP 와 반마오의 관계가 없다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 스포츠명언) 누가 쓸데없이 이 물건을 IAP 로 만들어서 사과를 나눠야 하는 거야 ~
플랫폼 간 동기화의 복잡한 사례도 있습니다. 이 문서의 세 번째 부분에서 더 자세히 설명하겠습니다.
1.2 IAP 유형
앞서 언급했듯이 IAP 는 단순한 지불 시스템이 아닌 상품 거래 시스템입니다. 각 구매 품목은 App 의 itunes connect 백그라운드에 상품을 만들어 Apple 에 제출하여 심사를 통과해야 구매 품목이 적용됩니다.
IAP 상품을 만들 때 선택할 수 있는 네 가지 주요 유형이 있습니다.
1.2.1 Consumable products
이 유형은 게임 소품, 가상 화폐 등과 같이 여러 번 구매할 수 있는 소모형 품목에 적용됩니다.
1.2.2 Non-consumable products
이 유형은 전자책, 게임 수준 등과 같이 영구적이고 유효한 항목을 한 번에 구입하는 데 적합합니다.
이 유형의 프로젝트는 장치 간 동기화 및 로컬 restore 를 지원합니다. 예를 들어, 사용자가 App 에서 책을 구입하면 App 자체의 계정 체계를 사용하지 않고도 동일한 Apple ID 장치의 모든 App 에서 무료로 이 책을 받을 수 있습니다. App 에서 이 책을 삭제해도 무료로 다시 받을 수 있습니다.
1.2.3 auto-renewable subscriptions
이 유형은 Apple Music 의 월별 가입과 같은 자동 갱신 가입 항목에 적용되며, 사용자가 수동으로 취소하거나 개발자가 IAP 항목을 내릴 때까지 사용자가 구매한 후 매월 자동으로 갱신됩니다.
Non-consumableproducts 와 마찬가지로 이 유형은 디바이스 간 동기화 및 로컬 restore 메커니즘도 지원합니다.
이전에는 newsstand 범주 (신문잡지) 의 App 만 지원했고, 2016 년 6 월부터 모든 유형의 App 를 지원했지만, newsstand 범주를 제외한 국내 App 는 이런 유형의 구매를 거의 사용하지 않았습니다.
1.2.4 non-renewable subscriptions
이 유형은 클라우드 음악 회원 및 일부 비디오 앱 회원과 같은 고정 유효 기간 동안 비자동 갱신 프로그램에 적용됩니다. 디바이스 간 동기화 및 로컬 복원 메커니즘이 없으므로 사용자는 여러 번 구매할 수 있습니다.
1.2.5 Free subscriptions
이 유형은 Auto-renewable subscriptions 의 특수한 경우로, 무료 가입 항목에 적용되며, newsstand 범주의 App 만 지원하며, 장치 간 동기화 및 로컬 restore 메커니즘도 지원합니다.
In-AppPurchase Programming Guide 에서는 다양한 유형의 적용 범위 및 기능에 대해 자세히 설명합니다.
특별한 주의가 필요한 것은 다음과 같습니다.
1 Non-consumableproducts 유형의 IAP 프로젝트의 경우 App 는 디바이스 간 동기화 및 로컬 restore 를 지원하는’ 복구 구매’ 기능을 제공해야 합니다. 동시에 App 자체에 사용자 계정 시스템이 있는 경우 사용자는 한 번만 지불하면 restore 메커니즘을 통해 IAP 항목을 여러 사용자 계정으로 무제한으로 복사할 수 있습니다, 구덩이 아버지 ~
따라서 전자책과 같은 한 번의 구매에 영구적이고 유효한 항목의 경우 App 자체의 사용자 계정 시스템을 사용하고 장치 간 동기화 및 로컬 복원 메커니즘을 피하려면 Non-renewable subscriptions 유형을 선택하는 것이 좋습니다. 한편, Non-renewablesubscriptions 는 일반적으로 고정 유효기간이 있다는 점을 감안하면, Apple 감사에 대응하기 위해 무한기간 (예: 9999 일) 을 추가할 수 있습니다.
2Consumable products 와 Non-renewable subscriptions 는 모두 소모품을 선호하는 IAP 프로젝트이며, non-renewable subscriptions 는 구독품을 선호합니다. 또 다른 차이점은 Non-renewable subscriptions 의 IAP 항목에 대해 사용자가 이전에 한 번 구입했거나, 만료 후 다시 구매하거나, App 계정을 전환한 후 구매하면, 지불 프로세스에 이전에 이미 해당 품목을 구입했는지, 다시 구매할지 여부를 알려주는 시스템 팝업 창이 나타납니다. 사용자가 실수로 취소를 취소할 경우 지불하십시오
애플이 이 이 탄창을 설계한 의도는 Apple ID 에 따라 사용자 ID 를 식별하여 사용자가 같은 프로젝트를 반복적으로 구입하지 않도록 하는 것이다. 그러나 사용자 계정 시스템이 있는 App 의 경우, 이 힌트는 다소 불필요하지만, 영향은 크지 않다. 따라서 IAP 프로젝트가 Consumable products 와 Non-renewable subscriptions 모두에 적용되는 경우 Consumableproducts 를 선택하는 것이 좋습니다.
1.3 가격 책정
IAP 프로젝트를 만들 때 가격을 설정해야 합니다. 이 가격은 애플이 사전 설정한 가격 등급에서만 선택할 수 있습니다. 예를 들어 등급 1 은 1 달러, 6 위안, 등급 2 는 2 달러, 12 위안에 해당합니다. 최고 등급 87 은 999.99 달러, 6498 위안에 해당합니다. 또 일부 통화구역의 개발자와 사용자를 돌보기 위해서일 수도 있고, 예비등급 A 는 1 달러, 1 위안, 예비등급 B 는 1 달러, 3 위안과 같은 특별한 등급이 있을 수도 있다. 이 밖에도 IAP 프로젝트는 9.9 위안을 정할 수 없어 어떤 등급에도 맞지 않는 가격이다. 상세한 가격 등급표는 애플의 공식 문서를 볼 수 있다.
애플의 가격 등급표는 보통 조정되지 않지만, 일부 통화환율이 크게 변하는 경우 해당 통화의 가격을 조정하고, 조정하기 전에 애플이 개발자에게 이메일을 보내는 것도 배제할 수 없다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 가격명언)
또한 가격 등급표에서 서로 다른 통화의 환율 관계는 실제 환율과 차이가 있다. 타오바오의 일부 저가 iOS 게임 내 구매는 특정 통화의 환율 차이를 이용해 장사를 하는 것이다.
개발자의 경우, App 가 중국 지역 밖에서 발표되면 환율 문제에 주의를 기울여야 할 수 있습니다. 일부 지역의 내부 구매는 인민폐로 정산된 후 수입이 해당 가격 등급의 인민폐 소득보다 낮기 때문에 실제 수입을 엄격하게 계산해야 하는 경우 (예: 재무통계수익, 또는 매입수익은 플랫폼 CP 측과 더 나누어야 하는 경우), 매입된 실제 지불화폐와 금액 및 그에 상응하는 환율에 따라 수익을 계산해야 할 수도 있습니다. 또는 일부 지역의 내부 구매를 제한하는 몇 가지 방법을 사용할 수도 있습니다 (이 문서의 2.2 절에서 설명).
IAP 품목의 가격은 상품 출시 후 아이튠즈커넥트 배경에서 수정할 수 있으며 시한부 할인가를 설정할 수도 있다고 덧붙였다. 그러나 대부분의 네트워킹 App 의 구매 품목 가격은 자체 서버측에서 얻은 것으로, 가격을 수정하거나 시한부 혜택을 설정하려면 양쪽으로 함께 처리해야 하는데 번거로워요.
1.4 로 나누다
App Store 의 유료 앱과 앱 내 구매는 애플과 개발자가 기본적으로 3/7 로 나눈다는 것을 많은 사람들이 알고 있다.
그러나 실제로 일부 지역에서는 애플과 개발자가 나뉘기 전에 거래세를 공제해야 하며 개발자의 실제 분할이 반드시 70% 는 아니다. 애플은 2015 년 10 월부터 중국 지역의 앱스토어 구매에 대해 거래세 2% 를 공제했고, 중국 구계좌 구매의 IAP 에 대해서는 개발자의 실제 분할이 68%~69% 사이였다. 그리고 중국 이외의 지역마다 거래세 기준도 차이가 있다. 1.3 에서 설명한 바와 같이 실제 수입을 엄격하게 계산해야 한다면 이 부분도 고려해야 할 것 같다.
지역별 구매의 경우, 구매 가격과 해당 개발자의 실제 수입은 애플의 가격 등급표 (1.3 의 링크) 에 상세히 열거되어 있다.
한편 애플의 2016 년 6 월 새로운 규칙에 따르면 Auto-RenewableSubscription 유형 IAP 에 대해 사용자가 1 년 이상 구독을 구매하면 이듬해부터 개발자가 85% 의 구분을 받을 수 있다. 자세한 내용은 다음을 참조하십시오.
1.5 결제
IAP 의 거래수입의 경우 애플은 일반적으로 5 주 (매년 1/4/7/10 월) 또는 4 주 (나머지 월) 를 결제주기로 하고 각 결제주기가 끝난 후 33 일째에 개발자에게 지불한다.
● ● ●
IAP 설계 및 개발 포인트
1. IAP 프로젝트 생성 및 제출
IAP 를 개발하기 전에 itunes connect 백그라운드에 IAP 상품을 만들고 사양에 따라 제품 ID, 상품명, 가격, 스크린샷 등을 기입해야 합니다.
App 의 현재 버전이 새로운 IAP 프로젝트를 지원하는 경우 릴리스하지 않고 IAP 감사를 직접 제출할 수 있습니다. App 의 새로운 기능이 필요한 경우 App 버전과 함께 제출해야 합니다.
IAP 생성 및 제출 프로세스에 대한 자세한 내용은 in-app purchase configuration guide for itunesconnect 를 참조하십시오.
특별한 주의가 필요한 것은 다음과 같습니다.
1.1 이미 만든 IAP 를 삭제하지 않도록 노력하십시오
만든 IAP 제품 id 를 제외한 모든 정보를 수정할 수 있습니다. IAP 를 삭제하면 동일한 제품 id 를 가진 IAP 를 더 이상 만들 수 없으며 제품 id 가 영구적으로 무효화됩니다. 반면 product id 에는 일반적으로 App 내의 구매를 표시하는 특정 명명 규칙이 있습니다. 명명 규칙 아래에 product id 가 영구적으로 만료되면 전체 product id 명명 규칙을 수정하여 구덩이에 빠질 수 있습니다 ~
1.2 참고 reference name 과 display name 을 구분합니다
Referencename 은 개발자를 위한 것으로, display name 은 IAP 지불 프로세스의 구매 확인 시스템 팝업 창에 사용자에게 표시되며 임의로 수정할 수 없으므로 (수정은 IAP 검토를 다시 제출해야 함) 이름을 지정할 때 명확하게 해야 합니다.
1.3 App 검토가 거부된 경우
IAP 가 App 버전과 함께 검토를 제출하면 문제가 있을 경우 새로 제출된 모든 IAP 항목과 App 버전이 동시에 거부됩니다. App 검토를 다시 제출할 때는 모든 IAP 항목을 다시 제출해야 합니다 (다시 제출하려면 각 IAP 를 수동으로 편집해야 합니다). 그렇지 않으면 애플은 감사를 계속할 수 없습니다
2 IAP 지불 프로세스
이 부분은 기능 구현의 논리에 속하며 In-App Purchase Programming Guide 에 자세히 설명되어 있습니다.
개인적으로 제품의 기획이나 상호 작용도 비즈니스 논리를 알아야 개발과 함께 사용자 체험이 좋은 기능 방안을 설계할 수 있다고 생각한다.
특히 IAP 의 지불 모드는 클라이언트 체크섬 서버측 검증의 두 가지 모드로 나뉩니다. 클라이언트 검증 모드는 지불 자격 증명을 위조하기 쉽고 보안이 낮기 때문에 일반적으로 매우 간단한 독립 실행형 App 만 사용하며 대부분의 App 는 서버 측 검증 모드를 사용합니다.
또 다른 유형의 IAP 지불 프로세스에도 약간의 차이 (주로 restore 메커니즘) 가 있을 수 있습니다. 다음은 가장 일반적인 Consumable products 와 Non-renewablesubscriptions 유형을 예로 들어 IAP 의 지불 프로세스를 설명합니다.
사용자가 품목을 구매할 준비가 되면 App 클라이언트는 제품 id 를 통해 애플 API 에 지불 정보를 요청합니다
휴대폰 시스템 팝업 창이 사용자의 Apple ID 를 확인합니다 (Apple ID 비밀번호를 입력하거나 touch ID 를 확인해야 할 수 있음)
Apple ID 검증이 완료되면 Apple API 는 사용자가 지불할 가격과 통화 단위를 app 클라이언트에 반환합니다
App 클라이언트는 product id 에 해당하는 지불 가격과 통화 단위가 올바른지 다시 한 번 확인하고 (생략 가능) 지불을 계속 요청합니다
휴대전화 시스템 탄창은 구매할 내용과 가격을 확인하라는 메시지를 표시하고, 사용자는 클릭하여 구매를 확인한다
App 클라이언트는 Apple API 에서 반환한 지불 성공 알림과 지불 자격 증명을 받고 app 서버측에 지불 자격 증명 확인을 요청합니다
App 서버는 클라이언트의 지불 자격 증명을 받은 다음 Apple 서버에 지불 자격 증명 확인 (일부 탈옥 플러그 인이 클라이언트 지불 자격 증명을 위조하지 않도록 방지) 을 요청합니다. 종이비행기의 중국어 버전 다운로드 주소는 어디에 있습니까
App 서버측에서 지불 자격 증명을 성공적으로 검증하여 App 클라이언트에 알립니다
App 는 후속 비즈니스 로직을 처리하기 전에 사용자를 대신하여 지불 자격 증명 검증 성공 알림을 받습니다
위의 내용은 표준 IAP 지불 프로세스이며, 순리적으로 보이지만 실제로는 많은 구덩이가 있습니다. 주의가 필요한 문제에 초점을 맞추겠습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언)
3 무시할 수 없는 구덩이
3.1 지불 결과 반환 지연
위의 프로세스의 6 단계에서는 네트워크 문제 등으로 인해 사용자가 이미 지불이 성공한 경우에도 클라이언트가 1 시 30 분에 Apple API 의 지불 성공 통지를 받지 못하거나 Apple API 에 지불 상태를 조회하도록 적극적으로 요청하지 못할 수 있습니다. 수동으로만 통지를 기다릴 수 있습니다.
따라서 클라이언트가 지불 성공 알림 (몇 분 후 또는 다음에 App 를 열 때) 을 받을 수 있는 경우가 있습니다. 이 경우 두 가지 작업을 수행해야 합니다.
클라이언트는 지불 결과에 확인되지 않은 모든 트랜잭션 정보를 로컬로 저장하고 지불 성공 정보를 받은 후 이 트랜잭션의 후속 프로세스를 진행할 수 있는 수신 프로세스를 설정합니다. 극단적인 경우 사용자가 거래 결과가 확인되지 않은 상태에서 App 를 삭제하면 App 로컬 데이터베이스에 저장된 거래 정보도 손실됩니다. 따라서 더 좋은 시나리오는 iOS 시스템의 keychain 에 거래 정보를 저장하는 것입니다.
지급 결과가 확인되지 않은 거래 정보가 로컬로 존재하는 경우, 사용자가 지급을 반복하지 않도록 지급 결과를 기다려야 할 수 있음을 사용자에게 대화식으로 알립니다
3.2 서버 측 검증 지연
위의 프로세스 6~8 에 대한 지불 자격 증명 검증 과정에서 네트워크 문제 등 여러 가지 이유로 클라이언트는 서버측의 검증 성공 알림을 제때에 받지 못할 수 있습니다. 이와 유사하게 다음과 같은 상황이 필요합니다.
클라이언트는 지불 자격 증명을 로컬로 저장하고 명시적 검증이 성공하거나 유효하지 않은 결과가 반환될 때까지 검증 결과를 서버측에 계속 폴링합니다. 지불 증명서는 keychain 에도 보관하는 것이 가장 좋다.
클라이언트가 서버에 결과를 폴링할 때 사용자가 지불 결과 페이지에서 너무 오래 기다리지 않도록 상호 작용 수준에서 먼저 지불 프로세스 (일정 시간 초과 후) 를 종료할 수 있으며, 사용자에게 지급 결과를 기다리라는 메시지를 표시하여 사용자가 지급을 반복하지 않도록 할 수 있습니다
3.3 비공식 채널 패키지 지불 실패
위의 프로세스 단계 1 에서 사용자가 설치한 App 가 AppStore 공식 채널 패키지 (PP 도우미, 동기 푸시 등 타사 앱스토어에서 다운로드) 가 아닌 경우 API 는 제품 ID 가 존재하지 않고 지불 프로세스를 종료하여 상호 작용 수준에서 사용자가 구매를 클릭한 후 지불 실패를 직접 알립니다. 이 문제는 오랫동안 우리를 괴롭혔고, 인터넷에서 비슷한 문제에 대한 정보를 찾을 수 없었고, 일지의 매몰점과 사용자 조사 등 일련의 수단을 다 써 버렸고, 결국 찾아냈다.
마찬가지로, 탈옥 장치는 일부 내부 구매 해독 플러그인을 설치한 후에도 내부 구매가 불가능할 수 있습니다 (제품 ID 가 존재하지 않음). 그러나 현재 iOS 장비의 탈옥 비율은 이미 매우 낮아서 기본적으로 무시할 수 있다.
따라서 이 문제에 대한 해결 방법은 반환 제품 ID 가 없을 때 사용자에게 비공식 채널 패키지를 설치하라는 메시지를 표시하여 사용자를 App Store 로 안내하여 공식 채널 패키지를 다운로드하는 것입니다.
3.4 통화 검증
이 문서의 섹션 1.3 에서 설명한 바와 같이 App 가 중국 이외의 지역에 게시되었지만 어떤 이유로 일부 지역 계정의 구매를 제한하고자 하는 경우 위 프로세스의 단계 4 에서 사용자가 지불한 통화 단위를 확인하고 특정 통화의 구매를 금지할 수 있습니다. 동시에 상호 작용에서도 사용자에게 적절한 힌트를 주어야 한다. 특수지역 계정 구매를 지원하지 않는 탄창 설명과 비슷하다.
3.5 App Store 결제 방법이 연결되지 않은 사용자 결제 프로세스
이것은 거대한 구덩이이다!
사용자가 내부적으로 구입하기 전에 App Store 의 결제 방법을 바인딩하지 않은 경우 위의 프로세스의 5 단계에서 시스템 팝업 창 (첫 번째) 을 클릭하여 구매를 확인하면 App Store 의 바인딩 결제 방법 인터페이스로 자동으로 이동합니다. 이어 결제 방식의 바인딩이 성공적으로 완료되면 자동으로 App 로 점프하고 시스템 팝업 창 (2 차) 이 다시 나타나 구매를 확인할 수 있도록 합니다.
그러나 사용자가 시스템 탄창 (첫 번째) 을 클릭하여 구매를 확인하면 애플 API 가 즉시 클라이언트에 지불 실패 … 지불 실패 … 실패 … 일반적으로 클라이언트는 지불 실패 반환을 받고 지불이 취소되었다고 생각하고 현지 거래 정보를 폐기해야 합니다. 하지만 이후 사용자 바인딩 결제 방식이 완료된 후에도 구매를 계속 확인할 줄은 전혀 몰랐습니다. 이것은 애플 IAP 시스템 디자인의 큰 버그입니다!
이 구덩이를 알면 해결 방안도 간단하다. 애플 API 가 지불 실패를 반환할 때 2.3.1 과 같은 방식으로 처리하고, 확인할 거래 정보를 유지하고, 지급 결과 반환을 계속 수신하는 것이다.
● ● ●
더 많은 IAP 실무 경험 요약
1 익명 구매
많은 App 는 App Store ReviewGuidelines 에서 App 가 불필요한 경우 필수 사용자 등록/로그인 후 특정 기능을 사용할 수 없도록 요구하기 때문에 IAP 를 처음 제출할 때 익명 구매가 거부됩니다.
일반적으로 IAP 가 없는 App 의 경우 필수 사용자 등록/로그인이 거부되지 않습니다 (매우 까다로운 검토자가 발생하지 않는 한). 그러나 IAP 의 경우 익명 구매를 지원해야 하는 경우가 많습니다. 물론, 사용자가 등록/로그인을 강요해야 하는 이유 (예: 제공된 상품이나 서비스가 사용자의 휴대폰 번호나 우편함 등을 받아야 하는 이유) 를 설명하기 위해 여러 가지 이유를 편성해 볼 수도 있지만, 감사인을 설득할 수는 없습니다.
익명 구매를 지원합니다. 일반적으로 사용자가 App 계정에 로그인하지 않은 상태에서 사용자의 구매 기록을 임시로 저장하고 사용자가 로그인한 후 App 계정 데이터에 통합해야 합니다.
2 플랫폼 간 동기화
원칙적으로 애플은 외부 채널을 통해 앱에서 유료로 사용할 수 있는 기능이나 가상 상품을 잠금 해제할 수 없다. 예를 들어 웹 측에서 강좌를 구입하여 앱 내에서 시청할 수 있지만, 어떤 경우에는 플랫폼 간 동기화 사용자가 구매한 콘텐츠를 만들 수 있다.
IOSApp 내에서도 해당 상품 IAP 구매가 제공되면 App 계정을 통해 사용자가 다른 플랫폼에서 구매한 콘텐츠를 동기화할 수 있습니다. 이 규칙은 대부분의 게임에 적용되면 비교적 까다로울 수 있지만, 일반 콘텐츠 클래스 App 는 모두 통용된다.
전자책, 음악, 비디오 등 프로젝트의 경우 App 는 단순한 콘텐츠 읽기/보기 기능만 제공하며, Kindle iOS edition 과 같은 콘텐츠 검색 및 가입 기능은 제공하지 않으며, 사용자가 외부 채널에서 콘텐츠를 구입한 후 App 에서 사용할 수 있도록 지원합니다 (특히 app store review guidelines 3 참조) 그러나 실제 허용 여부는 감사인의 판단에 따라 달라질 수 있습니다. 예를 들어 클라우드 교실은 유료 과정을 구매할 수 없는 버전을 제출한 적이 있지만, 사용자가 웹 측에서 유료 과정을 구입한 후 iOS 측에서 볼 수 있도록 허용하면 거부될 수 있습니다. 이는 유료 수업이 위 조건의 내용 범위에 속하지 않기 때문입니다.
3 가상 화폐
IAP 의 가격 등급 메커니즘으로 인해 유연한 상품 가격 (예: 9.9 위안) 및 마케팅 기능 (예: 쿠폰 공제 등) 을 지원할 수 없으므로 많은 App 가 가상 화폐를 도입하여 먼저 IAP 를 통해 특정 가격의 가상 화폐 (예: 6, 12, 18, 648 등) 를 충전한 다음 가상 화폐를 사용합니다
IAP 교차 플랫폼 동기화 문제와 마찬가지로 iOS 플랫폼 충전의 가상 화폐는 다른 플랫폼 (안드로이드, 웹) 과의 유통을 허용하지 않으며, 외부 플랫폼 충전의 가상 화폐는 iOS 플랫폼에서 사용할 수 없으며, iOS 플랫폼 충전의 가상 화폐도 외부 플랫폼에서 사용할 수 없습니다.
그러나 실제로 히말라야 (히말라야) 와 획득, 위챗 공중번호에서 허위화폐를 충전하는 사용자 지원 (위챗 충전도 iOS 플랫폼과 다른 플랫폼을 구분하지만), App 내에서 사용, 그리고 App 내 충전 인터페이스에서, 어렴풋이 사용자에게 충전에 문제가 생기면 위챗 공중번호에서 고객지원서비스를 받을 수 있다는 것을 알 수 있다. (실제로는 사용자가 위챗 사용을 유도하는 것이다. 이런 방법은 엄밀히 말하면 규정에 맞지 않지만, 애플의 심사가 엄격하지 않아도 통과할 수 있다면, 에지볼을 치는 셈인데, 이 수법은 그런대로 괜찮은 것 같다 ~
4 환불 문제
애플 정책에 따르면 사용자는 IAP 구매 후 90 일 이내에 여러 가지 이유로 환불을 신청할 수 있지만 (공제 후 구매 실패, 잘못 구입, 싫어하는 등), 실제로 성공 애플을 환불할 수 있을지는 결정한다.
사용자가 환불을 신청하면, 애플은 개발자와 결제할 때 환불 주문 (물론 원래 구매가 성공한 주문도 있음) 을 기록하고, 돈은 주지 않고, 애플도 어떤 사용자가 환불을 했는지 알려주지 않고, 사용자가 구매한 물건이 아직 있으니, 그야말로 패왕 조건 ~
주문 데이터는 itunes connect 백그라운드의’ 결제 및 재무 보고서’ 에서 볼 수 있지만 자세한 시간 및 사용자 정보가 없어 해당 플랫폼 주문으로 이동하기가 어렵습니다.
게임이나 자영 플랫폼의 경우 수입이 적을 수 있습니다. 플랫폼 CP 측과 일일이 나누어야 하는 제품에는 손해를 볼 수 있습니다. 이 문제를 해결하기 위해 IAP 주문의 기간, 금액, 플랫폼 주문의 일부 정보를 결합하여 IAP 환불 주문을 플랫폼 주문에 할당하는 복잡한 환불 주문 할당 규칙을 설계하려고 했습니다. 플랫폼과 CP 측이 공동으로 환불을 부담합니다. 하지만 개발 일정 때문에 이 방안은 1 년여간 방치해 둔 지 아직 안 했는데 ..全球排名第一오피스타공식 웹 사이트 포털 주소를 찾는 방법. 환불은 모두 플랫폼에서 부담합니다 → _ →
과거 수치로 볼 때 일반적으로 대량의 악의적인 환불이 발생하지 않는 경우 IAP 의 환불률은 1~3% 사이일 수 있습니다 (App 콘텐츠 품질, 사용자 기분, 애플의 기분에 따라 다름). IAP 매출이 많은 App 의 경우 환불 문제를 고려해야 할 수 있습니다.
5 지급 성공률
클라우드 교실은 아이폰 측에서 알리페이/위챗 지불을 사용한 적이 있다. (참고: IAP 를 우회하여 제 3 자 지불을 하는 것은 위반이며, 이로 인해 앱 하차나 개발자가 표지될 수 있으며, 모방해서는 안 된다! ) 및 IAP 의 지불 데이터에 따르면 제 3 자가 지불하는 사용자 지불 성공률이 IAP 의 2~3 배 정도 되는 것으로 나타났습니다. 이는 매출에도 2 배 이상 차이가 난 것으로 나타났습니다.
국내 앱스토어의 사용자 지불 습관이 제 3 자 지불만큼 성숙하지 않다는 것은 이해하기 어렵지 않다. 추가 사용자 설문 조사를 통해 IAP 지불 성공률에 영향을 미치는 요소는 여러 가지가 있습니다.
사용자 설치 App 는 타사 애플리케이션 스토어에서 제공되거나 탈옥 장치를 사용하며 IAP 로 결제할 수 없습니다
사용자가 App Store 결제 방법을 바인드하지 않았습니다
사용자가 IAP 지불 프로세스 바인딩 결제 방식에 문제가 있어 포기했습니다.
위의 데이터는 클라우드 교실의 아이폰 엔드 사용자 기반만을 나타내며, 어떤 의미에서는 클라우드 클래스 사용자가 비교적 소백 (제품 자체의 대상 사용자 대부분이 소백) 이며, IAP 와 접촉하지 않았다는 의미도 있다. 제품별로 대상 사용자 집단의 앱스토어 내 구매 사용 습관에도 차이가 있을 것이다.
하지만 앱스토어 내 구매가 보편화되면서 (게임 내 구매가 추진되고, 애플의 홍보로 인해, 예를 들어 앱 단원 구매 활동을 자주 하고, 2016 년 11 월부터 바인딩 알리페이를 지원하는 등) 사용자 내 구매 습관도 지속적으로 발달하고 있으며, 데이터에서도 IAP 지불 성공률의 상승 추세를 볼 수 있다. 액세스 I
-[특별 추천]-
문자 효과가 좋지 않아요? 이 몇 가지 방법을 시도해 보다
