#joethefox-ios

1 messages Β· Page 1 of 1 (latest)

robust sapphire
#

Hi πŸ‘‹ could you clarify what you mean when asking us to verify a transactionId?

turbid prairie
#

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.

robust sapphire
#

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.

turbid prairie
#

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

robust sapphire
#

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?

turbid prairie
#

sure, I can share the code if you want

#

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.

robust sapphire
#

And do you know which part of that code is executing when the error is encountered?

turbid prairie
#

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

robust sapphire
#

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?

turbid prairie
#

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.

robust sapphire
#

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.

turbid prairie
#

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."; }

turbid prairie
#

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 πŸ˜…

bitter siren
#

πŸ‘‹ 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?

turbid prairie
#

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

bitter siren
#

Hmmm... and there isn't anything else posting that "MeccanismiAppStripePaymentIntent" notification?

turbid prairie
#

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.

bitter siren
#

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)

turbid prairie
#

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

bitter siren
#

Gotcha (and thanks for confirming that)

turbid prairie
#

πŸ‘

bitter siren
#

Can you show me a bit more of your StripeCardFieldViewController code - specifically the parts that are calling your server and then executing dismissViewControllerAnimated ?

turbid prairie
#

sure

bitter siren
#

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
turbid prairie
#

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).

bitter siren
#

Interesting... Can you also share which version if the ios sdk you're using?

turbid prairie
#

last one at the moment of the app publishing, 22.6.0

#

@bitter siren thank you for your time. We will reach out here?

bitter siren
#

Do you have to head out?

turbid prairie
#

it's midnight here, tomorrow work. I need some sleep πŸ˜…
I can stay a bit more if necessary

bitter siren
#

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)