앱 내 구입을 위한 App Store Server API 살펴보기

안녕하세요 ‘앱 내 구입을 위한 App Store 서버 API 살펴보기’에 오신 것을 환영합니다 저는 App Store 서버 팀의 Alex입니다 그리고 저는 Ian입니다 저도 App Store 서버 팀 엔지니어입니다 이 세션에서는 App Store에서 이용할 수 있는 앱 내 구입용 서버 API에 대해 알아보겠습니다 서버 API의 활용 사례들을 소개해 드리면서 온디바이스 코드만 사용했을 때의 한계를 뛰어넘는 가능성을 발휘하는 법을 보여 드리겠습니다 세션의 제 부분에서는 App Store 서버 API에 추가되는 새로운 기능을 자세히 설명하겠습니다 이미 서버를 운영 중이신 분도 이제 막 시작하신 분도 흥미를 느끼실 수 있을 겁니다 다룰 내용이 많으니 시작해 보겠습니다 앱 개발자라면 App Store Connect가 익숙하죠 앱의 설정과 제품을 구성하는 데 사용하는 서비스죠 StoreKit도 잘 알고 계실 겁니다 앱 내 구입 기능을 앱에 추가할 때 사용하는 기술입니다 이 두 가지 기술도 필수적이지만 앱 내 구입을 한 단계 더 발전시키기 위해 활용할 수 있는 세 번째 기술이 있습니다 바로 App Store 서버입니다

App Store 서버는 세 가지 중요한 부분으로 구성되어 있으며 App Store 서버 API에서 시작됩니다 App Store 서버 API를 사용해 내 서버에서 App Store 서버로 요청을 할 수 있습니다 이를 통해 거래에 대한 정보를 쿼리할 수 있습니다 또한 구독 갱신 날짜 연장과 같이 해당 거래와 관련된 정보를 제출할 수도 있습니다

App Store 서버 API의 엔드포인트 중 4개를 사용하면 고객의 거래 내역을 가져오는 등 거래에 대한 정보를 얻을 수 있습니다 추가로 5개의 엔드포인트는 환불 및 고객 만족에 관한 것으로 환불 결정 과정에 참여하기 위한 소비 정보를 전송할 수 있습니다 마지막 3개의 엔드포인트는 App Store 서버 알림을 위한 거죠 이러한 엔드포인트를 통해 테스트 알림을 트리거하고 알림 내역을 확인할 수 있습니다

모두 합쳐 총 12개의 App Store 서버 API 엔드포인트는 2023년에 지원이 중단된 Verify Receipt 엔드포인트를 대체하고 그 이상의 기능을 제공합니다 App Store로 호출할 수 있는 엔드포인트를 살펴보았습니다 App Store 서버 알림을 사용하면 App Store가 서버를 호출합니다 App Store 서버 알림으로 App Store는 내 서버에 거래 업데이트를 사전에 알릴 수 있습니다

App Store는 구독 라이프사이클의 업그레이드 또는 갱신과 같은 이벤트를 서버에 알릴 수 있습니다 또한 알림은 환불이 발생한 시기를 알려 주는 등의 환불 라이프사이클에도 적용됩니다

다음은 App Store Server Library입니다 App Store Server Library는 App Store 서버 API와 App Store 서버 알림 사용을 위한 기반입니다 App Store Server Library는 App Store 서버와의 통합을 간소화하도록 만들어졌습니다

App Store 서버 API용 클라이언트를 제공하여 이러한 엔드포인트 사용을 아주 쉽게 시작할 수 있습니다

서명된 데이터 검증 기능이 내장되어 기기, App Store 서버 API 또는 App Store 서버 알림의 데이터를 검증하고 디코딩할 수 있습니다 또한 이 라이브러리는 지원이 중단된 영수증에서 거래 정보를 추출하여 지원이 중단된 Verify Receipt 엔드포인트와 Original StoreKit 클라이언트 프레임워크에서 전환할 수 있는 경로를 제공합니다

또한 프로모션 특가 서명을 간단하게 생성할 수도 있습니다

작년에 저희는 프로덕션에 바로 사용할 수 있는 1.0 버전을 Java, Python, Node.js, Swift 4개의 언어로 선보였습니다 App Store 서버 API를 이러한 언어에서 사용할 때 App Store Server Library를 사용하시는 것을 권장합니다 시작하려면 각 언어에 해당하는 패키지 관리자를 통해 라이브러리를 다운로드합니다

라이브러리의 또 다른 장점은 오픈 소스라는 것입니다! 피드백을 제출하고 풀 리퀘스트를 열어 주세요 GitHub의 저희 사이트에 가입해서 성장하는 개발자 커뮤니티의 구성원이 되어 라이브러리에 기여해 보세요

App Store Server Library 사용과 설정에 대한 자세한 내용은 WWDC23 세션 ‘App Store Server Library 알아보기’를 참고하세요 이제 App Store 서버의 기초를 설명해 드렸으니 오늘 세션의 세 가지 핵심 주제로 넘어가겠습니다 제가 각 주제에 대한 모범 사례를 몇 가지 공유한 다음 Ian이 새로운 기능을 공유하겠습니다 먼저 구입 라이프사이클을 살펴보고 Ian이 App Store 서버 알림의 새로운 기능을 소개할 것입니다 다음으로 콘텐츠 전달과 서버 관점에서 이 워크플로를 다루는 법을 설명하겠습니다 그런 다음 Ian이 이 영역의 개선 사항을 공유할 것입니다 마지막으로 구독과 특가 영역의 새로운 개발 사항을 공유하고 이러한 거래에 사용할 수 있는 새로운 필드를 Ian이 다루겠습니다 먼저 구입 라이프사이클에 대해 알아보겠습니다

다양한 유형의 앱 내 구입을 간략하게 살펴보겠습니다 비소모품이란 한 번 구매하면 평생 이용할 수 있는 제품을 가리킵니다 소모품은 이름에서 알 수 있듯이 고객이 원하는 대로 사용하여 소진하고 다시 구매할 수 있습니다 소모품의 예로는 게임 내 아이템 구입에 사용할 수 있는 보석 100개 팩이 있습니다

비갱신 구독도 소모품과 비슷합니다 기간이 끝나면 고객이 다시 구입할 수 있습니다 자동 갱신 구독은 일정에 따라 갱신되는 표준 구독입니다 갱신 또는 해지 시에 재구입할 수 있습니다 이상 앱 내 구입 유형을 다시 요약해 드렸습니다 이제 구입 라이프사이클에 대해 자세히 알아보기 위해 소모품 구입의 예를 살펴보겠습니다 고객이 앱에서 소모품을 구입하면 워크플로가 시작됩니다

고객의 기기는 서명된 거래를 수신하고 앱은 이를 서버로 전송하여 거래의 유효성을 검사하고 콘텐츠를 제공합니다 또한 App Store 서버는 ONE_TIME_CHARGE 알림을 동일한 서명된 거래를 사용해 내 서버로 보냅니다 일반적으로 이 단계에서 구입의 주기가 끝나고 고객은 다른 소모품을 구입할 준비가 됩니다 하지만 고객이 구입에 대해 환불을 요청하면 어떻게 될까요?

이 지점에서 App Store 서버는 내 서버에 CONSUMPTION_REQUEST 알림을 보내 고객의 제품 사용에 대한 정보 제공을 요청합니다 Send Consumption Information 엔드포인트를 호출하면 해당 정보를 제공할 수 있습니다 제출한 정보는 Apple의 환불 결정 절차에서 고려됩니다

Apple에서 환불을 승인하거나 거부하면 서버에 결과를 알려 주는 REFUND 또는 REFUND_DECLINED 알림이 전송되요

이 워크플로의 후반부는 다소 까다로워 보일 수 있지만 App Store Server Library가 도움이 될 것입니다 App Store Server Library로 소비 요청 워크플로를 구현하는 한 가지 방법이 여기 있습니다 이 예시에서는 Java를 사용하지만 이 라이브러리는 Node Python, Swift on Server에서도 사용할 수 있습니다

먼저 SignedDataVerifier와 AppStoreServerAPIClient를 생성해요 간결한 설명을 위해 인수는 생략하겠습니다 다음으로 최근에 알림을 받았으며 서명된 페이로드가 signedNotification 변수에 문자열로 저장되어 있다고 해 보겠습니다 다른 알림과 마찬가지로 페이로드 확인과 디코딩에 SignedDataVerifier를 사용하고 디코딩된 객체를 알림 변수에 저장합니다

이제 이 경우 NotificationType이 CONSUMPTION_REQUEST와 동일한지 확인하고 동일한 경우 해당 유형에 적합한 로직을 진행합니다

알림의 데이터 객체에서 signedTransactionInfo를 가져와서 String에 저장합니다 그런 다음 SignedDataVerifier를 사용해서 서명된 거래를 추출하고 확인한 뒤 transactionId를 변수에 저장해요 다음으로 엔드포인트로 전송할 consumptionRequest 객체를 작성해요 이 객체에 맞는 값을 결정하는 방법은 서버 구현과 현재 진행 중인 거래에 따라 달라집니다

여기에 포함된 몇 가지 예시 값은 샘플 콘텐츠가 고객에게 제공되었고 콘텐츠가 Apple 플랫폼에서 소비되었음을 나타냅니다

consumptionRequest 객체를 구성한 다음 Send Consumption Information 엔드포인트 호출에 앞서 만든 apiClient를 사용합니다 transactionId와 consumptionRequest를 전달합니다 예외가 발생하지 않으면 데이터가 잘 제출된 것입니다 이것이 바로 App Store Server Library를 사용해 소비 요청 워크플로를 처리하는 방법입니다 Ian, 이 영역의 새 기능에 대해 알려 주시겠어요? 물론이죠 구입 및 환불 처리 개선을 위한 몇 가지 새로운 기능이 추가되었습니다 먼저 일회성 청구 알림이 있습니다 Alex가 소모품 구입 워크플로 예시에서 포함시켰던 것이죠 이 새로운 알림은 앱 내 제품의 일회성 구입에 대해 전송됩니다 이제 누군가가 앱에서 소모품 비소모품 또는 비갱신 구독을 구입하면 서버가 알림을 수신합니다

이는 기존의 알림 유형에 추가되는 것으로 신규 구입 및 자동 갱신 구독의 갱신에 대한 알림에 추가되는 알림입니다 일회성 청구와 함께 이러한 알림을 수신하면 서버는 앱에서 발생하는 고객의 모든 구입을 최신 상태로 유지할 수 있습니다

이 새로운 알림은 오늘부터 샌드박스에서 이용 가능하며 테스트에 사용할 수 있습니다

올해 말에는 프로덕션 환경에서 사용할 수 있을 것입니다

다음은 디코딩된 ONE_TIME_CHARGE 알림 예시입니다 notificationType이 ONE_TIME_CHARGE입니다

디코딩된 거래 정보에는 앱 내 구입에 대한 모든 관련 데이터가 있습니다

이 예에서는 고객이 보석 100개의 소모품 팩을 구입했습니다 구입 시 appAccountToken을 제공했다면 해당 토큰을 여기에서 찾을 수 있습니다 이 값을 사용하여 서버의 어떤 고객 계정이 구입을 했는지 파악할 수 있습니다 이를 통해 이 알림에 제공된 데이터만 사용하여 이 구입에 대한 콘텐츠를 즉시 잠금 해제할 수 있습니다 이제 App Store 서버 API를 호출하거나 기기에서 호출을 기다릴 필요가 없습니다 구입 라이프사이클에서 환불은 중요한 부분 중 하나입니다 Alex가 말했듯이 소모성 앱 내 구입에 대한 환불을 요청하면 오늘 CONSUMPTION_REQUEST 알림이 전송됩니다 Send Consumption Information 엔드포인트를 호출해 응답할 수 있습니다 Alex가 말했듯이요 하지만 앱에서 자동 갱신 구독을 제공한다면 어떻게 해야 할까요? 사용자가 환불 결정 과정에 더 많이 관여할 수 있도록 이제 자동 갱신 구독에 대해 제출된 환불 요청에 대해서도 CONSUMPTION_REQUEST 알림을 보냅니다

ConsumptionRequestReason이라는 새로운 필드가 모든 CONSUMPTION_REQUEST 알림에 포함됩니다 이 필드에는 고객이 앱 내 구입에 대한 환불을 요청한 이유를 명시합니다

이 CONSUMPTION_REQUEST 알림은 자동 갱신 구독에 대해 전송되는 알림의 예시를 보여 줍니다

새 필드 consumptionRequestReason은 고객이 환불을 요청한 이유를 나타냅니다 이 예에서는 고객이 의도치 않게 구입을 했네요

CONSUMPTION_REQUEST 알림에 응답하는 절차도 업데이트되었습니다 Send Consumption Information을 호출하면 구입자의 제품 사용에 대한 컨텍스트 정보를 제공합니다 하지만 구입자가 의사 결정 과정에 더 적극적으로 참여하기를 원해요 따라서 이제 환불 허용 또는 거부에 대한 기본 설정을 Send Consumption Information 호출 시 제출할 수 있습니다

CONSUMPTION_REQUEST 알림의 새 consumptionRequestReason 필드를 사용해 선호 사항을 전달합니다 제출된 선호 사항과 기타 소비 데이터는 최종 결정 과정에서 고려될 것입니다 이제 Alex의 코드를 토대로 App Store Server Library를 이용해 이러한 새 기능 사용법을 보여드리겠습니다 알림을 디코딩하고 거래 정보를 가져오는 코드는 변경되지 않았습니다 하지만 이제 알림 데이터에 새로운 ConsumptionRequestReason이 포함됩니다

환불 수락 또는 거부에 대한 선호 사항을 표현하려는 경우 자체 로직에 따라 해당 사항을 결정할 수 있습니다 예를 들어 여기에 determineRefundPreference라는 커스텀 메서드 호출을 포함시켰습니다 이러한 메서드에서는 다른 데이터와 함께 소비 요청 이유와 거래를 고려할 수 있습니다

끝으로 ConsumptionRequest 객체에서 refundPreference를 설정하고 이전과 마찬가지로 App Store 서버로 전송합니다 다 됐습니다! App Store Server Library를 사용하면 코드 몇 줄만 추가하여 새로운 기능을 통합할 수 있습니다

소비 정보를 전송하는 것은 환불 프로세스에서 더 큰 역할을 할 수 있는 한 가지 방법입니다 하지만 여러분의 가장 큰 역할은 애초에 환불 요청이 발생하지 않을 원활한 구입 경험을 제공하는 것입니다 이를 위한 한 가지 방법은 앱을 사용하는 사람들이 구입한 콘텐츠에 즉시 액세스할 수 있게 하는 것입니다 Alex, 이 주제에 대해 조언해 주시겠어요? 좋은 질문입니다, Ian 콘텐츠 제공에 대한 모범 사례를 몇 가지 공유하겠습니다 먼저 서버를 통한 콘텐츠 전송 워크플로가 어떻게 이루어지는지 알아 보겠습니다 일단 고객이 앱 내 제품을 구입하는 것으로 시작됩니다 구입이 이루어지면 앱이 서명된 거래 정보를 서버로 전송합니다 여기서 사용자에게 제품에 대한 액세스 권한이 부여됩니다 예를 들어 소모품의 경우 사용자의 게임 내 화폐 잔액을 서버에서 업데이트할 수 있습니다 기기의 앱에 다시 신호를 보내 거래에 대한 콘텐츠 제공이 승인되었음을 알립니다 그러면 앱에서 거래를 완료로 표시합니다 거래를 완료로 표시하면 콘텐츠가 제공되었으며 고객이 다른 구입을 할 준비가 되었음을 App Store에 알립니다

콘텐츠 제공 단계에 집중해 보겠습니다 서버를 통해 콘텐츠를 제공하는 모범 사례들 몇 가지를 소개합니다 서버 제어는 여러분만이 수행하는 것이므로 고객이 액세스할 수 있는 콘텐츠의 유일한 출처가 되어야 합니다 서명되지 않은 데이터가 기기에서 또는 기기와 서버 간에 수정될 수 있으므로 시스템에서 고객이 소유한 것을 확인하는 과정에서 기기를 신뢰해서는 안 됩니다 또한 서버는 콘텐츠 제공에 대한 전적인 책임이 있으므로 어떤 콘텐츠가 제공됐는지에 대한 유일한 출처가 되어야 합니다 서버가 온디바이스 거래에 대한 콘텐츠를 제공하면 앱은 App Store 서버에 완료 신호를 보내 표시해야 합니다 그러나 거래의 완료 상태를 콘텐츠 제공의 지표로 사용해서는 안 됩니다 콘텐츠를 여러 번 제공하거나 아예 누락시킬 수 있기 때문입니다

서버가 서명된 거래를 획득한 위치에 관계없이 콘텐츠를 제공하기 전에 서명의 유효성을 검사해야 합니다 App Store Server Library를 사용하면 이를 쉽게 할 수 있습니다 서버는 모든 콘텐츠의 제공을 담당하므로 최상의 고객 경험을 제공하기 위해 새 거래와 업데이트된 거래를 빠르게 파악하는 것이 중요합니다 서버가 거래를 놓치지 않도록 하는 방법에는 여러 가지가 있습니다 모든 신규 및 업데이트된 거래를 기기에서 서버로 전송합니다 앱에 App Store 서버 알림 V2를 활성화합니다 고객이 앱을 사용하지 않을 때 발생하는 갱신 같은 구입을 포함해 모든 구입이 알림으로 전송됩니다 이를 통해 기기에 의존하지 않고도 고객의 구입을 파악하는 것이 가능합니다 StoreKit을 사용하여 서버가 고객에 대해 구입 시점에 생성하는 appAccountToken을 설정합니다 구입에 대한 App Store 서버 알림을 받으면 이 값을 사용하여 기기가 없어도 포함된 거래 데이터를 고객에게 연결할 수 있습니다 또는 구입을 놓쳤다고 생각하는 이유가 있는 경우 App Store 서버 API의 Get Transaction History 엔드포인트를 사용해 고객의 기록을 가져와 누락된 거래 업데이트가 있는지 확인할 수 있습니다

App Store Server Library를 사용해 getTransactionHistory 엔드포인트를 호출하는 방법입니다 앞서와 같이 apiClient가 있고 고객에게 속한 transactionId가 있다고 가정합니다 고객의 transactionId 하나로 전체 거래 내역을 가져올 수 있습니다

다음으로 요청을 구성하겠습니다 이 엔드포인트는 다양한 필터와 정렬 옵션을 지원합니다 마지막 수정 날짜를 기준으로 거래를 오름차순으로 나열하도록 지정하겠습니다 엔드포인트의 응답을 저장할 HistoryResponse 변수를 만들고 서명된 거래를 저장할 List와 수정본을 저장할 String을 만들죠 이 사용자에 대한 엔드포인트 호출은 이번이 처음이므로 revision은 null이어야 합니다 이 사용자의 거래 기록을 가져온 적이 있다면 가장 최근의 HistoryResponse에서 revision을 제공하여 새로 업데이트된 거래만 가져올 수 있습니다

요청을 하기 위해 transactionId를 전달하고 이전 요청에서 반환되었다면 해당 revision과 요청 객체도 전달합니다 응답에서 서명된 모든 거래를 출력 목록에 추가합니다 revision 변수를 업데이트하면 다음 거래 세트를 가져올 준비가 되었습니다

이 엔드포인트는 페이지가 매겨져 있으므로 응답에 더 이상 거래가 없을 때까지 엔드포인트를 호출하는 코드를 반복합니다 응답의 HasMore 필드가 false로 표시될 때까지요

루프가 완료되면 고객에 대한 모든 거래의 목록이 생기며 앞서 살펴본 것처럼 SignedDataVerifier로 디코딩할 수 있습니다 그런 다음 목록을 검토하여 새 거래와 업데이트된 거래를 확인하고 콘텐츠 전달과 같은 적절한 조치를 취할 수 있습니다 이것이 App Store Server Library로 Get Transaction History를 사용하는 방법입니다 정말 멋지네요, Alex 정말 그 엔드포인트로 모든 거래를 가져올 수 있나요? 정확히는 아닙니다 이 엔드포인트는 기기에서 환불, 취소 또는 완료되지 않은 소모성 거래만 반환합니다 엔드포인트가 처음 도입된 이래로 항상 그랬습니다 업데이트할 때도 됐죠 오늘 Get Transaction History의 새 버전을 출시합니다 엔드포인트 버전 2는 지정된 고객에 대한 모든 거래를 반환합니다 제품 타입, 환불 상태 또는 완료 상태에 상관 없이요 고객 거래의 진정한 전체 이력을 가져올 수 있어 완전히 새롭게 활용할 수 있습니다 가령 고객에게 전체 구입 내역을 보여주는 데 사용하거나 단일 고객에 대한 서버 측 구입 항목을 새로 고칠 수도 있습니다 서버에서 누군가의 남은 소모품 양을 감사하여 모든 지출이 완전히 최신 상태인지 확인할 수도 있습니다

Get Transaction History의 새 버전은 원래 버전처럼 같은 데이터를 모두 반환하는 등 다양한 기능이 있어요 따라서 원래 버전은 이제 지원이 중단됩니다

새 엔드포인트는 원래 버전과 상당히 유사하므로 마이그레이션이 간단합니다 URL 경로의 버전을 V2로 업데이트하고 완료된 소모성 거래를 서버가 처리할 수 있도록 준비만 하면 모든 준비가 완료됩니다 새 버전의 Get Transaction History는 한 가지 방법이 여기 있습니다

Alex의 코드를 다시 살펴보면 엔드포인트에 대한 호출만 바뀌었죠

새 버전 매개변수를 통해 호출할 엔드포인트 버전을 선택합니다

이전과 마찬가지로 응답에서 거래 목록을 채울 수 있지만 이제 서명된 거래 목록에 모든 소모품이 포함된다는 점을 유의하세요

이것이 거래 기록에 대한 최신 정보입니다 하지만 완전한 거래 내역이 완전히 비어 있다면 무슨 소용이 있을까요? 많은 거래를 생성하는 방법 중 하나는 앱에서 자동 갱신 구독을 제공하는 것입니다 신규 구독자를 유치하고 기존 구독자를 유지하려면 꾸준한 노력이 필요하지만 그만한 가치가 있습니다 Alex, 도움이 될 수 있는 옵션을 소개해 주시겠어요? 물론이죠! 다음에는 구독과 특가에 대해 그리고 특가를 사용해 고객을 구독 제품으로 불러들이고 유지하는 방법에 대해 설명하겠습니다 자동 갱신 구독에 사용할 수 있는 세 가지 결제 모드부터 시작하겠습니다

특가를 생성할 때 구성할 수 있는 결제 모드는 여러 가지가 있습니다 그 중 하나는 고객에게 무료 체험판을 제공하는 것입니다 무료 체험판은 고객이 비용을 지불하기 전에 서비스를 사용해 보도록 유도할 수 있는 좋은 방법입니다 또는 분납 결제 모델에서 2개월 반값 할인과 같이 고객에게 할인을 제공할 수 있습니다

마지막으로 고객에게 일정 기간을 미리 결제하면 할인해 주는 선불 결제 옵션을 제공할 수 있습니다 다양한 결제 모드를 살펴보았으니 이제 다양한 특가 유형 차례입니다 먼저 신규 구독 프로모션입니다 신규 구독 프로모션은 구독 그룹에 새로 가입하는 구독자에게 적용되는 프로모션입니다 이러한 프로모션의 요건과 배포는 Apple에서 처리하므로 고객이 해당 프로모션을 사용한 적이 없는지 확인합니다 다음은 프로모션 코드입니다 고객에게 배포하여 앱에서 프로모션을 사용할 수 있는 코드입니다 코드가 지정된 횟수만큼만 사용되도록 Apple에서 보장하며 코드를 배포할 고객은 판매자가 결정합니다

다음은 프로모션 특가입니다 기존 고객을 유지하거나 이탈한 가입자의 재가입 유도에 사용할 수 있는 프로모션입니다 이는 온디바이스로 제공되며 자격 해당 여부는 여러분이 전적으로 결정하실 수 있습니다

마지막으로 새로운 윈백 특가 유형입니다 서비스를 떠난 고객에게 표시해 고객 재유치에 사용할 수 있습니다

이 새로운 특가 유형에 대한 자세한 내용은 WWDC24 세션 ‘App Store 특가 구현하기’를 확인하세요

프로모션 특가는 모든 특가 중에서 서버 로직 의존도가 가장 높은데 배포를 위한 서명이 필요하고 자격 로직을 직접 설정해야 합니다 어떻게 작동하는지 더 자세히 살펴보겠습니다

이것은 프로모션 특가 워크플로의 예입니다 기존 고객이 구독 자동 갱신을 비활성화하여 곧 구독이 해지될 예정이라고 가정해 보겠습니다

App Store 서버는 이 사실을 알림을 통해 안내하는데 DID_CHANGE_RENEWAL_STATUS 타입과 AUTO_RENEW_DISABLED 서브타입을 사용합니다 이제 여러분에게 고객이 계속 구독하도록 유도하는 프로모션 특가로 고객을 타깃팅할 수 있는 옵션이 있습니다

고객이 특정한 특가 혜택을 받아야 한다고 결정했다면 서버가 프로모션 특가 서명을 생성해서 고객의 기기로 보내야 합니다 앱은 StoreKit에 서명을 제공하는데 고객에게 제품을 특가로 구입할 수 있는 옵션을 제시하기 위해서입니다

이 사용에 대한 알림은 SUBSCRIBED 또는 OFFER_REDEEMED 알림을 통해 받게 됩니다

이 워크플로에서 더 복잡한 부분 중 하나는 프로모션 특가 서명을 생성하는 것입니다 App Store Server Library가 출시되기 전까지는 그랬죠 App Store Server Library를 사용해 서명을 생성하는 한 가지 방법이 여기 있습니다

프로모션 특가 서명을 생성하는 코드는 다음과 같습니다

PromotionalOfferSignatureCreator를 먼저 인스턴스화합니다

내 앱의 비공개 키, keyId bundleId를 전달합니다 이러한 값은 프로모션 특가 서명에 서명하는 데 사용되며 고객이 동의 없이 프로모션 특가를 사용할 수 없도록 방지합니다

다음으로 특가에 대한 productId와 특가 식별자 고객에 대한 app_account_token을 지정합니다 임시값을 생성하고 현재 타임스탬프를 기록합니다 임시값을 사용하면 App Store에서 특가가 여러 번 사용되는 것을 방지할 수 있습니다

이러한 매개변수를 signatureCreator에게 전달하고 Base64로 인코딩된 서명을 받아 고객의 기기로 전송할 수 있습니다 이것이 App Store Server Library를 통한 프로모션 특가 서명 방법이죠 이제 이러한 특가를 제공할 대상을 결정하는 방법이 궁금할 것입니다 Ian, 공유할 업데이트가 있죠? 그럼요! 프로모션 특가에는 어떤 유형의 특가를 생성할지 받을 대상은 누구인지 등 많은 것을 고려해야 할 수 있어요 저희는 여러분에게 구독과 특가에 대한 정보를 최대한 많이 제공드림으로써 여러분이 비즈니스와 고객을 위한 더 나은 결정을 내릴 수 있기를 바랍니다

이를 위해 2023년 말에 서버 API와 StoreKit를 통해 온디바이스로 제공되는 거래 데이터에 새로운 필드를 추가했습니다 새로운 가격 및 통화 필드는 적용된 특가를 포함하여 고객이 구입한 제품의 표시 가격과 통화를 나타냅니다 이러한 필드를 사용할 때는 재무 및 회계 목적으로는 App Store Connect 보고서가 정확한 기준임을 기억하십시오 구입에 특가가 적용된 경우 새로운 offerDiscountType 필드는 해당 특가의 결제 모드를 FREE_TRIAL, PAY_UP_FRONT PAY_AS_YOU_GO 중 하나로 나타내요

정기구독 구입에 대한 디코딩된 거래 정보의 예시입니다 새로운 가격 및 통화 필드에는 구입 시점에 제품에 표시된 가격이 표시됩니다 가격은 해당 화폐의 밀리단위로 표시됩니다 이 예에서 4990은 USD 통화로 4달러 99센트의 가격을 나타냅니다

기존 offerIdentifier와 offerType 필드를 참고하여 사용자가 사용한 특가와 그 유형을 파악할 수 있습니다 새 offerDiscountType 필드는 ‘PAY_UP_FRONT’ 특가임을 나타내죠

이러한 필드는 다양한 시간대에 앱에서 이루어진 구입의 가격대를 이해하는 데 유용한 참고 자료가 됩니다 이제 고객의 거래 내역을 확인하고 이후 제품 가격이 변경되더라도 고객이 지불했던 가격을 파악할 수 있습니다

다음은 새 필드가 구독 구입에 대해 작동하는 방식을 디코딩된 거래 정보의 예시입니다 최초 기간의 거래 정보를 보면 이 구입이 ‘PAY_UP_FRONT’ 특가의 일부임을 알 수 있습니다 거래의 표시 가격은 USD 통화로 4.99달러입니다

2개월의 특가 기간이 끝나면 구독이 갱신됩니다 고객은 이제 정상 가격인 9.99 USD를 지불하게 됩니다

또한 API는 각 고객의 구독에 대한 갱신 정보를 제공하므로 다음에 구독이 자동 갱신될 때 어떤 일이 일어날지 파악할 수 있습니다

이제 갱신 정보에도 세 가지 새로운 필드가 제공됩니다 바로 renewalPrice, currency offerDiscountType입니다 이러한 새로운 필드를 통해 다음 구독 갱신 시 적용될 예상 표시 가격과 특가 결제 모드를 파악할 수 있습니다

구독에 대한 디코딩된 갱신 정보의 예시입니다

renewalPrice 및 currency 필드는 App Store 서버에서 다음 갱신 구입 가격이 8.99 USD로 표시될 것이라는 예상을 나타냅니다

기존 offerIdentifier와 offerType 필드는 다음 갱신 구입에 적용될 것으로 App Store 서버가 예상하는 특가 및 특가 유형을 나타냅니다

새로운 offerDiscountType 필드는 App Store 서버가 갱신 구입이 ‘PAY_AS_YOU_GO’ 특가의 일부로 예상함을 나타내요

선납 결제 특가 예시를 다시 보면 필드의 작동 방식을 알 수 있습니다 초기 특가 기간 동안의 갱신 정보에는 도래하는 정상 기간에 대한 정보가 포함됩니다 갱신 시 정가인 9.99 USD가 적용된다는 것을 알 수 있습니다

첫 번째 갱신 뒤에는 갱신 정보에 두 번째 갱신 시 적용될 내용이 반영됩니다 고객에게 이제 정상 구독 가격이 적용되므로 필드는 변경되지 않습니다

이제 ‘PAY_AS_YOU_GO’ 예시입니다 초기 특가 기간 중 갱신 정보에는 첫 번째 갱신 시 이루어질 구입이 반영됩니다 offerDiscountType 필드는 다음 구입이 아직 ‘PAY_AS_YOU_GO’ 특가의 일부가 될 것임을 나타냅니다 갱신 가격은 특가 할인이 포함된 2.99 USD입니다

첫 번째 갱신 후 갱신 정보에는 두 번째 갱신 정보가 포함됩니다 renewalPrice는 구독이 정상 가격인 4.99 USD로 돌아간다는 것을 나타냅니다

갱신 정보는 두 번째 갱신 후에도 변경되지 않습니다 타깃팅된 프로모션 특가는 고객을 구독 제품으로 유도하고 유지하는 강력한 도구입니다 App Store 서버 API를 통해 제공되는 데이터를 사용하면 프로모션 특가에 대한 서버 측 자격 로직을 특정 요구 사항에 맞게 조정할 수 있습니다 예를 들어 특정 고객에게 특가를 광고하기 전에 해당 고객이 앱에서 특가를 사용한 적이 없는지 확인합니다 또는 더 낮은 가격대의 상품만 구매한 고객에게 제한된 시간 동안 프리미엄 제품을 할인된 가격에 체험할 수 있는 특가를 만들 수 있습니다

특가 전략 수립에 새로 추가된 필드가 도움이 되길 바랍니다 이제 오늘 세션에서 공유한 새로운 기능을 요약해보겠습니다 새로운 ONE_TIME_CHARGE 알림이 일회성 구입에 대해 전송되어 이제 App Store 서버 알림으로 앱에서 이루어진 모든 앱 내 구입을 추적할 수 있습니다

CONSUMPTION_REQUEST 알림은 이제 소모품뿐만 아니라 자동 갱신 구독에 대해 제출된 환불 요청에 대해서도 전송됩니다 또한 이러한 알림에는 이제 새로운 ConsumptionRequestReason 필드가 포함됩니다

이 필드와 기타 서버 측 데이터를 사용하여 환불 허용 또는 거부에 대한 기본 설정을 Send Consumption Information 엔드포인트 호출 시 표현합니다

새로 업데이트된 Get Transaction History 엔드포인트는 특정 고객이 앱에서 진행한 모든 구입에 대한 거래를 반환하므로 요청 시 포괄적인 데이터를 검색할 수 있습니다

마지막으로 price currency, offerDiscountType 같은 새로운 필드로 구독과 거래에 대한 더 많은 인사이트를 얻을 수 있죠 이상입니다 Alex, 더 공유할 내용이 있나요? 그럼요! 오늘 공유한 기능에 대한 여러분의 피드백과 App Store 서버에 있었으면 하는 기능을 알려 주세요 App Store 서버에 대한 기능 요청 또는 피드백이 있으시다면 피드백 지원을 통해 알려 주시기 바랍니다 참고로 오늘 세션에서 사용한 App Store Server Library는 오픈 소스입니다! GitHub에 참여하여 문제를 제출하고 기여해 주세요 App Store 서버에 대한 자세한 내용은 작년의 이 세션들에서 확인하세요 시청해 주셔서 감사합니다!