Original

In-App Purchase Programming Guide

번역

About In-App Purchase

In-App Purchase allows you to embed a store inside your app using the StoreKit framework. This framework connects to the App Store on your app’s behalf to securely process payments from users, prompting them to authorize payment. The framework then notifies your app, which provides the purchased items to users. Use In-App Purchase to collect payment for additional features and content.

• ‘인앱구입’은 나의 앱에 StoreKit을 사용해서 하나의 스토어를 만드는 것입니다. 이 프레임워크는 사용자가 안전한 결제를 하기위해 앱을 대신하여 앱스토어에 연결하여 결제승인을 요청합니다. 그리고 앱에 알려주고, 구입한 아이템을 사용자에게 제공합니다. 추가 기능과 컨텐츠의 구입목록을 위해 인앱구입을 사용합니다.

For example, using In-App Purchase, you can implement the following scenarios: 예를 들어, 아래 시나리오를 구현할 수 있습니다.

A basic version of your app with additional premium features

• 프리미엄 기능이 있는 기본 버전 앱

A magazine app that lets users purchase and download new issues

• 사용자가 구입하고 새 항목을 다운로드 할 수 있는 잡지 앱

A game that offers new levels to explore

• 새로운 맵 제공하는 게임

An online game that allows players to purchase virtual property

• 플레이어가 가상 자산을 구입하는 온라인 게임

At a high level, the interactions between the user, your app, and the App Store during the In-App Purchase process take place in three stages, as shown in Figure I-1.

• 사용자, 나의 앱, 앱스토어가 인앱구입을 3단계로 처리하는 동안 서로 상호작용합니다.

First, the user navigates to your app’s store and your app displays its products.

• 먼저 사용자는 나의 앱안의 스토어로 들어가고 나의 앱을 상품을 표시합니다. Second, the user selects a product to buy and the app requests payment from the App Store.
• 두번째로, 사용자는 상품을 선택하고 구입합니다. 그리고 앱은 앱스토어로부터 결제를 요청합니다. Third, the App Store processes the payment and your app delivers the purchased product.
• 세번째로, 앱스토어는 결체를 처리하고, 나의 앱으로 구입된 상품을 전달합니다.

sequenceDiagram
    participant YourApp
    participant AppStore
Note left of YourApp: first
    YourApp->>AppStore: 상품정보 요청
    AppStore->>YourApp: 상품정보 제공
    YourApp-xYourApp: 상품을 UI로 표시
Note left of YourApp: second
    YourApp->>YourApp: 사용자가 상품을 선택
    YourApp->>AppStore: 결제 요청
    AppStore->>AppStore: 결제 진행
    AppStore->>YourApp: Observer 호출
    YourApp-xYourApp: 상품 전송

Preparing for App Review

After you finish testing, you’re ready to submit your app for review. This chapter highlights a few tips to help you through the review process.

• 테스팅이 끝나고 나면 앱리뷰를 준비해야합니다. 이 챕터의 몇가지 팁이 리뷰프로세스를 통과하는 도움이 될겁니다.

Submitting Products for Review

제품 리뷰 제출하기

The first time you submit your app for review, you also need to submit in-app products to be reviewed at the same time.

• 검토를 위해 앱을 처음 제출하는 경우, 동시에 검토할 인앱 제품을 제출해야합니다. After the first submission, you can submit updates to your app and products for review independently of each other.
• 첫번째 제출후, 앱과 제품에 대한 업데이트를 제출하고, 앱과 제품을 독립적으로 검토할 수 있습니다. For more information, see In-App Purchase Configuration Guide for iTunes Connect.

Receipts in the Test Environment

테스트환경에서 영수증 발행하기

Your app runs different environments while in development, review, and production, as show in Figure 8-1.

• 개발하고 리뷰하고 판매하는 환경이 다릅니다.

• Testing
  • Development 사인된 앱 -> 개발자의 테스트 서버 -> 애플의 테스트 서버
• App Review
  • Production 사인된 앱 -> 개발자의 판매 서버 -> 애플의 테스트 서버
• Production
  • Proudction 사인된 앱 -> 개발자의 판매 서버 -> 애플의 판매 서버

During development, you run a development-signed version of your app, which connects to your development servers and the test environment for the App Store. In production, your users run a production-signed version of your app which connects to your production servers and the production App Store. However, during app review, your app runs in a mixed production/test environment: it’s production signed and connects to your production servers, but it connects to the test environment for the App Store.

• 개발하는 동안 development-signed 버전이 동작합니다. 개발서버와 앱스토어 테스트 서버에 연결하겠지요. 프로덕션할 때는, production-signed 버전이 동작하고 앱스토어 판매서버와 개발자의 판매서버에 연결합니다. 그러나 리뷰하는 동안은 실제와 테스트 환경이 섞여있습니다.

When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment.

• 서버가 영수증을 처리할 때, production-signed앱에서 애플의 테스트 환경의 영수중을 받아서 처리할 수 있어야합니다. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production”, validate against the test environment instead.
• 프로덕션 서버가 앱스토어 프로덕션에 대한 영수증을 항상 먼저 확인하는 것이 좋습니다. ‘프로덕션환경에서 사용되는 Sandbox 영수증’에러코드를 사용하여 실패한 경우는, 테스트환경에서 검사하세요.

Implementation Checklist

Before you submit your app for review, verify that you’ve implemented all of the required behavior. Make sure you’ve implemented the following core In-App Purchase behavior (listed in order of a typical development process):

• 앱 리뷰를 제출하기 전에, 필요한 것들을 다 구현했는지 확인바람. 다음 핵심 인앱구매 이벤트를 구현했음을 증명하세요.

• Create and configure products in iTunes Connect. You can change your products throughout the process, but you need at least one product configured before you can test any code.

  • iTunes Connect에 상품을 생성하고, 설정하세요.
  • 프로세스를 통해서 상품을 변경할 수 있지만, 테스트 하기전에 적어도 하나의 프로덕트를 설정해야합니다.

• Get a list of product identifiers, either from the app bundle or your own server. Send that list to the App Store using an instance of SKProductsRequest.

  • 앱번들 또는 자체 서버를 통해서 상품ID 목록을 받아오세요. 그리고 SKProductsRequest의 인스턴스를 사용해서 상품ID 목록을 앱스토어에 보냅니다.

• Implement a user interface for your app’s store, using the instances of SKProduct returned by the App Store. Start with a simple interface during development, such as a table view or a few buttons. Implement a final user interface for your app’s store at whatever point makes sense in your development process.

  • 앱스토어에서 반환된 SKProduct인스턴스를 사용해서 인앱 UI를 구현하세요. 개발하는 동안은 간단한 인터페이스로 시작하세요.
  • 그리고나서 앱스토어에 대한 최종 UI를 구현합니다.

• Request payment by adding an instance of SKPayment to the transaction queue using the addPayment: method of SKPaymentQueue.

  • addPayment를 사용해서 트랜잭션 큐에 SKPaymnet 인스턴스를 추가해서 결제를 요청하세요.: SKPaymentQueue 메소드

• Implement a transaction queue observer, starting with the paymentQueue:updatedTransactions: method. Implement the other methods in the SKPaymentTransactionObserver protocol at whatever point makes sense in your development process.

  • paymentQueue:updatedTransactions: 로 시작하는 트랜잭션큐 옵저버를 구현하세요.
  • SKPaymentTrascationObserver 프로토콜의 나머지 메소드를 구현하세요. 개발 프로세스에 맞게 잘.

• Deliver the purchased product by making a persistent record of the purchase for future launches, downloading any associated content, and finally calling the finishTransaction: method of SKPaymentQueue. During development, you can implement a trivial version of this code at first—for example, simply displaying “Product Delivered” on the screen—and then implement the real version at whatever point makes sense in your development process.

  • 나중에 실행했을 때를 위해 구입한 내용을 기록하고, 관련 컨텐츠를 다운로드하고 finishTransaction: 함수를 호출하여 구입한 항목을 전달합니다.
  • 개발하는 동안 임시 버전으로 “Product Delivered"라고 간단하게 표시하고 실제 버전에서는 프로세스에 맞게 잘 구현하세요.

If your app sells non-consumable items, auto-renewable subscriptions, or non-renewing subscriptions, verify that you’ve implemented the following restoration logic:

• Provide UI to begin the restoration process.
• Retrieve information about past purchases by either refreshing the app receipt using the SKReceiptRefreshRequest class or restoring completed transactions using the restoreCompletedTransactions method of the SKPaymentQueue class.
• Let the user re-download content.

If you use Apple-hosted content, restore completed transactions and use the transaction’s downloads property to get an instance of SKDownload.

If you host your own content, make the appropriate calls to your server.

If your app sells auto-renewable or non-renewing subscriptions, verify that you’ve implemented the following subscription logic:

• Handle a newly-purchased subscription by delivering the most recently published piece of content—for example, the latest issue of a magazine.

• When new content is published, make it available to the user.

• When a subscription expires, let the user renew it. If your app sells auto-renewable subscriptions, let the App Store handle this process. Don’t try to handle it yourself. If your app sells non-renewing subscriptions, your app is responsible for this process.

• When a subscription becomes inactive, stop making new content available. Update your interface so the user has the option to purchase the subscription again, re-activating it.

• Implement some system to keep track of when content was published. Use this system when restoring purchases to give the user access to the content that was paid for, based on the periods of time the subscription was active.