#aeo_unexpected

1 messages · Page 1 of 1 (latest)

timber mountainBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1476759342232371323

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

abstract mango
peak basin
#

sure... i can... but this isn't any particular search..

#

i've noticed duplicate customers, and identified this as the issue

#

let me see if I can find one where it should have returned a result

abstract mango
peak basin
#

sure, give me a sec... here are two customers:

#

cus_U0ZDkMTNDaVZYD

#

cus_U0ZDt2MRBSH2Ul

abstract mango
peak basin
#

having a little struggle finding the search, please give me a minute

#

through the api

#

var customers = customerService.Search(searchOptions, GetAccountLevelRequestOptions);

            if (customers.Data.Count > 0) {
                return customers.Data[0].Id;
            }
#

var customerService = new CustomerService();
var searchOptions = new CustomerSearchOptions {
Query = "metadata['uschedule_customerId']:'" + cust.Id + "'",
Limit = 1
};

abstract mango
#

Hmm, I just tested it out on my end, it took around ~1-2 seconds

peak basin
#

this would be the request that didn't return data.. i think

#

req_KHK6bSknfiWpx0

#

this was the request that created it

#

req_oCm56RrWrbSxDg

#

so 30 seconds later, I searched for that customer, and it didn't return results, so I created a new one

abstract mango
#

Don’t use search for read-after-write flows (for example, searching immediately after a charge is made) because the data won’t be immediately available to search. Under normal operating conditions, data is searchable in under 1 minute. Propagation of new or updated data could be delayed during an outage.

For read-after-write flows that require immediate data availability, use the various list APIs, such as List invoices). These APIs aren’t subject to the availability delays mentioned above.

peak basin
#

right, but I >> can't << use metadata for list.. right? my question i guess, is can i use List with "email" as a backup, if my searhc by metadata returns no results?

#

and that is not subject to the delay... so it should be there..

#

?

#

if I retrieve a customer from the "list" endpoint, will the return data contain my metadata? so I can cross check my local ID against the meta data?

abstract mango
#

Actually, before I reply to that question, could I clarify why is there a need to find the Customer immmediately after creation?

Because after the Customer creation API /Method call, the created Customer object is immediately returned by the API/Method call

peak basin
#

i knew you would ask that..

#

yeah, i know its not a good design... its just a wierd quirk on my side with how i'm storing data, and what it means..

#

we integrate with a bunch of processors...

#

and we have a reference for each providers "customerid", but in our system, that means that there is a "saved card" associated with that profile.

#

so.. with stripe, I can't necessarily save the "customerID" until I know I have a stored payment method

#

its dumb.. i know, its just kind of the way it is, and I wasn't up for rewriting the whole thing

abstract mango
#

I see, thanks for the clarification!

#

and we have a reference for each providers "customerid", but in our system,
Do you store this Customer ID in the DB or somewhere? Because if you do, you could also just use the Customer ID to call the Retrieve Customer API [0], it takes in the ID as a parameter and outputs the whole Customer object with metadata

[0] https://docs.stripe.com/api/customers/retrieve?lang=curl

peak basin
#

so, when a customer is creating a saved card (payment_method)...i want to create a "stripe customer" to associate it to... but if that that payment method fails validation... then I can't save it (the card) and update my side's "stripe customerid", because there isn't a saved card yet.

#

if its a success... then i can update my sides "customerid" and everything is happy..

#

its really not a problem "after" a succesful card is saved, because I create the stripe customer, and save the id on our side... its this weird zone between when the first attempt to save a payment_method fails... and I can't update the ID on our side, because there is no saved card yet.

#

if i "could" I would just check to see our side for the id, then if i don't have a stripe customer id, create one, and link it. the problem is that saving that "stripe customer id" against our customer "means something different"... it means that there is a saved card... not that there is a linked customer... which is the bad design, and I know.. just its legacy stuff I don't wany to refactor and reintroduce bug possibilitues

#

so, i have a "GetOrCreateStripeCustomer" that I call when am attempting to save a card... that first runs a query... and then creates one if not found..... (it doesn't do this after a customer has already been created...only for new ones)

#

i "think" though... if I run a list by email.. and check the metadata for my customerid... that will be sufficient..

#

the only question, is if the metadata will be present on the list endpoint.

#

i'm guessing that "list" will be faster than "search" ... but idk

abstract mango
#

its this weird zone between when the first attempt to save a payment_method fails... and I can't update the ID on our side, because there is no saved card yet.

Hmmm, I can see two ways to check if saving a payment method has succeeded for the Customer:

  1. Retrieve via Retrieve API [0]/ List API [1]
    The metadata should be present there in each Customer object, this will be better than search, because as mentioned before, search needs to index the objects.

  2. Webhook events
    If you have a webhook service running [2], you can consider listening to the setup_intent.succeeded [3] to know that the setupintent to create a saved payment method for future use has succeeded for which Customer

[0] https://docs.stripe.com/api/customers/retrieve
[1] https://docs.stripe.com/api/customers/list
[2] https://docs.stripe.com/webhooks
[3] https://docs.stripe.com/api/events/types#event_types-setup_intent.succeeded

peak basin
#

ok, i think if I switch from "search" to "list" and use the emailaddress and a parameter, compare the metadata to my current customer, and its a match, i return that result... if not that means, that either its a different customer with the same email, or there was no results, and I should create a new customer. Does this sound reasonable?

#

@abstract mango it's fine if you don't answer immediately, I'd just like some confirmation that my new approach seems like it would solve the issue I'm experiencing. Thank you.

abstract mango
#

Does this sound reasonable?
Yup generally sounds okay to me. Just that there might be duplicated Customers for the same email address (as you noted), so you would need to watch out for that.

timber mountainBOT
#

⛔️ Stripe developers have stepped away for a short while

Please leave your questions here, and we’ll respond as soon as we're back! If you need help urgently, you can contact Stripe support for help.