Page Comparison

...

• In-App purchase fulfillment API

  • API that verifies the payment and unlocks gated content

  • Possible data required for this API:

    • Transactional details like receipt information or Transaction ID

    • Basket, which can be obtained for a user against a site

• In addition to this, we would need to be able to distinguish between in-app purchase orders and web orders. The most straightforward way of doing this is to add a boolean flag to the Order model.

API Flow:

Following is the proposed API flow:

1. BasketAddItemsView is called with the course seat SKU to get it added to the basket on the ecommerce side before showing the payment pop-up on the app screen
   Note: The embargo check would apply at this point and the API call would fail if a user is requesting from a country with the embargo in place.

2. Payment is processed on the mobile side. Upon success, the newly introduced In-app purchase fulfillment API is called with the transaction ID or other transaction information

3. A third party in-app purchase verified verifier verifies the successful purchase

4. Upon successful verification, create_order from EdxOrderPlacementMixin is called to create and place an order against the purchased course seat.

5. The create_order method creates the order, places it with the system, and triggers the course seat fulfillment.

6. Once this is all complete, some post order operations like invoice creation are carried out by the handle_post_order method.

7. Once these steps are complete, the user should have access to gated content as well as all the journalling be done on the ecommerce side.

8. The in-app Purchase API then returns a success response to the mobile app and the flow is continued on the mobile side.

...

Procedure to offer a refund:

There are APIs already in place to create and track refunds which are as follows:

• <http-scheme>://<domain>/refunds/

• <http-scheme>://<domain>/refunds/<pk>/process/

The first API creates a refund and the second API can be used to approve or deny a refund.

These APIs can be used as is in the case of web orders but since the payment is being processed on the mobile end in the in-app purchases, further research would be needed to figure out exactly where these APIs would fit in.

Risks and Concerns:

Following are some of the visible potential concerns that are attached to the in-app purchases flow:

• What if there is a network/connection problem to the server and the course seat purchase fulfillment call fails?

  • Possible routes:

    • Mobile side retries calling the API

    • Triggers the fallback if the issue persists

• What would happen if the in-app purchase verification fails?

  • Possible routes:

    • Retry verification

    • Let the mobile side know that the verification failed to trigger the fallback

• What would happen if the order fulfillment fails?

  • Possible routes:

    • Retry fulfillment?

    • Mobile side fallback

Project Estimates:

Project tasks:

• API addition with unit testing and required documentation (~1 week for handling API flows apart from purchase verification)

• Any modifications required in the current system like changes to Order module ( ~1 week)

• Integration of third party in-app purchase verifier (~3 weeks, 1 for basic understanding of tool, 1 for play store verification integration, and 1 for app store verification integration)