#joethefox-ios
1 messages Β· Page 1 of 1 (latest)
Hi π could you clarify what you mean when asking us to verify a transactionId?
I have an Id in the form pi_1234ABC to check
I have the issue that with a confirmPayment, I got a STPPaymentHandlerActionStatusFailed with iOS SDK but the user is charged.
Gotcha, could you share that Payment Intent ID here? I believe I've seen that error surfaced when multiple attempts are made to confirm an intent.
yes, in the truth there is only one call. The error dump says "com.stripe.lib:ErrorMessageKey" = "The current action is not yet completed. STPPaymentHandler does not support concurrent calls to its API.";
the id is pi_3LT8n5CHPGFnU95t0JBlsy4S
I chatted with karllekko the other day. He asked me to provide this error dump
Based on what I'm seeing, it does look like that payment was successful. Could you tell me what your app was attempting to do when it encountered that error?
sure, I can share the code if you want
here:
I have done literally thousands of tests in test environment and never encountered this issue, last two weeks I had four live events, more thank 6k transactions and just a small part of them with this error, about 50.
And do you know which part of that code is executing when the error is encountered?
case STPPaymentHandlerActionStatusFailed: { // NSLog(@"STPPaymentHandlerActionStatusFailed %@", error); [self cancelledOrderId:orderId message:[NSString stringWithFormat:@"Stripe %@ %ld - %@", NSLocalizedString(@"Errore", nil), (long)error.code, error.localizedDescription] transactionID:paymentIntentParams.stripeId userInfo:[NSString stringWithFormat:@"%@", error.userInfo]]; NSString *responseMessage = NSLocalizedString(@"Si Γ¨ verificato un errore durante l'aggiornamento delle informazioni. Riprovare piΓΉ tardi.", nil); if (![error.localizedDescription isEqualToString:@""]) { responseMessage = error.localizedDescription; } [self simpleAlertWithTitle:[NSString stringWithFormat:@"\u26A0 %@ %ld", NSLocalizedString(@"Errore", nil), (long)error.code] message:responseMessage closeButtonTitle:NSLocalizedString(@"Chiudi", nil)]; [self setInterfaceEnabled:YES]; break; }
STPPaymentHandlerActionStatusCanceled case is the same code
That's a switch statement, so it's being driven by the status variable, that's being returned by confirmPayment. So you're attempting to confirm a payment when that error is encountered?
yes
first I create a payment intent, server to server, get the client_secrect and intent_id from my server and then I call the confirmPayment.
I followed this flow: https://stripe.com/docs/payments/accept-a-payment?platform=ios&ui=custom
Did the error message include any reference to a request ID? It would start with req_. Looking at the Payment Intent, I only see the creation and confirmation request, and those were both successful so I'm trying to track down any useful information about the error you're seeing.
nope. This is the complete error.userInfo:
{ NSLocalizedDescription = "There was an unexpected error -- try again in a few seconds"; "com.stripe.lib:ErrorMessageKey" = "The current action is not yet completed. STPPaymentHandler does not support concurrent calls to its API."; }
The payment intent I posted at the beginning comes from a customer complains.
There are cases with the same error that aren't charged.
For example looking at my logs I have this payment intent pi_3LTB8BCHPGFnU95t0EJO98Vl from a couples of minutes ago with the same error but I don't know if the user was charged. Nobody is complaining right now π
π I'm hopping in - let me take a look
You're sure there's no way for confirmPayment to accidentally be called twice in your app, correct?
In life the only two sure things are death and taxes. Let me check my flow
I have a controller, called CheckOutViewController that contains different user payment methods.
Based on which one is called I present a view controller, In this case StripeCardFieldViewController.
StripeCardFieldViewController collects the user's info, call the server to create the intent and then execute this code
[self dismissViewControllerAnimated:YES completion:^{ [[NSNotificationCenter defaultCenter] postNotificationName: @"MeccanismiAppStripePaymentIntent" object:nil userInfo:stripeDict]; }];
In CheckOutViewController there is a registration to this notification
[[NSNotificationCenter defaultCenter] addObserver: self selector: @selector(handleStripePaymentIntent:) name: @"MeccanismiAppStripePaymentIntent" object: nil];
where handleStripePaymentIntent is the method I posted at the beginning
Hmmm... and there isn't anything else posting that "MeccanismiAppStripePaymentIntent" notification?
no
I can put a semaphore (arghh) in handleStripePaymentIntent for unique payment intents, even if I never had the issue to be called twice.
I'm presenting an alert view controller that would have fired a log warning or even during the tests, internal and customer's closed ones, with the stripe test enviroment we had this issue. Neither one single failure.
Just thinking out loud - while you were testing, did you make sure to test with any of the 3ds triggering test cards? (I don't think this would be the problem, but just want to make sure)
I tested, at least once, ALL the cards in your guide. Just for fun , I remember one day I tested every card, from every country and with every error
Gotcha (and thanks for confirming that)
π
Can you show me a bit more of your StripeCardFieldViewController code - specifically the parts that are calling your server and then executing dismissViewControllerAnimated ?
Okay just confirming some things here:
- You can only reproduce this in live mode with real payments reported from your users
- There's no way that you know of to reliably reproduce this in your test environment for now
And just asking some questions:
- Do you have any more details from your customers about what their exact flow is when they reproduce the error? Just trying to narrow down if there's a way to reliably reproduce
- Are there any other logs that you have available to you that may help out here? It's tough to know where to go from here w/o being able to reproduce, so hoping there's something that can point us in the right direction
Q: You can only reproduce this in live mode with real payments reported from your users
A: Yes
Q: There's no way that you know of to reliably reproduce this in your test environment for now
A: Impossibile to reproduce. In my company I have a stripe account too. I tested ten 1 EURO consecutive payments in live mode just to test out. All successfull.
Q: Do you have any more details from your customers about what their exact flow is when they reproduce the error? Just trying to narrow down if there's a way to reliably reproduce
A: It's hard to talk with customers. I was in an event last week and the customer didn't told me anything special, just the alert after the pay button. To remark: I only put the orders in "Annulled" status only when I receive a STPPaymentHandlerActionStatusFailed or STPPaymentHandlerActionStatusCanceled.
All the issues reported from the customers are "Annulled" in my backend.
Q: Are there any other logs that you have available to you that may help out here? It's tough to know where to go from here w/o being able to reproduce, so hoping there's something that can point us in the right direction
A: sadly no, but I'm happy to add logs to the error log sent back to the backend. Suggestions are welcome π
One thing maybe can be useful: we are talking about mobile payments made during music festivals, with thousands of people in the same place. The 4G/5G connections are degraded and there could be the "Stadium effect" (that's why we store informations in rfid wristbands, but it's another story).
Interesting... Can you also share which version if the ios sdk you're using?
last one at the moment of the app publishing, 22.6.0
@bitter siren thank you for your time. We will reach out here?
Do you have to head out?
it's midnight here, tomorrow work. I need some sleep π
I can stay a bit more if necessary
In terms of next steps, the best thing to do would be to send out an email to support@stripe.com and mention you spoke to karbi and we can continue digging in from there
Discord is hard to manage for questions that need repeated back/forth and deep investigation (email is better for this and I'll grab the ticket on my end once you email in)