Order Management

Introduction

The IPOS Order Management system provides a robust and integrated solution for widget developers to facilitate transactions within their widgets. This system is designed to be deeply integrated with the GIGGLE IPOS economic model (currently under development), which in the future will offer a powerful way to incentivize user engagement and provide revenue opportunities for widget developers.

Problem Solved: Driving User Payment and Developer Monetization

The Order Management system addresses two key challenges:

• Boosting User Payment Motivation: By allowing IP holders to integrate their economic models directly with transactions initiated within widgets in the future, users will be more incentivized to make payments. The potential for rewards, benefits, or unique experiences tied to the IP's economic model is expected to significantly increase conversion rates.

• Enabling Widget Developer Monetization: The system aims to reward widget developers for driving transactions on the platform. IP holders will be able to configure their economic models (under development) to automatically allocate a percentage of each successful order to the widget developer who facilitated the transaction. This creates a direct incentive for developers to build engaging and valuable widgets.

Supported Payment Methods

The IPOS platform currently supports popular payment methods, including:

• Stripe: Integrating Apple Pay and Google Pay to provide users with a convenient payment experience.

• Web3 Payment: Users can choose to pay using system-allocated Web3 accounts.

Widget developers do not need to handle the underlying payment integration details when creating orders; the IPOS platform will manage the processes for various payment methods.

Order Generation Workflow

The lifecycle of an order within the IPOS ecosystem follows these key steps:

Step-by-Step Explanation:

1. Create Order: The widget developer initiates the order creation process by calling the IPOS Order Management API. This request includes essential details such as the transaction amount, a description of the item or service, and specifications for the reward model (coming soon). The API response will include a unique Order ID and an Order URL. For detailed parameters and request structures, please refer to the Order Section.

2. Bring user to order url: The widget developer then redirects the user to the provided Order URL. This URL is hosted by IPOS and presents the user with the available payment options.

3. User selects payment method and completes payment: On the IPOS-hosted page, the user selects their preferred payment method (Stripe/Apple Pay/Google Pay/Web3 Payment) and completes the payment process.

4. IPOS Payment Callback: Upon successful payment (or any status change), IPOS sends a notification (a POST request with relevant order details, including payment method) to the callback URL specified by the widget developer during order creation. For detailed structures and parameter descriptions of the callback request, please refer to the Order Creation. Widget developers must configure their servers to receive and process these callbacks.

5. Complete Remaining Logic: Once the widget's backend receives and processes the successful payment callback, it executes any remaining business logic associated with the order, such as delivering a digital asset or granting service access. This part of the process is fully controlled by the widget developer.

6. Initiate Economic Model Flow: Following successful payment, the IPOS platform will initiate the economic model associated with the IP in the future (currently under development). Based on the IP holder's configuration, this may involve the distribution of funds or rewards, potentially including a share of the transaction value for the widget developer.

By utilizing the IPOS Order Management system, widget developers can easily facilitate transactions within their widgets, with the potential for future integration with the platform's economic incentives. For more detailed API information, such as request methods, parameters, and response formats, please consult the complete Order Section.

Order Page Query Parameters

The order page supports the following query parameters to control the displayed content and user context:

• orderId

  • Required: Yes

  • Type: String

  • Description: A unique identifier for the order to be displayed. This parameter must be included in the URL.

• token

  • Required: No (Optional)

  • Type: String

  • Description: Allows manually specifying a user access token. By default, the order page attempts to read the access token from local storage to fetch order details. This parameter is typically used when you need to open the order page from a widget, especially if the widget and the order page are on different origins (domains). In such cross-origin scenarios, you will need to pass the user's token from your widget to the order page using this parameter.

• theme

  • Optional

  • Type: String

  • Description: Sets the display theme. Use 'dark' for dark mode.

• hideBack

  • Optional

  • Type: Boolean

  • Description: If set to true, hides the back button.

• hideScrollBar

  • Optional

  • Type: Boolean

  • Description: If set to true, hides the page's scroll bar.