Hi Bhathiya, Please find my answers for your concerns,
*I think we can do this check at the time they enable monetization for an API*. +1 *Why do we need separate tables here? Can't we use the existing stats data here?* We need a separate table here because we check whether the response for a particular request is delivered successfully based on some set policy, before taking it as a count to bill. But in the current stats there is no such a check when we aggregate the request count and all of them are simply added to the count through API Request count Aggregation. So if we try to add this also to the same aggregation as a new column then it will create a separation among the request count aggregated and will have to modify the aggregation and existing queries which we used to get data from these aggregations. Hence creating a separate table would very much simplify this. Thanks, Silmy. On Fri, Apr 5, 2019 at 2:38 PM Silmy Hasan <si...@wso2.com> wrote: > Hi Bhathiya, > > Please find my answers for your concerns, > > *I think we can do this check at the time they enable monetization for an > API*. > +1 > > *Why do we need separate tables here? Can't we use the existing stats data > here?* > We need a separate table here because we check whether the response for a > particular request is delivered successfully based on some set policy, > before taking it as a count to bill. But in the current stats there is no > such a check when we aggregate the request count and all of them are simply > added to the count through API Request count Aggregation. So if we try to > add this also to the same aggregation as a new column then it will create a > separation among the request count aggregated and will have to modify the > aggregation and existing queries which we used to get data from these > aggregations. > Hence creating a separate table would very much simplify this. > > Thanks, > Silmy. > > On Fri, Apr 5, 2019 at 2:25 PM Bhathiya Jayasekara <bhath...@wso2.com> > wrote: > >> Hi Chamin, >> >> On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias <cham...@wso2.com> wrote: >> >>> Hi all, >>> >>> We are in the process of providing support for monetization in APIM. We >>> have performed a pre-analysis of $subject and came up with the initial >>> design. >>> >>> For the initial implementation, we plan to use Stripe and implement the >>> necessary functions to support monetization flow in the product. >>> >>> Please find the details below. >>> >>> *A) Prerequisites* >>> >>> 1. API provider should have a stripe account. >>> 2. API subscriber should have a credit card (to use paid APIs). >>> 3. API analytics should be enabled (since we need to publish some data >>> in the DB related to this) >>> >>> >>> *B) There should be few mappings between APIM and Stripe for some >>> objects/actions.* >>> >>> - Object/action in APIM : Attaching a paid tier to an API >>> - Corresponding object/action in Stripe : Plan [1] >>> >>> >>> - Object/action in APIM : API subscriber >>> - Corresponding object/action in Stripe : Customer [2] >>> >>> >>> - Object/action in APIM : Subscribing to an API >>> - Corresponding object/action in Stripe : Create a subscription [3] >>> in stripe >>> >>> >>> - Object/action in APIM : Invoking APIs >>> - Corresponding object/action in Stripe : Charging [4] in stripe >>> >>> >>> *C) This is the flow.* >>> >>> 1. API provider creates an API. At the time of attaching a paid tier to >>> his API, we check for the existence for the stripe account of the provider. >>> If it is there, we create a "plan" [1] in the stripe side to indicate the >>> attachment if the tier to the API. If the API provider does not have a >>> stripe account, then we notify them to create an account and come back. >>> >> >> I think we can do this check at the time they enable monetization for an >> API. >> >> >>> >>> 2. API subscriber (app developer) subscribes to an API. If this is done >>> through a paid tier, then we create a "customer" [2] object in stripe side >>> using the stripe account of the API provider. In other words, this is the >>> indication that this app developer is a customer if the corresponding API >>> provider. A "subscription" [3] will be created in stripe side after >>> capturing the credit card data. >>> >>> 3. When the API is consumed (i.e - invoked), we record the data in the >>> corresponding data table (we will need a separate table(s) for this). >>> >> >> Why do we need separate tables here? Can't we use the existing stats data >> here? >> >> Thanks, >> Bhathiya >> >> >>> >>> 4. Every day, at a given time (say at 00:00), we run a scheduled task >>> and identify the customers (i.e - who has reached the end of the billing >>> cycle - say 1 month) to be billed. If we find such customer, then APIM >>> sends a "charge" [4] request to the respective customer (i.e - App >>> developer) based on the usage data we have collected in the DB. >>> >>> Please share your thoughts/suggestions if you have any. >>> >>> [1] Plan : https://stripe.com/docs/api/plans?lang=curl >>> [2] Customer : https://stripe.com/docs/api/customers?lang=curl >>> [3] Subscription : https://stripe.com/docs/api/subscriptions?lang=curl >>> [4] Charge : https://stripe.com/docs/api/charges?lang=curl >>> >>> Thanks. >>> >>> -- >>> Chamin Dias >>> Mobile : 0716097455 >>> Email : cham...@wso2.com >>> LinkedIn : https://www.linkedin.com/in/chamindias >>> >>> >> >> -- >> *Bhathiya Jayasekara* >> *Technical Lead,* >> *WSO2 inc., http://wso2.com <http://wso2.com>* >> >> *Phone: +94715478185* >> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >> <http://www.linkedin.com/in/bhathiyaj>* >> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >> *Blog: http://movingaheadblog.blogspot.com >> <http://movingaheadblog.blogspot.com/>* >> > > > -- > Shilmy Hasan > Associate Software Engineer | WSO2 > > E-mail :si...@wso2.com > Phone :0779188653 > web : http://www.wso2.com > > [image: https://wso2.com/signature] <https://wso2.com/signature> > -- Shilmy Hasan Associate Software Engineer | WSO2 E-mail :si...@wso2.com Phone :0779188653 web : http://www.wso2.com [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
