How to delete a price using API

moskrc commented 4 years ago

Hello,

I want to delete a price inside a product, I can do it in the Stripe dashboard, but I can’t do this using API

Code:

stripe.Price.delete("price_HLez6Zi58HejNP")

Result:

  File "../src/payments/models.py", line 81, in delete
    stripe.Price.delete(self.stripe_id)
AttributeError: type object 'Price' has no attribute 'delete'

Thanks

remi-stripe commented 4 years ago

@moskrc The Price API does not support deletion today. You should instead set active to false on the Price if you don't want to use it again. The only case where a Price can be deleted is when it's mirroring a Plan and this plan is deleted via the API, which we only support for legacy integrations but actively discourage using.

kirk-marple commented 4 years ago

@remi-stripe On this topic, if you don't delete a price, which has been added to a product, you get an error deleting the product.

This product cannot be deleted because it has one or more user-created prices.

Should we just be setting products to inactive too, rather than deleting them?

remi-stripe commented 4 years ago

Yes we recommend keeping your object so that it can help with future reconciliations.

sasokovacic commented 3 years ago

@remi-stripe It doesn't make any sense to be able to delete an unused product and not be able to delete an unused price. It's also not logical that we can delete a price in the Stripe panel but not through the API. You should enable this at least in the development mode where we are adding a lot of dummy data and want to clear some of it after testing. The only option here is to delete all test data from the Stripe panel.

remi-stripe commented 3 years ago

@sasokovacic I agree but in the future we want to remove the ability to delete object and instead default to marking them as inactive and make them hidden. The Prices API is a newer API and replaces the Plans API. Plans could be deleted though so we had to support deletion in the Dashboard for backwards compatibility. If we had removed it, we'd have broken thousands of integrations that expect this flow to works in the Dashboard. Overall though, we are moving away from it and will, in the (far) future, disable this feature. For newer integrations, deleting a Price is something we don't want to directly support which is why you can't do it in the API

jleclanche commented 3 years ago

@remi-stripe I know this is OT for stripe-python but IMO Stripe should consider allowing deletion of prices that haven't been used anywhere. Especially for users doing most of their business directly from the dashboard (eg. using Stripe purely as an invoicing platform), mistakenly creating prices can happen and if no related invoice has been issued, it ought to be fine to delete.

remi-stripe commented 3 years ago

@jleclanche It's really confusing when an API fails in almost all cases though. Being able to delete a Price never used but not delete another Price is a pit of failure for a developer to discover. And FWIW We do allow this in the Dashboard already for that reason. Overall there's no reason to delete a Price as long as the Dashboard is hiding them by default so it's more that we need to improve the Dashboard overall and not clutter the API with an API method that can almost never be used I think

sasokovacic commented 3 years ago

@remi-stripe what is the reasoning behind this decision? What is so problematic about deleting unused records? It's the most basic functionality in any application. When I build apps for businesses, I always implement soft deletion, but they are also able to hard delete data that doesn't have any value in the system. This is how you enable users to clean up the database frequently and consistently.

remi-stripe commented 3 years ago

@sasokovacic It's related to what I mentioned. You would think you can delete all prices but later discover you can only delete unused prices for example. And if you support price deletion, then in the API you get a truncated version of the object that only returns the id, object and deleted property when what most integrations want is to make the price inactive so that no one new can use it, while keeping the historical record. I do understand your position and I don't disagree but I wouldn't call it "the most basic functionality" either. At some scale, there is value in data that can be mutated or disappear too.

QuintinWillison commented 3 years ago

I've just stumbled across this issue as I'm working on the "product and price" creation bit of a Stripe integration for someone right now (JS SDK in Node.js but applies just the same, and this issue came up top in Google search). It really makes no sense to me why the "..." menu against a price in the dashboard (the web UI) allows users to "Delete price" but I cannot do the same from the API.

Also, loosely related, I was surprised I could create products and specify the product id myself (good!) but found that I am not allowed to specify the price id myself when creating a price.

Something definitely doesn't sit right here. I was expecting consistency and parity from Stripe across all levels of the UX/DX, given how focussed you are on API / developer first (or at least as far as I understood you were). It just feels a bit curiously incongruous. 🤷

Developers just learning your platform will be thrashing about, in both test and production environments, so I think it's only natural to be able to fix our mistakes by deleting unused and misconfigured objects while we experiment... especially when those experiments are programs / scripts that we're writing to "initialise" our Stripe environments.

sasokovacic commented 3 years ago

@remi-stripe from my experience deletion/soft-deletion is the most basic and most common functionality these days. Also, there is a difference between archived, soft-deleted, and hard-deleted status. IMO Stripe should have at least the first two available through its API. As for truncated objects, you don't have to return them. There is no need for this. You only return active objects by default. Archived and soft-deleted objects can be retrieved explicitly using some parameter or different URI. In the end, it's your decision. I'm just sharing my experiences building many business apps. Some businesses require hard deletion, but most of them require soft-deletion which means these records are not visible anywhere in the app except in some special view for troubleshooting purposes.

pm-bc commented 3 years ago

I will second the comments from Quintin and sasokovacic. I just ran into this myself when attempting to use the API to completely automate some testing our accounting team is doing --- in the test area! Lo and behold I can't use the API to clean up a bunch of test prices, and, well, that really stinks. I see zero reason why deleting prices via the API should be blocked from the test environment.

Second, I even feel that in the production area, it should be allowed as well via API. First, it's the end user's data, and if they make a mistake and want it GONE, that should be their choice. Since people (and especially accountants -- haha!) make mistakes a lot, and since there are numbers involved and the potential for fat-fingering, a good UX for an API-centric product like Stripe is supposed to be would allow this --- or at least give the user the ability to enable such a 'feature' themselves. It's fine if Stripe wants to think that they need to hold everyone's hand on everything, but you don't. If you want to have a default mode where it is disabled, fine, but give us the ability to enable it and use it if we know what we're doing. And we do.

Just food for thought. Thanks for reading.

remi-stripe commented 3 years ago

I see zero reason why deleting prices via the API should be blocked from the test environment.

One reason is that if we didn't block it, you'd build your entire integration thinking it will just work in Live mode only to discover you're down the day you deploy to production. Consistency between Test mode and Live mode is quite crucial for patterns like this and we do our best to approach it this way when we can

As for the second part of your comment, I don't disagree conceptually but we used to support deletion on the Plan API and I have helped countless developers over the years try to recover from deleting the wrong Plan, re-creating a new Plan with the same id and then being thoroughly confused why 2 subscriptions on the "same plan id" had a different amount charged, etc. There is a lot more to it than just deleting to suppress a mistake and over the years as business grows there is a higher cost than you would expect to supporting real deletion in the API. It doesn't mean we won't bring it back, we're constantly monitoring feedback like this and taking it into account as we evolve our products and APIs and we hear you. I have also shared this thread multiple times internally as we looked into future improvements and changes so it's top of mind for the eng teams maintaining those APIs overall!

sasokovacic commented 3 years ago

@remi-stripe thats why I suggested soft-deletion. This is how you prevent users from doing hard-deletion mistakes and they can do a recovery when they soft-delete something. This is what businesses mostly require from my experiences. Soft-delete should be the default behaviour. As for hard-delete, I agree with pm-bc. Users should be able to remove all their content from the platform if they want. But it should be done explicitely which means you should send some extra parameter in the request or use different URI. I do agree with you about consistency. This should be available on both environments.

kg69design commented 3 years ago

@remi-stripe If you monitoring feedback, please, check these real-world examples.

I created 1000+ products thought API with prices. And now these product need to be deleted. What should I do? Delete them manually one-by-one? Or mark them as "Archive" and use search-filter EVERY time when I need to edit products in admin-area?
I created 20+ different prices to one product and now these prices need to be deleted. What should I do again? Delete them manually too? Or mark them as "Archive"? But have your ever try to create or edit price in a product with tons of "Archive" prises?

The main reason of all problems like that is that you do not use your soft by yourselves in real world and do not want to notice the obvious things that make working with your application very difficult.

remi-stripe commented 3 years ago

@kg69design Thanks for the feedback, we'll see if we can make improvements to the Dashboard to make those flows better.

boatcoder commented 3 years ago

Looks like you should read up on db constraints @remi-stripe. Things that are unused should be deletable, things that are in use can only be made inactive. It's worked for relational DBs since the 60s. I know you don't care, you just want to make one of your pain points be someone else's pain point and you have succeeded in doing exactly that.

arian-fallahpour commented 3 years ago

Also, whenever you want to test a certain product during development, you might want to delete it later on so it doesn't clutter everything up. I run into a lot of situations were I quickly create a new product to test the integration of my API with stripe, then have to manually delete it later.

nicholi commented 3 years ago

Addendum about Price object usage. It's not just the usage in active Subscriptions which will make it undeletable. I noticed creating new Invoices from within the dashboard will create a "one-time" interval Price object. Also you can accidentally create the same price value twice in two objects (if you manually enter the value amount rather than select from dropdown in Product selection). Once this price_id gets used in a finalized Invoice, now it's basically undeletable because it is used in 1 transaction. As invoices can never be removed, and now it's part of that transaction history. Can only archive and ignore clutter in Dashboard. Not part of any active Subscriptions at all.

I fully understand the necessity to keep these objects around for the transaction history of an invoice (which is meant to be eternal). Hoping we can get a more ignore/soft delete type feature, as long as the Price object is removed from any active transactions and its only existence is in old invoices like these. As sometimes we literally do not need the Price object anymore (and possibly created in err or in testing), and the only thing it does is clutter lists in Dashboard as archived and requires being filtered out in list calls to API as well (even though that is fairly simple to handle as well, by default it would be listed though).

boatcoder commented 3 years ago

Would not mind a truncate feature for all the data in test mode

On Thu, Sep 23, 2021 at 2:21 PM Nicholas Schell @.***> wrote:

Addendum about Price object usage. It's not just the usage in active Subscriptions which will make it undeletable. I noticed creating new Invoices from within the dashboard will create a "one-time" interval Price object. Also you can accidentally create the same price value twice in two objects (if you manually enter the value amount rather than select from dropdown in Product selection). Once this price_id gets used in a finalized Invoice, now it's basically undeletable because it is used in 1 transaction. As invoices can never be removed, and now it's part of that transaction history. Can only archive and ignore clutter in Dashboard. Not part of any active Subscriptions at all.

I fully understand the necessity to keep these objects around for the transaction history of an invoice (which is meant to be eternal). Hoping we can get a more ignore/soft delete type feature, as long as the Price object is removed from any active transactions and its only existence is in old invoices like these. As sometimes we literally do not need the Price object anymore (and possibly created in err or in testing), and the only thing it does is clutter lists in Dashboard as archived and requires being filtered out in list calls to API as well (even though that is fairly simple to handle as well, by default it would be listed though).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stripe/stripe-python/issues/658#issuecomment-926088742, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENX3UMFOMAGVHLB5CXNGDLUDN42RANCNFSM4NKC4RLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

MehdiSaffar commented 3 years ago

Truncate test data or bulk deletion/update active state would be very helpful

olan-a21 commented 2 years ago

Deleting a price should be in any environment. There are many reasons a delete should be implemented. If users want to delete them, allow it, it's their choice if they want to delete or archive them.

zefir-git commented 2 years ago

If deletion of prices is impossible, perhaps then listing all prices should by default be active=true and if someone needs to list all inactive/archived prices (for whatever reason), they could send a different API request to see just these. Similarly, in the dashboard, archived prices could be filtered out from suggestions when creating new products or invoices. Basically, archiving a price would soft-delete it, allowing you to still get it by ID, but it is not actively displayed on the Dashboard or in the default prices list, reducing the processing of useless data with the API that is required to be there for archival/log purposes and making the dashboard UI cleaner.

However, I can see how such a change in the API could break applications that use archived prices differently than me, so perhaps developers that do not want to see archived prices in lists should just always use active=true in their API requests to filter out inactive prices.

top-master commented 2 years ago

In my case, I just wanted to migrate form Plans to Prices, but all these deleting errors show up.

Because you seem to force setting active=false (instead of deleting).

Now, please force that kindly on us developers, you ask "how?", well, like whenever we call delete(...), you should silently set active=false and save(...) (also, fix your Dashboard to really hide Prices).

boatcoder commented 2 years ago

I think @top-master you have been fooled into thinking they care, based on the way this is STILL broken after a full year, it is obvious, they don't

remi-stripe commented 2 years ago

@boatcoder that's a pretty surprising comment. We do care, we listen to feedback, we explain our thought process and we also try to clarify why we do things a certain way. We've built dozens of features based on feedback from developers here, on public mailing list, on our Discord server or to support.

We won't be able to build everything though and we don't always agree that something should be built or designed in a certain way. For example we disagree that deleting should not delete and subtly marked it as inactive but still existing. It's not wrong, but it's also not how deletion has worked historically in our API.

That definitely doesn't mean we don't care and that we don't listen.

boatcoder commented 2 years ago

So if you do care, why can I not delete a price that hasn't been used by anything? Why can I not delete a product (that has never been used) because it has a price I can't use? I could see preventing this deletion because of FK references, but even in my DB, I can remove all the things that reference something or pass CASCADE to the deletion to make things go away for real.

The fact that someone else had a problem after they deleted their prices prevents me from deleting test prices (that are unused) seems ludicrous at best.

If you truly want to make it easier for developers, maybe you shouldn't handcuff so tightly. Enforce consistency just like SQL has been doing since the 60s, everyone should understand that model if they are a developer. These jagged edges that exist in the stripe test mode world are pain points for us and more than a year after this has been reported and echoed by lots of people, it's still busted.

That's what I call neglect, not care.

On Thu, Apr 7, 2022 at 9:52 PM remi-stripe @.***> wrote:

@boatcoder https://github.com/boatcoder that's a pretty surprising comment. We do care, we listen to feedback, we explain our thought process and we also try to clarify why we do things a certain way. We've built dozens of features based on feedback from developers here, on public mailing list, on our Discord server or to support.

We won't be able to build everything though and we don't always agree that something should be built or designed in a certain way. For example we disagree that deleting should not delete and subtly marked it as inactive but still existing. It's not wrong, but it's also not how deletion has worked historically in our API.

That definitely doesn't mean we don't care and that we don't listen.

— Reply to this email directly, view it on GitHub https://github.com/stripe/stripe-python/issues/658#issuecomment-1092391177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENX3UOWVIOVZYDYWCCOT3LVD6NOJANCNFSM4NKC4RLQ . You are receiving this because you were mentioned.Message ID: @.***>

remi-stripe commented 2 years ago

I have explained multiple times in this thread why we don't plan to support Prices deletion for now. Caring about it doesn't mean doing what you're asking us to do. We are listening to the feedback, we iterate a lot, we change things. We don't change it all. You say "echoed by a lot of people", and there's definitely engagement here, that doesn't mean this is echoed by the majority of developers who use our API.

Let's wait for other people to chime, calling this "neglect" is not really bringing anything new to the discussion

WsK commented 2 years ago

Let me translate what Remi said in plain, non-corporate language.

"We make a lot of things here at Stripe. There are tons of little things people complain about, but we are the monopoly now. We can afford to have grumpy developers and customers, I mean what can they do today? Use Braintree, it is 2022, we rule here."

To be fair to Stripe， all companies make decisions this way though if they address every complaint the customers have they won't be able to make new money-making features. You can really only care when you are small, just the nature of the game.

beninsydney commented 2 years ago

This issue would probably collect more feedback if it was left open. I certainly think we should have the option to purge everything, I know this has been a common complaint for the developer mode for years that we can't just reset testing data via API.

sasokovacic commented 2 years ago

@WsK @remi-stripe It seems you're pretty ignorant. I wouldn't call it complaining when people make reasonable arguments and offer solutions to solve the issue. Deleting stuff from apps is a common sense. And some of us also offered a solution that is commonly used in applications, which is soft-delete by default and explicit hard-delete with extra param. With this solution your argument about the danger of accidental price deletion no longer has any basis. You don't need majority for this. You only need to check what is the common practice in the industry. Also, developers are capable of thinking with their own heads and don't need Stripe parents to watch out for them. We can handle the danger of price deletion especially when it's elegantly solved with soft-deletion.

WsK commented 2 years ago

@WsK @remi-stripe It seems you're pretty ignorant. I wouldn't call it complaining when people make reasonable arguments and offer solutions to solve the issue. Deleting stuff from apps is a common sense. And some of us also offered a solution that is commonly used in applications, which is soft-delete by default and explicit hard-delete with extra param. With this solution your argument about the danger of accidental price deletion no longer has any basis. You don't need majority for this. You only need to check what is the common practice in the industry. Also, developers are capable of thinking with their own heads and don't need Stripe parents to watch out for them. We can handle the danger of price deletion especially when it's elegantly solved with soft-deletion.

If you actually read my response, I was simply offering my perspective on how companies like Stripe prioritize things, since most people don't have experiences making priority calls on large scale products. A lot of time, we get frustrated with this or that, but if you were the product owner, that's just one of many feedback / complaints you receive. What frustrated to you in the grand schema is not that big of deal. I was obviously annoyed by missing this feature too, otherwise I wouldn't find this thread. Again, it is not like Stripe doesn't know how to implement this feature, it is just not high priority.

But thank you for reminding me leaving comments on thread like is a waste of time.

hdwebpros commented 2 years ago

@remi-stripe "Let's wait for other people to chime"

Chiming in here too.

"We are listening to the feedback"

Here's more feedback. A solution that is commonly used in applications is soft-delete by default and explicit hard-delete with extra param.

If you can delete a product through the GUI, you should be able to via API. That's my $0.02.

My other $0.02 is that since this is such an actively engaged topic, marking this issue as closed is equivalent to shutting down the conversation. I respectfully request this to be reopened so devs, who are engaged with this issue, and are also engaged on Github, have a place to communicate about this. Most of this conversation is respectful, and we will continue to conversate in that manner -- we just wish to have a forum to discuss this very prevalent issue and have our feedback at least 'listened to'.

Thanks

remi-stripe commented 2 years ago

I hear you on a place to discuss feedback. Github issues are limited to bugs/feature requests with the library itself right now which is why this originally got closed. Our advice is to raise this directly with our support team since the request can be tracked and associated with your Stripe account. I do know it seems less scalable as you can't easily build on other people's feedback.

We do have a mailing list called api-discuss to discuss API features and changes. It is less suited for long running feedback like this one but it could work. You'll see I reply to most of those myself and have for many years!

I'll reopen this issue as an exception though. I do agree engagement needs to happen somewhere and this could be found even by people not specifically using stripe-python.

wlarch commented 2 years ago

I have stumbled upon this thread after testing the Stripe API. I just created multiple products programmatically with a default price on my testing environment. While I want to delete those products, I get an error :

(Status 400) This product cannot be deleted because it has one or more user-created prices.

When I want to "Archive" the price prior to delete the product, I get the following error :

(Status 400) This price cannot be archived because it is the default price of its product.

Is there anything I am missing out in order to delete the products I have created for testing purposes ? 🤔

remi-stripe commented 2 years ago

@wlarch you can call the Update Product API and unset the default price by passing default_price: '' and then you will be able to archive both.

wlarch commented 2 years ago

@remi-stripe Thanks for the feedback, but when I set the default_price to an empty string value or null value, the price is correctly archived. Although, I still get the following error while trying to delete the product :

Uncaught (Status 400) This product cannot be deleted because it has one or more user-created prices.

I am unable to delete the product. I suppose I can only archive it by updating its active field to a false value. We should be able to delete the product using the API, like we can do in the Stripe Web UI.

remi-stripe commented 2 years ago

Gotcha but then this is expected right now and similar to the rest of this discussion! We'll keep monitoring feedback but for now you should set active: false in that case!

fdiasr commented 2 years ago

@remi-stripe I need some help. In order I can't delete the prices/products using API / lib, can I delete multiple products created in Test Mode ? In our integration, we are creating many products that is not necessary after tests, but to keep things working as expected maybe we can run these tests again. I just want to keep data from test environment cleaner.

Also, is there a limit for product and price registration ?

sasokovacic commented 2 years ago

Keep getting responses to my email inbox. it seems that this conversation will go on forever. I don't get it. There are many possible solutions if you're afraid for companies that could accidentally delete prices and products. I've already mentioned one of them. The other solution for example would be to add some system setting that could enable or disable soft and hard deletion. By default it can be set to false. But if a developer wants, he/she can change it. In this case the developer accepts full responsibility for any loss. Before the change the developer gets a huge alert with IMPORTANT note that informs him/her about the danger enabling this feature and if it's enabled, the stripe team is not obligated to restore any of the lost items. This is probably my last post in this conversation. I think you have enough arguments to enable the deletion. You can continue to ignore them or you can do something about it. It's up to you. I'm leaving this conversation.

remi-stripe commented 2 years ago

@fdiasr You can't delete Products or Prices and you should aim to leave those and mark them as inactive. You can also delete all test data in your account otherwise if you want to start fresh. This is really an integration support question, please work with our support team for help on this instead: https://support.stripe.com/contact

boatcoder commented 2 years ago

That's funny. I've had really amazing HELP from the support team. NOT EVER.

You keep seeing this come up because it causes us problems. Sure we can just mark them inactive (delete could do the same thing instead of throwing an error) but since you @.***), in your infinite wisdom have decided the API should be broken in this way you keep getting complaints.....

In Mexico the women complain about being murdered, they call it femicide. The official position is to oppose and/or suppress any women who are protesting femicide because the real problem is that the women are upset, not that they are being killed.

Here the problem is that you can hack together a workaround for a broken API so the problem is you aren't hacking correctly, not that the API is broken.....

On Fri, Aug 12, 2022 at 8:04 PM remi-stripe @.***> wrote:

@fdiasr https://github.com/fdiasr You can't delete Products or Prices and you should aim to leave those and mark them as inactive. You can also delete all test data in your account otherwise if you want to start fresh. This is really an integration support question, please work with our support team for help on this instead: https://support.stripe.com/contact

— Reply to this email directly, view it on GitHub https://github.com/stripe/stripe-python/issues/658#issuecomment-1213620470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENX3UNGTO2OYE3FV4W2REDVY3YDPANCNFSM4NKC4RLQ . You are receiving this because you were mentioned.Message ID: @.***>

rmjwilbur commented 2 years ago

Ran across this after discovering no way to delete a price and can't specify a price id via the API.

Deleting prices

I've done many integrations with customers over the years so I get the challenges supporting them. However, technically it's pretty easy to allow deletes of unused entities, and return an error message if it's been used.

In the test data, I expect to be able to run unit tests so I can be reassured my integration still works properly, and neither of us has changed anything unexpectedly. When I look at the dashboard, I expect there is no unit test data afterwards so I know I didn't create any orphaned entities, which could indicate a failure that didn't report an error.

I also have test data that I expect to be there as I have a test application. Having its data mixed with unit test data that doesn't get cleaned up automatically is messy, and makes it harder to confirm my application works properly.

I expect to also be able to delete unused prices in live mode. I've seen many cases where a customer has created live data by mistake. We should be able to clean up an accidental mess if we need to. If we don't, there's additional risks of someone else thinking it is real data, and using it by mistake.

Price id

While there is provision for a lookup_key, I don't find it friendly to have to use the search option to find a price record. Also, in the case of a unit test, this is cumbersome as I can not find the price record immediately after creating it as there is a delay in the lookup_key's data becoming available. I don't want to have my test wait for an indeterminate amount of time, and I don't want to store cross reference keys for everyone I integrate with. As with product id, I would rather specify my own price id.

Effective dates

While dealing with prices, I'd like to mention that a standard use case is to populate prices in advance of price changes, using an effective date. While I may be able to find a workaround via the lookup_key, it would be nice if there was a documented provision and example for this use case.

Thanks for listening

ROBERT-MCDOWELL commented 2 years ago

Ran across this TOO after discovering no way to delete a price and can't specify a price id via the API. well Stripe Team, it's up to you to congest your database with billions and billions prices and products increasing despite of a few percentage will be used for various reason (test, not using anymore, mistakes etc...) I don't call this consistency but stupidity, sorry for my French....

humayunghani commented 2 years ago

@remi-stripe Still not resolved? Are there any plans to resolve this in future or should we just forget it?

remi-stripe commented 2 years ago

No plan to change this behaviour for now. This is a thread to raise the feature request, but that's it. We're monitoring it, not ignoring it.

eybel commented 2 years ago

I just implemented an API, not having the DELETE price Obj brings problems. I decided to change the "active" status to false but then now my "lookup_key" still gets used by this inactive price obj, so now I have to update the future 'archived' price object because I need that look_up key.

This Stripe API should definitly bring in the "delete" feature to objects (producs/price) also the "update" for pricing doesnt let you update the price itself, but all the others paremteres. Do you realize its called update?

This is some how frustrating...

andrewbaxter commented 2 years ago

@remi-stripe what does delete in the web ui do?

Edit: Also, are there limits for how many prices can be created including active=false prices?

urosjarc commented 1 year ago

Leaving my take on this...

When I started testing STRIPE how it works I first didn't know about test mode. I created a lot of invoices prices, items etc... I tested how you guys manage this stuff... And if stripe is good platform to do my business...

Then in my application I created e2e to test my implementations and create a bunch of elements on live mode...

After some time I found test mode in which I then test stuff from that point on...

And now I'm going live... Have to live with garbage data that I have created at the begining before knowing about testing mode.

keithwhor commented 1 year ago

I really don't think there should be an option to delete prices in the admin dashboard but no option to delete programmatically using the API. That's the primary cause of most of this back and forth IMO.

My suggestion;

If you can delete prices via dashboard, we should have programmatic / API access to the same endpoint for consistency.
If you refuse to implement a prices.del method, it should be removed from the dashboard for the same reason.
Realistically, if a price is unused, we probably should be able to delete it - the delete-if-fail-archive pattern is relatively straightforward and in modern JS, for example, just a simple try / catch
The dashboard Products page currently shows $X.XX USD / month if only one Price exists, otherwise it shows {x} Prices when multiple prices exist for a product, even if archived: this makes it more difficult to monitor live prices from the dashboard (requires an extra click).
I think if you're unwilling to change the API, a quick dashboard fix (e.g. https://dashboard.stripe.com/test/products) that shows a summary on the Products page of the currently active price(s) will get over some of the "deletion anxiety" you see cropping up here

stripe / stripe-python