STPApplePayContext hangs after didAuthorizePayment on iOS 26 + React Native New Architecture — "Payment Not Completed"

[owen-appicidea]

STPApplePayContext hangs after didAuthorizePayment on iOS 26 + React Native New Architecture — "Payment Not Completed"

Describe the bug

When a customer pays with Apple Pay via @stripe/stripe-react-native's
confirmPlatformPayPayment({ applePay: ... }), authorization succeeds
(Face ID), the sheet dismisses to a spinner, and the payment never settles —
ending with Apple Pay's "Payment Not Completed". Reproducible on iOS 26.x
devices under the React Native New Architecture (Fabric) + Hermes.

Native instrumentation confirms that on iOS,
confirmPlatformPayPayment({ applePay }) invokes STPApplePayContext.

React Native implementation (failing path)

// @stripe/stripe-react-native 0.74.0 (bundled Stripe iOS SDK 26.6.0)
import { confirmPlatformPayPayment, PlatformPay } from '@stripe/stripe-react-native'

const result = await confirmPlatformPayPayment(paymentIntentClientSecret, {
  applePay: {
    merchantCapabilities: [
      PlatformPay.ApplePayMerchantCapability.Supports3DS,
      PlatformPay.ApplePayMerchantCapability.SupportsCredit,
      PlatformPay.ApplePayMerchantCapability.SupportsDebit,
    ],
    merchantCountryCode: 'HK',
    currencyCode: 'HKD',
    cartItems: [
      {
        label: 'Order',
        amount: (amount / 100).toString(),
        paymentType: PlatformPay.PaymentType.Immediate,
      },
    ],
  },
})

The promise returned by confirmPlatformPayPayment never resolves or
rejects after authorization. We confirmed this by wrapping the call in a
Promise.race with a 90 s timeout plus an AppState watchdog — the
timeout/rejection fires, but Stripe's completion never does.

Root-cause evidence (instrumentation)

We instrumented StripeApplePay/StripeApplePay/Source/ApplePayContext/ STPApplePayContext.swift with NSLog + NotificationCenter posts and
forwarded them into Sentry. Every failing payment shows this exact sequence:

1. presentApplePay completion fired
2. didAuthorizePayment fired ← Face ID authorization accepted
3. _completePayment started
4. … nothing after

Confirmed absent in every failing case:

• PaymentMethod.create completion fired — never logged
• handleSuccess / handleFailure — never called
• didCreatePaymentMethod / didCompleteWith — never called
• No App Hang / ANR event captured — the main thread is not blocked

Conclusion: the flow stalls inside STPApplePayContext after
_completePayment begins — most likely the PaymentMethod.create network
call (or its completion handler) never returns.

To Reproduce

1. React Native app with New Architecture (Fabric) enabled, Hermes.
2. @stripe/stripe-react-native 0.74.0 (bundled Stripe iOS SDK 26.6.0).
3. On an iOS 26.x device, call confirmPlatformPayPayment with an
   applePay config (see snippet above) for a live PaymentIntent.
4. Tap Apple Pay → authorize with Face ID.
5. Observe: spinner → "Payment Not Completed".

Expected behavior

confirmPlatformPayPayment resolves and the PaymentIntent is confirmed.

Actual behavior

The promise never settles; Apple Pay shows "Payment Not Completed".

Environment

• React Native: 0.83.10 (New Architecture / Fabric enabled)
• JS engine: Hermes
• @stripe/stripe-react-native: 0.74.0
• Stripe iOS SDK (StripeApplePay pod): 26.6.0

Devices

• iPhone14,2 — iOS 26.6
• iPhone14,3 — iOS 26.6
• iPhone15,3 — iOS 26.5.2

[wooj-stripe]

Hi @owen-appicidea ,

Thanks for writing in, and sorry to hear you're encountering an issue. Given that didCreatePaymentMethod is never called, it sounds like the call to create the payment method might be having trouble succeeding -- are there any logs/errors/etc you can provide to help us further debug?

[ayushsingh82]

cc @wooj-stripe — spent some time tracing this against the vendored STPApplePayContext.swift (pulled from stripe/stripe-ios) and wanted to share a lead, though I want to flag upfront this is an unconfirmed hypothesis, not a reproduced diagnosis — I don't have the reporter's device/build to verify against.

Ruled out: a dangling-delegate theory (the RN module holding the delegate reference being deallocated mid-flight). StripeSdkImpl is a process-lifetime singleton (@objc public static let shared = StripeSdkImpl(), used throughout StripeSdk.mm), so it can't be deallocated mid-payment.

A structurally-consistent candidate mechanism, inside STPApplePayContext._completePayment:

stripe-react-native's ApplePayViewController.swift implements the legacy completion-block-based STPApplePayContextDelegate (not the newer async ApplePayContextDelegate). After PaymentMethod.create succeeds, _completePayment branches on this:

} else if delegate.responds(to: legacyDelegateSelector),
          let helperClass = NSClassFromString("STPApplePayContextLegacyHelper") {
    // dynamically invoke the legacy delegate method via this helper
} else {
    assertionFailure("An STPApplePayContext's delegate must conform to ApplePayContextDelegate or STPApplePayContextDelegate.")
}

If NSClassFromString("STPApplePayContextLegacyHelper") returns nil at runtime — e.g. the Obj-C class gets dead-stripped by the linker since nothing references it except this string-based lookup — execution falls to assertionFailure, which is a silent no-op in Release builds. No crash, main thread untouched, didCreatePaymentMethod never called, the promise just never resolves. That lines up with every symptom in the report: no ANR, no crash, PaymentMethod.create's own completion path proceeding but nothing downstream firing.

This class of failure (an Obj-C class referenced only via NSClassFromString getting dead-stripped) is commonly tied to static-library linking without an explicit -ObjC linker flag — worth noting stripe-react-native.podspec doesn't set OTHER_LDFLAGS/-ObjC itself. That, combined with how New Architecture Podfiles commonly configure static linking, plus newer/stricter linkers in recent Xcode/iOS SDKs, could plausibly explain why this surfaces specifically under "iOS 26 + New Architecture" rather than universally.

If this is right, the durable fix on our side would be migrating ApplePayViewController.swift's delegate conformance from the legacy STPApplePayContextDelegate to the modern ApplePayContextDelegate async/throws protocol, which bypasses this dynamic dispatch path entirely — but that's a nontrivial migration (different types throughout: StripeAPI.PaymentMethod vs STPPaymentMethod, STPApplePayContext.PaymentStatus vs STPPaymentStatus), so I didn't want to put up a speculative PR without confirming this is actually the mechanism first.

Happy to dig further or attempt the migration if this direction seems worth pursuing — let me know if it's consistent with what you're seeing on the internal ticket.

[owen-appicidea]

New evidence — server-side request logs narrow it down.

For one failing attempt, both network calls succeed but the SDK completion never fires: POST /v1/tokens returns 200 (token created) and POST /v1/payment_methods returns 200 (pm_… created) — but GET /v1/payment_intents/{id} and /confirm are never sent, and the Intent stays requires_payment_method. So this is not a network failure or app suspension: the payment method is created, but PaymentMethod.create's completion ({ result in inside _completePayment) never runs.

Timing also stands out: the token → payment-method gap is ~15 s on the failing attempt, vs. the same second on a successful attempt by the same device minutes later — a sign the completion dispatch is already stalling.

Environment (updated RN to try again): RN 0.86.0 (Fabric/Hermes), iOS 27.0, @stripe/stripe-react-native 0.74.0, Stripe iOS SDK 26.6.0.

Pointing at the code: StripeAPI.PaymentMethod.create(payment:) → Self.create → STPAPIClient.post("payment_methods", …) — the response succeeds server-side but the completion callback is never delivered on the client.

Question: is STPAPIClient.post's completion dispatched via a @MainActor/queue hop that could be dropped under iOS 27 + New Arch? Happy to share exact request/token/payment-method IDs and breadcrumbs off-thread.

[ayushsingh82]

Thanks for digging up the server-side logs — that's a useful constraint, and I think it actually rules out the STPApplePayContextLegacyHelper theory I floated earlier: that failure mode assumes PaymentMethod.create's completion already ran successfully (you need a paymentMethod in hand before you ever reach the legacy-delegate dispatch branch). If the completion at _completePayment's PaymentMethod.create(...) { result in ... } itself never runs, the failure is upstream of where my hypothesis applies. So scratch that one for this report.

On your question — I checked the actual stripe-ios source (current master, same shape as 26.6.0):

• StripeAPI.PaymentMethod.create(payment:) → Token.create → Self.create(params:) → apiClient.post(resource: "payment_methods", object: params, completion:) (PaymentMethod+API.swift)
• That resolves to STPAPIClient.sendRequest (STPAPIClient.swift):

  func sendRequest<T: Decodable>(request: URLRequest, retryCount: Int, completion: @escaping (Result<T, Error>) -> Void) {
      urlSession.stp_performDataTask(with: request, completionHandler: { (data, response, error) in
          DispatchQueue.main.async {
              completion(STPAPIClient.decodeResponse(...))
          }
      }, retryCount: retryCount)
  }

• stp_performDataTask (URLSession+Retry.swift) is a thin wrapper over a plain URLSessionDataTask — it only intercepts HTTP 429 for retry/backoff; every other response (including your 200) falls straight through to completionHandler(data, response, error) unconditionally.

So to answer directly: no, this isn't @MainActor-routed. It's a plain GCD DispatchQueue.main.async wrapping a vanilla URLSessionDataTask callback — no Swift-concurrency structured-task machinery in this path for New Architecture/Fabric to interact with. GCD doesn't silently drop an enqueued main-queue block; once that line executes, the closure will run as soon as the main run loop is free. I don't think a dropped queue-hop is the mechanism.

That pushes the real question one level earlier, into stp_performDataTask: did the URLSessionDataTask's own completion handler ever fire? Given the shape of the evidence — server 200, client never proceeds, ~15s stall, self-resolves on a later attempt — the pattern that best fits is a gap between "server sent the response" and "client's URLSession actually delivered it to that closure": e.g. a mid-response connection drop or network transition (Wi‑Fi↔cellular handover, VPN toggle, Low Data Mode), or the process being briefly suspended while the task was in flight. STPAPIClient's session isn't a background URLSessionConfiguration, so if the app got suspended mid-request, iOS can abandon that task without ever invoking the callback — no crash, no visible main-thread block, because nothing was actually blocked; the callback just never got scheduled.

That's a slightly different claim than "not a network failure" — the server returning 200 doesn't guarantee the client's socket received the full response. Would you be able to check whether there was any network transition (Wi‑Fi/cellular handover, VPN, Low Data Mode) in that ~15s window, or reachability/connectivity logs from the device around that timestamp? That would help distinguish "URLSession callback never invoked" from something else further down.

To be clear, this is source-reading and inference, not a reproduced diagnosis on my end either — happy to keep digging if it's useful.