So I have my clients app set up to work with plans, which I was testing with my account. I set those test plans a couple months back, but now that I'm setting it up on my client's account, when I create a product I can only create a price for it. Did something change. Can I create a plan or do I have to change my code?
Prices are a new abstraction that replace Plans, yes :
https://stripe.com/docs/billing/prices-guide
https://stripe.com/docs/billing/migration/migrating-prices
They're created by default in the dashboard now.
You shouldn't need to change any of your code though, it's completely backwards and forwards compatible.
You can simply pass a price_xxx ID into anything that takes a plan parameter, for example, code that creates a subscription and sets items[0].plan=price_xxx will just work. You'll also see that the API mirrors the Price into both plan and price fields when you read an object from the API so again, your code doesn't need to know a Price is being used.
Related
I have a Shopify store with rental products. Since Shopify doesn't handle return flows, the shop is connected to an external service, were the order is sent via an API to that service, which handles finalizing the rental and tracking it.
Now here is the problem, since the procedure is finalized outside of Shopify, the products are removed when rented, but not added when returned. this makes updating the shop manual. I am currently using Pipedream to handle my Web-hooks and requests, and it provides a service to change Inventory Level, but no direct way to update Shopify inventory. I know that the only way to update quantity in by getting InventoryItemID, and the only way to get that is by using ProductVarientID. I was able to acheive that using GraphQL, but I'd have to manually quary the InventoryItemID by using the ProductVarientIDs of my return orders from an API, and then use a mutation that does bulk inventory update to get the job done, but you can see, this is hardly automated.
Any thoughts and ideas are much appreciated.
If there is a way to do it using Pipedream, that's super.
I am a bit stuck so I'm turning to you.
I have a system of subscriptions. The customer can only upgrade his subscription.
So the idea is that you have the different plans we offer, let's say you have account: silver (30$) gold (90$) and platinium(180$)
if the user has a free account, it's a regular subscription creation.
So the scenario is the following:
My customer goest from free to silver.
After a weeks he realize gold is fitting to his needs so he upgrades he has a preview of his next invoice and this works no problem so far with the following function:
await stripe.invoices.retrieveUpcoming({
customer: this.body('customer'),
subscription: this.body('sub'),
subscription_plan: this.body('newPlan'),
});
so the problem arise when the customer wants to upgrade again. Using the subscription_plan parameters bugs, and prevent the upgrade from being done.
How can i do that ? Do i need to create a new subscription ? What am i doing wrong
Using subscription_items seemed to do the job, the the invoice is giving me hell to fetch the data correctly with the prorata.
You can upgrade (or downgrade) a subscription by calling stripe.subscriptions.update.
Notably this will take care of any prorations for you, and you can specify your preferred proration behaviour when updating. You can learn more about how Stripe handles prorations here.
I'm working on a SAAS system that allows purchases to be made through a clients own payment gateway. We have one client that wants to use Stripe as their gateway, however as they are using Corporate Purchase Cards (CPC), it is necessary to pass Level 3 transaction details through. I've been trying to get details from Stripe on how we ensure that Level 3 data can be passed through successfully, however I'm not really getting anywhere with this in terms of getting any definitive information we can work with.
Stripe say that their system supports level 3 data, we just need to provide the data in the first place, however there is nothing in their documentation about this and the example we have been provided only allows for a single item to be listed - we will need to support a basket of different items.
We are using the Payment Intents process and already support adding in Metadata to the transaction. We've been told that adding metadata for SKU, Unit of Measure, Unit Price and Extended Price will allow level 3 processing, however this does seem to fall short of the information list on other sources (not to mention does not allow listing multiple items in the order due to the metadata keys needing to be unique)
Baed on that, our Metadata population looks like this (values hard coded to example purposes)
Dictionary<string, string> nRetVar = new Dictionary<string, string>();
nRetVar.Add("Customer", "John Smith");
nRetVar.Add("Email", "John.Smith#example.com");
nRetVar.Add("Order Number", "12345");
nRetVar.Add("Order Date", "2020-02-06");
nRetVar.Add("SKU", "ABCD1234");
nRetVar.Add("Unit of Measure", "1 Pack");
nRetVar.Add("Unit Price", "$10.00");
nRetVar.Add("Extended Price", "$15.00");
Stripe support never seem to directly answer any of the questions we have been asking about this, so it's proving very hard to get any progress on this - does anyone have enough experience with this to confirm if this metadata is enough to class as level 3, or is there more that we need to be adding?
Stripe supports Level 3 data in their API on both Charge and PaymentIntent. This feature though is currently "gated" which means you need to get access to the feature on your specific account. It's a bit similar to a long running beta. You should contact their support team again and ask for them to enable Level 3 data on PaymentIntent for your account.
The fields they are expecting as specific to that feature. This does not go inside metadata. The documentation is also gated which means you can only see it once you get access to the feature, to avoid confusion for other developers who don't have access.
You can see what the shape looks like in stripe-java for example on Charge here. The feature is not directly supported on PaymentIntent in the library though as this is still private.
We have a bot that will be used by different customers and depending on their database, sector of activity we're gonna have different answers from the bot and inputs from users. Intents etc will be the same for now we don't plan to make a custom bot for each customer.
What would be the best way to separate data per customer within Chatbase?
I'm not sure if we should use
A new API key for each customer (Do we have a limitation then?)
Differentiate them by the platform filter (seems to not be appropriated)
Differentiate them by the version filter (same it would feel a bit weird to me)
Using Custom Event, not sure how though
Example, in Dialogflow we pass the customer name/id as a context parameter.
Thank you for your question. You listed the two workarounds I would suggest, I will detail the pros/cons:
New API Key for each customer: Could become unwieldy to have to change bots everytime you want to look at a different users' metrics. You should also create a general api (bot) where you send all messages in order to get the aggregate metrics. This would mean making two api calls per message.
Differentiate by version filter: This would be the preferred method, however it could lengthen load times for your reports as your number of users grows. The advantage would be that all of your metrics are in one place, and they will be aggregated while only having to send one api call per message.
I have a tested app that will hopefully go live in the short term.
However, it has 3 in app purchases.
If the situation arises where I need to do a further test of purchasing the in-app-purchases, is there any way I can cancel my own personal in-app-purchases up to that point so I will be testing from scratch?
Note: I am using the new Windows.Services.Store.StoreContext method, and not the old one.
First, there's no such API that can cancel your in-app-purchase currently. But you can still do your further test.
If the situation arises where I need to do a further test of
purchasing the in-app-purchases, is there any way I can cancel my own
personal in-app-purchases up to that point so I will be testing from
scratch?
According to your description, it seems your IAP type is durable. If so, you can specify the duration for the product as 1 day so that you can repurchase it after it expires.
If your IAP is developer-managed consumable type, you need to report the previous IAP as fulfilled after the user consumes all the items. Then they purchase it again.
If your IAP is Store-managed consumable type, you need to report any items consumed by user as fulfilled to the Store and the Store updates user's balance. After users consume all the items, the user can purchase that IAP again.
For more details, you may refer to In-app purchases and trials.