In the iOS App Store, you can create subscription groups, which I believe allows the app to (if coded as such) display different subscription options to different groups of users. For example, grouping magazine subscriptions by genre.
Is there anything like this for the Google Play store, or would I need to do the groupings myself within the app?
Although I am not sure at this time, but I don't think Google Play provides the equivalent of a Subscription group. At the time of this writing, I am working on the same and new updates will publish edits here.
There is a catch here,
which I believe allows the app to (if coded as such) display different subscription options to different groups of users
Although, subscription groups can be used for the purpose described above, they are not inherently meant for the same. Subscription groups are meant to group different subscription products so that the user can purchase only one of them at the same time.
You can view a subscription group as a product/ service your app offers and the subscription products under them as the Plans under the same. For example, for a news app, you may offer a subscription product to your users with different plans like Single Category Monthly, All Monthly, Single Category Annual, All Annual. The single category app may provide news only in one single chosen category like sports, entertainment, politics etc. The user can choose to change between plans any time but can subscribe to only ONE plan at a time.
Also, as you would comprehend, some of these plans are higher levels of services than others. Based on your business definition, you can put these plans at different levels. That will determine if the user is upgrading/downgrading/cross grading while changing a plan. For example, in this case you may have two levels:
Level 1 may have All Monthly and All annual.
Level 2 may have both the single plans.
1 -> 2 will be downgrade, 2 -> 1 will be upgrade, 1 -> 1, 2 -> 2 will be cross grade.
In Google Play Billing, an upgrade or downgrade will be performed by setting the oldSku while making a purchase. If the oldSku is set, Google Play Store will consider it as an upgrade/downgrade.
However, I am not sure at this point how the App Store determines if it's a upgrade/ downgrade / crossgrade. May be based on the price (unlike Apple).
Grouping may not be required for Playstore. In Appstore, since all the subscription options are listed, we need to group a set of items together. For example, if user subscribes within a 10 days of registration, 10% reduction in monthly, annual cost can be provided. In such cases, if they cancel the subscription, they can re-subscribe from store. They will be listed with only those group to which they subscribed before (monthly, annually for within 10 day plan). So they continue to get 10% reduction if they re-subscribe to any plan (monthly, annually).
In Playstore, user can re-subscribe to the same subscription that user opted before. So such case won't arise.
Set update subscription param as specified here
Related
I am looking to build a bot that typically requires two numbers with a different meaning (role) in the same utterance. Let's take the example of a StockMarket order assistent (fictional, as example)
Some example utterances:
Buy 100 MSFT stock at limit of 340
Get me 200 Apple at maximum 239.4
Buy 40 AMZN at market price
In LUIS portal, I have defined two entities
StockSymbol a List entity (for all stocks, linking their symbols and the names as synonyms).
number the prebuilt entity with two Roles: Amount and Limit
When specifying the utterances shown as example, it shows that the entities get recognized. But I cannot find a way to specify the roles for the different number entities in my sample utterances. (in the examples, the first number instance of number is the Amount, and if a second it there, that is typically the Limit role.
Anyone an idea on how to define this and set this up?
Best regards
There are 2 different ways to do this, First is to use roles for a prebuilt entity, go into the number prebuilt, click on Roles, add 2 different roles.
one for Amount another for Limit then you have to go in the utterances and label for the roles, you do that by going to the utterance, clicking on the # symbol on the right, selecting the number prebuilt, selecting the role, then highlighting the numbers with that role.
Second approach is to use ML entities, create 2 ML entities, one for Amount one for Limit. Add the number as a feature and make it a required feature, and then go ahead and label the Amounts with the Amount entity and the limits with the Limit entity directly.
Let’s assume I’m in the context of an admin panel for a webshop. I have a list of orders. Those orders are payed for and are ready to ship. The (admin) user would like to start making shipments based on the items ordered.
Imagine there are 2 microservices. One for orders and one for shipments. In order to create a shipment, i will send a request with a couple of items to be shipped and an order ID to the shipment service. The shipment service will then check whether the items are present in the order by querying the order service. Because i don’t want to create a shipment with items that are not present in the order.
I’d like to have immediate consistency because the shipment data will be send to a third-party application after creation. Thereby it also feels weird to allow shipments to be created if the data is not correct.
I’m also using GraphQL mutations. Which means i have to return the updated state to the user, which also makes eventual consistency a lot harder.
What is the recommended approach for these situations? Could this be a sign that these 2 microservices need to be merged? I can imagine this situation can occur multiple times.
I am working on a SAAS project where users can create various projects. With each project, they can choose from 5 different plans. Each plan has its own costs per month. Hotjar is a kind of equal concept.
Now I want to arrange the subscription with Stripe. The problem with that was that a user can have a maximum x subscription, which of course was a shame. Then I decided to take 1 subscription that has several plans. But now I have a dilemma, to update the subscription you have to change the number via SubscriptionItem. Then you have to save yourself which plan has which SubscriptionItem_id for which user. That is quite a detour and can cause many problems.
Someone is a better way with Stripe or another payment software.
You don't necessarily need to store the subscritpion_item IDs, you can look it up via the subscription_item list API. All you need to do is store the subscription_id for your customers, and based on that ID you can retrieve the list of subscription_items:
\Stripe\Stripe::setApiKey("sk_test_9GavlLpfiKewqeCBXvRvmVgd");
\Stripe\SubscriptionItem::all(["subscription" => "sub_EQlPGjVj4o5luH"]);
Then you can handle the data part of the returned JSON object and update / delete / etc these subscription items.
If you only have the customer_id handy, then you can use the subscription list API (with status as well on the GET params) to retrieve the list of active subscriptions.
We have an e-commerce site, and several bricks & mortar stores.
I have managed to extract stock data from the "bricks & mortar" database and send this up to the website, but putting the online sales back into the database is proving almost impossible. No docs + uncooperative vendor.
What happens at the moment is the website sells something, the order is processed manually into the store database and then the stock levels are updated back to the website. The issue being that the stock levels are not updated instantly so there is a possibility 2 people can purchase the same item, especially with sale items where there is only a single item left.
I am wondering if there are any good solutions to this?
One thought I had was to store the number of purchases on the website, and subtract that from the number of items in-stock leaving the correct stock level. But then once the order is processed in the "bricks & mortar" store, the stock level being exported to the website would be inclusive of that difference, and my online stock levels would be incorrect.
Any help pointing me in the right direction would be greatly appreciated
You should use a 'lock' and 'confirm' approach. If a customer at one POS is requesting an item, you should contact the server and lock up the item if it is available. Then customer will have a few seconds to 'confirm' the sale (otherwise the POS requests the server to unlock the item).
In my application my users can generate statements, monthly and weekly. I've recently been
asked to allow the users the capability to associate a customer with either weekly or monthly
but not both, to a customer. This then leads to...if a user selects a weekly customer and runs a monthly
statement, he or she, should be prompted that customer's statement cannot be generated and why.
My question: In the UI of the customer screen when editing a customer, should I label the choice option(s) as
Select the customer Statement
Frequency [ monthly or weekly]?
Select the customer Statement Type [
monthly or weekly]?
What giudelines do you follow to assist you when making such decisions?
Thanks
I would suggest using Statement Frequency. Other choices might be cycle or period.
The rule of thumb should be to ask the user (product's business owner) what terms and wordings to use. It's not uncommon for business users to review all the terms and messages the application uses. That way the resulting product will speak the users' language.
The reason is that developer-invented terminology often leads to unintuitive UI. It may be perceived as clumsy, unfamiliar, or even incomprehensible by end-users. The worst case is bringing the software's internal terminology and mechanisms to the user interface.