#jaunt-archived-products-dashboard

1 messages · Page 1 of 1 (latest)

visual walrus
#

I'm seeing that view populate with some archived products on my own test account - do you have a specific example of an archived product you're not seeing in that view?

grand jewel
#

Thanks for checking. Let me find an example.

#

So prod_KbsDTcFTphMAB3 says it's archived, but won't show up when I look at products / archived.

visual walrus
#

Hmm.... that's very strange. Give me a bit to dig in further

grand jewel
#

thanks!

visual walrus
grand jewel
#

Hmm, let me think how I can do this quickly. Is there a way to make api calls in the dashboard?

dawn briar
#

no you can't make API calls in the Dashboard

grand jewel
#

ok so I'll probably have to make a function in my production back end and deploy it.

#

shouldn't take me too long

dawn briar
#

@grand jewel you don't really need to

#

that specific product was created with price_data and product_data on Checkout and in that case the product is just not shown in the Dashboard

grand jewel
#

I see. but might be possible to get it through the API you are thinking?

#

That would be good because this kind of relates to another issue under investigation where adhoc created products are re-using old products instead of creating new ones.

#

I need to find out which customers ended up with products with meta data from other customers.

#

For example if I create a product with a name "LESSON", and add meta data specifying which lesson, that doesn't work if the products aren't uniquely created.

dawn briar
#

You can explicitly retrieve that product via the API yes, but you can't mutate/change it

grand jewel
#

that's ok, I just need to see which customers are messed up. I've now changed the system not to rely on meta data in products at all.

#

But if I request all inactive products, will I get ones that were created in checkout?

dawn briar
#

I don't think so but I can try quickly, give me 5

grand jewel
#

thanks

dawn briar
#

doesn't work unfortunately, those are "ad-hoc" products and we don't really surface them on their own. But you can retrieve them directly

grand jewel
#

I see. So I can get all subscriptions, find out which product they are tied to, then retrieve that product.

dawn briar
grand jewel
#

Ok that's cool.

dawn briar
#

and get the entire info in one call

grand jewel
#

Nice.

#

I'm glad we're just a startup with not too many customers yet. Ha. How adhoc products are being reused is hard to understand. My guess is under the hood when you try to create a new one, it's looking for existing active ones by name only. But that it throws out the meta data and uses the old meta is a head scratcher.

dawn briar
#

I'm surprised we would ever re-use a product under the hood

#

if you have an example I can check

grand jewel
#

These two products were created yesterday by customers (adhoc), yet the meta data came from products created in october. I don't see how I could have accidentally done that because if you look at ddcode in my meta data, it's the current webapp version, and I don't keep that info around, so yesterday's products having a month old version info means it came from the old products I think.

prod_KZKU82XL8IlRzG
prod_KZKUrheku9W0we

dawn briar
grand jewel
#

ok I don't understand that.

#

but thank you -- I have a hard time not believing that.

dawn briar
#

I can look further if you want

grand jewel
#

Thanks. I'm trying to figure out what's going on but jumping all over the place. Also hard since I can't see the archived products.

Super confusing what's happening. I wonder if something is wrong with the go code I'm using, like somehow data is crossing between api call to my backend.

#

Is there a way to see which customer or subscription is attached to prod_KZKU82XL8IlRzG?

dawn briar
grand jewel
#

OK. I'll finish this function to get all subscriptions first.

grand jewel
#

Ps for listing subscriptions as you mentioned above with expanding items.data.price.product, is that possible? It says I should be expanding "data.items" instead, but would that break the 4 depth limit?

#

anyway, I seem to get a lot of data about everything without expanding at all.

proud dove
#

hey there, just catching up

#

items.data.price.product is only 4 levels, so that should be fine

#

are you having issues with it?

grand jewel
#

Hi thanks! It's because it's from the list subscriptions route, so it's a list that gets returned. I guess I could make that call for each one.

proud dove
#

ah so on a list request the expansion needs to start with the data. layer to refer to each iterated item

#

and that does count as a layer, yes

#

ie, listing subscriptions you be limited to expand[]=data.items.data.price

grand jewel
#

ok thanks! Almost got it working. Then to figure out what else is going on 🙂

proud dove
#

Sounds good, let us know if you need any help 🙂

grand jewel
#

thanks!

grand jewel
#

Hello, I found an anomaly that I can't explain:

This event is a subscription update: evt_1JuA2PDqsmyGk25Qw5NYcxom

It's for: sub_1JgdV6DqsmyGk25Q0ldmCXns

Which is attached to this product: prod_KXig2H6oc3CMLq

But in the event, items[0].data.plan.product is set to prod_KUDn0vkxNFZPMd, and so is plan.product.

It's only under "previous_attributes" that the correct product shows up as prod_KXig2H6oc3CMLq.

prod_KUDn0vkxNFZPMd is for a product that was created on Oct 27, adhoc for a completely different user: vt_1JpFLeDqsmyGk25Q71spgREV

tulip drift
#

Hello! Let me take a look, hang on...

grand jewel
#

Thank you kindly!

tulip drift
#

In this request (which is the one that generated the customer.subscription.updated above) you're updating the Subscription to use price_1JpFLeDqsmyGk25QKzaDKafR which is a Price for Product prod_KUDn0vkxNFZPMd: https://dashboard.stripe.com/logs/req_5DO14LfbDKcRmR

#

The event data is reflecting the change you made.

grand jewel
#

ok that's helpful.. I will take a look thanks!

grand jewel
#

I think this entire mess-up was caused by a colleague attaching an adhoc price to a different customer. He tried to downgrade a customer from premium to standard, but the drop down just populates with a bunch of same-named prices, so it's impossible to know they have specialized meta data in the interface.

tulip drift
#

That could be. One thing to note is that Prices in Stripe cannot be attached to Customers. What's your use case for creating Prices for each Customer?

grand jewel
#

I guess I meant products. When a user wants to "check out", I had been creating ad-hoc products to send to the checkout session. I attach meta data to those products. We have our own product catalog and so we don't want to maintain a separate version in the stripe dashboard. This works well seemingly. A couple confusing things though, is that in the stripe dashboard under products, you can't see products created in this way, nor can you export them. Yet when you are adjusting someones subscription, they seem to pop up there.

tulip drift
#

Products can't be attached to Customers either.

grand jewel
#

Well they can indirectly

tulip drift
#

Sure, but not in any functional/meaningful way.

#

We don't surface the Products/Prices you create ad-hoc for one-off purchases in most places because doing so would quickly overwhelm your reusable Products/Prices.

grand jewel
#

Makes sense.

#

I can't quite figure out why some do pop up.

tulip drift
#

But you're saying the ad-hoc Prices are showing up when you edit a Subscription?

grand jewel
#

Well, there are a bunch of products that show up under "Products" and I would have thought they are all adhoc as we don't ever create them in the dashboard, but they are only a subset of products. I think those are the ones that show up when editing a subscription.

#

Could it have to do with a user editing one in the customer portal or something? Here's one example of one showing up: prod_KYtToSTnwea3Ya

tulip drift
#

To clarify, are we talking about Products or Prices?

grand jewel
#

Products, sorry.

tulip drift
#

It was not created ad-hoc.

grand jewel
#

So I guess somehow the way I am creating them in golang is either making them reusable or not.

#

I see.

#

So when the customer wants to go to the customer portal to manage their subscription, I create products, But when they originally buy them they are adhoc. Damn.

tulip drift
#

So when the customer wants to go to the customer portal to manage their subscription, I create products

Can you expand on this? I don't understand why you would create a Product prior to sending someone to the Customer Portal.

grand jewel
#

Well because I create adhoc products in the first place, I need to be able to send them to the portal with a second subscription to upgrade or downgrade to. When they first purchase they already chose standard or premium.

#

It's quite crazy -- I had some help here with setting it up 😉

#

And when creating new prices to attach to their portal session, I couldn't see a way to do it adhoc. I remember that now.

tulip drift
#

I understand you don't want to maintain your product catalog in Stripe, but I think you might be shooting yourself in the foot by trying to do all this ad-hoc. What if you added your products to Stripe as they're used instead of all at once up front?

grand jewel
#

Ha, I definitely already have a bullet hole in my foot!

I guess I'd have to search for them and reuse if I find them? As long as products were truly fixed, in that they had a consistent ID matching their attributes, I guess that could work. For a while we were selling lesson and have hundreds of them, and course packs that changed all the time.

But now just a few subscriptions which would be easier. Hmm

#

And I'm sure there's a way to make sure the user always gets both tiers available when managing their subscription.

#

But for example, we are planning on adding a third tier, so then we'd still have to massage existing products to match that third tier.

The way I have it now, is I detect their current subscripton, scan our own catalogue for matching tiers, and rebuild their choices before they go to their protal.

#

Maybe the solution is to not use stripe checkout.

tulip drift
#

The easiest approach long-term by far is going to be to create all your Products in Stripe up front.

grand jewel
#

And just do it manually.

tulip drift
#

Failing that, if you create them as they're used and save the Product and Price IDs on your end alongside the product and price info you already have, you'll then know when to add stuff to Stripe: if there's no Stripe ID for it, create it and save the ID.

grand jewel
#

It's super painful as well as we have multiple prices for each country.

#

We actually did what you are saying originally. Here's what a product looked like back then. And then if we want one for each lesson and course pack, the dashboard way got massively annoying. Json was so much better and we could use git.

#

prod_GBEBaUMhkZynF2

tulip drift
#

The way you're doing it now is going to eventually end up with the same situation; all the Products will eventually be in Stripe as more and more people use the Portal.

grand jewel
#

A solution could be to somehow create them adhoc... shouldn't that be possible?

#

Or is that only when sending to checkout session?

tulip drift
#

If you create them adhoc they're not going to show up in the Portal.

grand jewel
#

that's fine

#

It's better that they don't

tulip drift
#

Wait, I think we might be talking past each other.

#

I'm saying that if you create a Product/Price adhoc they will not show up in the Customer Portal. I'm referring specifically to the scenario where your customer is being sent to the Portal to up/downgrade.

#

Meaning adhoc will not work for your use case.

grand jewel
#

oh -- I see what you mean.

#

sorry

tulip drift
#

No worries! Just wanted to make sure we're on the same page. 🙂

grand jewel
#

why wouldn't they show up? I guess because they have to be reusable.

tulip drift
#

The Portal would end up with thousands of options if adhoc Prices showed up.

grand jewel
#

For customer portal? But right now only the two I create and attach via "subUpdate" show up,

# 
            Enabled:               stripe.Bool(true),
            Products:              catalogue,
            DefaultAllowedUpdates: []*string{stripe.String("promotion_code"), stripe.String("price")},
            ProrationBehavior:     stripe.String("always_invoice"),
        }
#

Should it matter whether the products in the catalogue I send are adhoc or not?

# 
        BusinessProfile: &stripe.BillingPortalConfigurationBusinessProfileParams{
            PrivacyPolicyURL:  stripe.String("https://singdaptive.com/privacy"),
            TermsOfServiceURL: stripe.String("https://singdaptive.com/terms"),
        },
        Features: &stripe.BillingPortalConfigurationFeaturesParams{
            InvoiceHistory: &stripe.BillingPortalConfigurationFeaturesInvoiceHistoryParams{
                Enabled: stripe.Bool(true),
            },
            PaymentMethodUpdate: &stripe.BillingPortalConfigurationFeaturesPaymentMethodUpdateParams{
                Enabled: stripe.Bool(true),
            },
            SubscriptionCancel: &stripe.BillingPortalConfigurationFeaturesSubscriptionCancelParams{
                Enabled: stripe.Bool(true),
            },
            SubscriptionPause: &stripe.BillingPortalConfigurationFeaturesSubscriptionPauseParams{
                Enabled: stripe.Bool(true),
            },
            SubscriptionUpdate: subUpdate,
        },
    }
#

I mean using this billing portal configuration.

tulip drift
#

The normal use case for adhoc Prices is when you have a Product you charge variable amounts for. That Product would end up with dozens, hundreds, or even thousands of adhoc Prices as a result. If we showed every adhoc Price for that Product in the Portal it wouldn't make sense.

grand jewel
#

Ok that makes sense. I'm just confused because I have many "reusable" products but only the two I specify in subscriptionupdate show up, so I figured if I specified adhoc prices in subscription update that might work.

tulip drift
#

I don't think that would work. It's worth a try, but I imagine it won't.

grand jewel
#

I guess alternatively I could archive active products after they are "used"?

tulip drift
#

Yeah, I suppose that would work, but you're really going against the grain of how Stripe is designed to work here. You're likely to keep running into rough edges and issues and will probably end up expending more effort if you continue trying to do everything adhoc instead of going with the intended flow and adding all of your Products and Prices to Stripe as they exist in your catalog.

grand jewel
#

Ok will ponder that. I know you are right. But it's not insignificant how error prone it is to manage a catalog through a dashboard like that.

#

No version control etc.

tulip drift
#

I'm not suggesting you manage it through the Dashboard.

#

It's probably best to set up a scheduled task that runs some code that makes sure Stripe is up to date periodically.

grand jewel
#

I see. So a function that takes my json store and syncs it to stripe. I like that.

tulip drift
#

I'm thinking something that goes through each Product/Price on your end, checks to see if there's already a Stripe ID associated with it, if not it creates and stores one, and for archived/deleted/whatever Products/Prices you could fetch the associated Stripe Product/Price and make sure it's also archived.

grand jewel
#

Ah yes.

tulip drift
#

Then you run that as often as you need to keep everything up to date. Maybe on a schedule, maybe when certain Product/Price updates take place on your end, maybe a combination.

grand jewel
#

Yes. Ok I'm with you. I appreciate the help. I think that's totally doable.

tulip drift
#

I recommend creating a new Stripe account dedicated to testing just this code. You never need to activate it, just use it in test mode with this code. Each time you run the code you can verify the info, then use the Delete all test data... button to reset and test fresh again after making changes: https://dashboard.stripe.com/test/developers

grand jewel
#

I already have three accounts (local, dev, and prod) 🙂

tulip drift
#

Deleting all of your test data shouldn't take too long if all you've got are the Products and Prices in there.

grand jewel
#

Make sense.

#

Thank you for the help!