-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crashes handling Apple Pay payments #219
Comments
Hi @roryprior, We're on it! |
Are you getting any closer to finding the cause of this issue? It's been over 8 months and this is the largest source of crashes on our app. We don't have this issue with card payments, it's exclusively Apple Pay. It seems like you're not holding onto the reference for the apple pay view controller strongly somewhere and it's potluck whether it's still in memory when it's accessed. |
We've been unable to reproduce it so far, and we have it in our backlog as it requires further investigation, |
For further context we're seeing this impact about 0.8%-1% of Apple Pay transactions in our app but this still constitutes 700-800 failed transactions each week which isn't really acceptable. With the relatively low failure rate reproduction is difficult, I'd suggest trying to automate it by creating transactions sequentially until failure, but respectfully we shouldn't have to provide a sample project for this we're using your SDK in the way we've indicated and don't see this issue at all on non-Apple Pay transactions so the problem is clearly in the SDK as the code paths are otherwise identical. |
Are you keeping a strong reference to
|
In addition, I see that you're using |
Yes we keep a strong reference to the judo object, invokeApplePay presents as an async method in swift so I guess Apple is doing some behind the scenes magic here, but again we don't have this problem anywhere else we're using async/await with your SDK. When I said the code paths are otherwise identical I meant on our side. A couple of releases ago we changed how we were calling the Apple Pay preauth to try and work around this bug from our end but we're still seeing the same crashes unfortunately keeping our own strong reference to the AP view controller. With this method we're seeing the crash within the continuation executing the completion handler, which is where the crash is occurring using the direct invokeApplePay method.
Crash log:
|
Another solution we're open to if this bug proves intractable is directly invoking Apple Pay ourselves if you could advise on what we'd need to do to achieve that while still working with the rest of your SDK and keeping PCI compliance on your side if that's possible. |
Hi, we're seeing a continual low level number of crashes processing ApplePay payments in production, but it's proving hard to replicate during testing. This is the stack trace we're seeing on Crashlytics: (I've censored our product name)
This is how we're invoking Apple Pay with JudoKit :
We also make the same call with JPTransactionMode.payment elsewhere in our code, it's not clear at the moment which of these is failing but I imagine they share a lot of the same code behind the scenes.
The text was updated successfully, but these errors were encountered: