#blurwocky
stark inlet
serene terrace
While I'm not sure what the error code "means", the only thing I can think of that would have caused the error:
- I had triggered the initPaymentSheet once using an idempotency key, and the subsequent presentPaymentSheet succeeded with successful payment.
- re-triggering the initPaymentSheet against the same idempotency key works, but subsequent presentPaymentSheet fails. The error code isn't helpful to know that it probably is failing because the payment intent succeeded.
tepid plover
For initPaymentSheet and presentPaymentSheet?
serene terrace
@tepid plover Discord is saying I can't paste it here, how would you like me to provide the snippet? (Your message could not be delivered. This is usually because you don't share a server with the recipient or the recipient is only accepting direct messages from friends. You can see the full list of reasons here)
tepid plover
That's odd. You should be able to just copy/paste your code between 3 backticks like this
Or you should be able to attach a txt file if you want to dump it in there
Otherwise a Github gist or something similar works
serene terrace
tepid plover
I think this is an issue caused by calling init and present back-to-back as opposed to calling init on view load and then present on a button click
Can you try either adding a short timeout before calling present or can you pull that out and call it on a separate click handler for a test so we can verify if that is the issue?
serene terrace
I tried adding a 5 second timeout, will try on view load then separate button click 👍
tepid plover
The timeout didn't fix things?
How are you calling initializePaymentSheet?
And have you tried hardcoding a client secret and Customer ID?
Hmm actually I don't think the back-to-back calls should be an issue here. I just tested that myself and it works fine.
serene terrace
I think I figured it out - narrowed it down to the idempotency key.
- Call initPaymentSheet with an idempotency key
- Call presentPaymentSheet and successfully complete payment against that paymentIntent
- Later
- Re-call initPaymentSheet with the same idempotency key - this returns the same paymentIntent that was created before - but no metadata is provided to indicate that it's already been paid
- Attempt to call presentPaymentSheet and encounter the
StripePaymentSheet.PaymentSheetError error 3.error - In absence of more meaningful error messaging, I suspect this is because you can't present a paymentSheet to fulfill a paymentIntent that is already completed
tepid plover
When you say:
Call initPaymentSheet with an idempotency key
You mean you are setting an idempotency key on the PaymentIntent that you are creating and then using that same key again to try to create a new PI the next time?
So you are passing in an "already-consumed" client secret
Yep
Okay I can repro that
serene terrace
yes - not so much that we're trying to create a new PI, more that the mobile app encountered an unrelated error and then wasn't aware that the paymentIntent succeeded - or perhaps due to a bug in processing the webhook events, our system isn't aware that the client has already paid the PI - so, we attempt to recreate the PI for the same key
tepid plover
The operation couldn’t be completed. indeed isn't a super helpful error message
tepid plover
yes - not so much that we're trying to create a new PI, more that the mobile app...
Gotcha
serene terrace
Is there a more appropriate way to shore up that with more resiliency than using an idempotency key? I was thinking to embed our key as metadata on the PI, then query for an existing / completed PI based on metadata before attempting to create a dupe PI
tepid plover
Idempotency keys are designed for safe server-side retries when you don't get a definitive network response.
Mostly I think you are on the right track that you should create your PI with metadata that is associated to the order, then if you are going to retry again client-side you can list PIs for the Customer and check to see if that PI for that order is still incomplete or not.
serene terrace
Okay, I think that addresses my use case. Would it be worth opening a GH issue against that error message (since it's super unclear)?
tepid plover
Nah I already flagged it for improvement internally!