This document provides a review of the proposed approach in the following PRs:

This document contains 3 sections: Critical, Questionable, and Upstream Ready

• Critical - Cannot be merged to the upstream in this way

• Questionable - Should be discussed and documented

• Upstream Ready - Functional that can live in the upstream

Critical

1. Fetching AppConfig and IAPConfig from the enrollments API.
   /api/mobile/{version}/users/{username}/course_enrollments/

2. Relying on the API of the deprecated ecommerce framework.

Android	iOS

Android	iOS
Open	Open

3. Relying on the Basket flow Moved to the Questionable section

Questionable

1. Setting SKU manually instead of getting it from the API response.
   It’s a bit confusing, and we cannot guarantee that the backend has IAP with this SKU.

   Open

   

2. Relying on the Basket flow.

   Open

   
   Open

   

   In-app purchase is a straightforward process of buying 1 item.
   Attempts to copy web e-commerce flow with basket could confuse.
   It looks like mobile follows this flow just because the e-commerce framework cannot do it any other way; mobile ignores CheckoutResponse and just passes basketId to the final request for some reason.

Upstream Ready

It would be nice to have the following functionality in the upstream:

Checks:

• isAuditMode

• isUpgradeable

• isUpgradeDeadlinePassed

• etc.

Utility/Manager classes that can be used with any eCommerce system:

• BillingProcessor for Android and StorekitHandler for iOS

• IAPAnalytics

All Views that can be reused in the Open edX application:

• Android: IAPDialogFragment, UpgradeToAccessView, etc.

• iOS: CourseUpgradeUnlockView, UpgradeInfoView, etc.

Tests.