#mounirmtl

1 messages ยท Page 1 of 1 (latest)

frozen ivyBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

ivory oasis
#

Don't think search is supported for Accounts API endpoint

#

What's the usecase?

#

yeah search is only supported on the list here
https://stripe.com/docs/search

Query fields for charges
Query fields for customers
Query fields for invoices
Query fields for PaymentIntents
Query fields for prices
Query fields for products
Query fields for subscriptions

native socket
#

We have different services that need to communicate with stripe and only holds the stripe account id so far.

Instead of trying to published an event for those other services to get access to the store stripe_account_id, I've been wondering if it was possible to add our own store_id as a metadata to the stripe account and filter accounts with that metadata...

#

So we don't have to sync data around

ivory oasis
#

Instead of trying to published an event for those other services to get access to the store stripe_account_id, I've been wondering if it was possible to add our own store_id as a metadata to the stripe account and filter accounts with that metadata...
Not sure I fully grasp this
Can you share an example?
Just want to make sure I am on the same page before recommending anything ๐Ÿ˜…

native socket
#

We use micro services and they each have their database instances. So far the only services that needed to deal with stripe was our billing service who's responsible for well.. billing ๐Ÿ˜…

As you might have guessed based on our previous discussion, we're starting a new subscription based product. And stripe needs to be aware of products and prices since subscriptions are tied to a price and product_id.

So it'd mean that our catalog service (which handle product data) and our sales service (which handle product prices and cart) need to create products on our merchants' connect accounts so they can create subscriptions based on those products..

#

For that we need our catalog service and sales service to be aware of the connect account stripe id to add products and prices on their connect account.

#

I hoped that we could retrieve an account, somehow, by using metadata..

#

Done ๐Ÿ˜…

ivory oasis
#

You could map it on your end though right? Instead of storing metadata on Stripe object (account object), you could just map the connected account ID in your DB to whatever metadata you want. That way you don't need to call Stripe's Accounts API at all and can handle it on your end

native socket
#

Yeah that's what we did for our billing service.
But now turns out our catalog service our sales service needs it too. I could fire up an pubsub event to let other services know. But I was hoping to avoid that

ivory oasis
#

yeah I think that'd be comparatively more efficient anyway as Search API calls are heavy (based on number of the connected account you have and can only increase from that point on)

native socket
#

interesting...

#

We rely heavily on search for payment_intents

#

That's where all our orders data basically live. They're just metadata on a payment_intent object

ivory oasis
#

Hmm yeah.. I mean our APIs are fast but from an efficiency perspective, search and list calls will always be computationally more taxing with all the filters and everything..

#

essentially it comes down to your usecase/need.

native socket
#

I mean mostly we embraced the fact the we didnt own our billing data for orders so we decided that we might as well rely solely on stripe to retrieve it rather than trying to stay in sync with you.

Everything else about orders like customers, products doesn't live in stripe

ivory oasis
#

Gotcha. Can't think of any other workarounds for this unfortunately.