Skip to main content

Billing implementation

This section provides guidance on implementing billing on the Fynd Platform for developers who wish to create paid extensions. The billing implementation flow involves three entities:

  1. Seller
  2. Extension
  3. Fynd Platform services

For non-paid extensions, no information regarding subscription plans is provided. However, for paid extensions, information about available subscription plans is included.

Flow Diagram​

Billing-implementation

The extension creates a Pricing page that allows sellers to view available plans and their respective features. This page is essential even for a single plan as it provides sellers with details of the features they are paying for.

Here is the flow for the billing charges approval process:

  1. Once a seller selects a plan, they will be redirected to the Fynd Platform billing charges approval page. Here, the seller can review the charges submitted by the extension to the Fynd Platform. Upon accepting the charges, the specified amount will be deducted from the seller's account, along with the Fynd Platform plan bill.
  2. After approving or declining the charges, the seller will be redirected back to the extension's provided link. If the charges are approved, the extension should update the active plan details accordingly based on the seller's consent.
  3. Upon approving the charges, the seller should be redirected to the extension's home page, where they can start using the extension.
  4. If the seller declines the charges, they will be redirected to the extension's provided link. The extension should then capture the seller's reason for declining the charges for further understanding.
note

It is important to handle the redirect and communication with the seller effectively throughout this process.

Required DB Models​

You can use two models for your billing implementation

  1. Plan Model

Plans model contains attributes such as:

  • plan_id : To keep a track and fetch the status of charged plans created on the Fynd platform.
  • name : Provides name of the plan.
  • tagline : Provides plan tagline.
  • company_id : Company ID where plan is being applied .
  • pricing_type : Provides pricing type for current extension charge (It will be always recurring for subscription).
  • price : Provides plan amount to be deducted in each billing cycle.
  • features : Provide features of the plan.
  • interval : Plan cycle type. Possible values: month, year.
  • created_at : ISODate string for plan activation.
  • updated_at : ISODate string for plan modification.
  1. Subscription Model

Subscription model contains attributes such as :

  • subscription_id : To keep a track and fetch the status of subscription created on Fynd platform.
  • company_id : Company ID where plan is being applied.
  • status : Provides the status of the subscription, which can be pending, expired, declined, active, frozen, cancelled, no_renew, success, or failed.
    • pending : Charge is created but yet to be approved or declined by the seller.
    • expired : Session for seller to pay charge is expired.
    • declined : When the seller has not approved the consent of charge.
    • active : When any plan is subscribed successfully for an extension.
    • frozen : Charge for some time is not applied.
    • cancelled : Charge is cancelled by extension or extension is uninstalled and it is not active anymore. If the extension is uninstalled, seller is charged once as per their usage and is excluded from further billing cycles.
    • no_renew : Extension is uninstalled and charges will be cancelled after charge period is over.
    • success : After installing the extension, the seller pays the charges for extension successfully.
    • failed : Transaction of charge is in failed state.
  • activated_on : ISODate string for subscription activation.
  • cancelled_on : ISODate string for subscription cancelled state.
  • created_at : ISODate subscription creation date.
  • updated_at : ISODate subscription updation date.

Status Transition​

Below are status transitions for activating new plans or switching from the existing one:

  • Any plan subscribed successfully will follow:
    • pending → active.
  • Any plan started subscription but declined will follow:
    • pending → declined.
  • Any plan switched from existing subscribed plan will follow:
    • pending (new subscription) → active (new subscription) → cancelled (old subscription).
  • Any extension uninstalled with active subscription will follow:
    • active → no_renew.
  • Any extension if had plan activated before uninstallation and re-installed in sometime will follow:
    • no_renew → active.
  • Any extension which was previously uninstalled and not re-installed by the time subscription period ends will follow:
    • no_renew → cancelled.

Steps​

  1. Seller selects a plan and clicks the Subscribe button.

QG7

  1. Extension will call the createSubscriptionCharge method from SDK to create subscription charge for a plan.

    Body :

    {
        "_id": "" //Subscription ID
        "name": "", // name of plan or subscription
        "line_items": [ // Will be shown in invoice
        {
            "name": "", //name of recurring charge or plan
            "term": "", // basic description of recurring charge
            "price":
                    {
                        "amount": 0,
                        "currency_code": "INR"
                    },
            "pricing_type": "recurring",
            "recurring": {
                "interval": "" // month/year
            },
            "capped_amount": //Max usage allowed under current extension usage,
            "trial_days": 0,
        }
        ],
        "return_url": "" // return redirect url of extension website-
        // after user's approval or rejection of charge
    }

    QG7

  2. Get subscription charge details:

    QG7

How Seller will be charged for extension?​

  • Charges created by extensions are not immediately charged. Each Fynd Platform seller will have an active subscription to the Fynd Platform plan, which is charged on a monthly or yearly basis.
  • Extension charges will be added to the Fynd Platform's monthly invoice and deducted from the seller's account (credit balance).
  • Recurring charges created by the extension will be charged in advance on the start date of the current period cycle. For example, if a seller subscribes to an extension on 01-06-2021 for a one-month period (from 01-06-2021 to 30-06-2021), they will be charged on the next Fynd Platform invoice generated with a billing date of 01-06-2021. For the next cycle, charges will be made on 01-07-2021 for the period 01-07-2021 to 31-07-2021.

What happens when seller uninstalls an extension?​

  • Active charges for the extension are marked as "no_renew" state, indicating that the extension has been uninstalled. If a seller does not install another extension before the recurring charge period is over, the charges will be marked as cancelled.
  • In this case, the seller will be charged for the entire period even if they uninstall the extension before the subscription plan expires. For example, if the monthly charge for an extension is Rs. 100 and the seller uninstalls the extension after using it for 20 days, they will still be charged Rs. 100.
  • The extension can cancel these charges soon after the extension is uninstalled. Once the extension cancels the charges, the seller will be charged only for the days until the charges are cancelled. To cancel charges, use the cancelSubscriptionCharge method of the SDK.

What if Seller reinstalls extension before recurring charge period is over?​

  • If a seller reinstalls the extension before the recurring charge period is over, the charges will be moved back to the active state, indicating that the existing subscription has been resumed.
  • For example, if a seller subscribes to an extension for a one-month period (from 01-12-2021 to 31-12-2021) and the charges are in the "no_renew" state, if the seller reinstalls the extension before or on 31-12-2020, the charges will be moved to the active state and continue charging the customer going forward.

Switching plan​

  • If a seller has an active plan and decides to switch to another plan, the charges for the active subscription will be moved to the cancelled state. When the seller approves the new charges, the new plan will be activated.
  • For cancelled charges, the seller will be charged only for the days they used the previous plan when the next invoice is generated.
  • Extensions should handle this scenario by marking any existing subscription as cancelled before activating a new subscription with the same or different plan.

Webhook​

The extension subscription event webhook can be helpful in handling subscription events when installation or uninstallation events occur for an extension. You can subscribe to these events by passing the 'webhook_config' parameter in the setupFdk function.

let fdkExtension = setupFdk({
    ...
    webhook_config: {
        api_path: "/webhook",
        notification_email: "[email protected]",
        event_map: {
            "company/extension/install": {
                "handler": extensionSubscriptionInstallHandler,
                "version": '1'
            },
            "company/extension/uninstall":{
                "handler": extensionSubscriptionUninstallHandler,
                "version": '1'
            }
        }
    }
});

Was this section helpful?