Implementing Apple Pay In-App Provisioning in a WKWebView app

We are developing a native iOS financial application called Tradu: Stocks, Forex, and CFDs (Apple ID: 6473443264), which embeds a WKWebView to render all user-facing logic. All user interactions—including authentication with MFA—occur inside this WKWebView.

To access native functionality, we use postMessage() to communicate between the web and native layers. This approach has worked successfully for biometric authentication, for example.

We are currently integrating Apple Pay In-App Provisioning and have a few questions regarding compliance with the documentation provided by our Issuer Host (Modulr). In the document titled Getting Started with Apple Pay: In-App Provisioning, Verification, Security, and Wallet Extensions (Version 4.0, February 2023), all examples are based on a fully native application.

We’ve managed to integrate most of the In-App Provisioning flow via postMessage() up to the point of passing encryptedData to the Payment View.

  1. Apple Pay button inside WKWebView

In Section 7: Frontend Overview, the user initiates the provisioning by tapping a native PKPaymentButton (SwiftUI example). In our case, this button is rendered inside the WKWebView, styled according to the Apple Style Guide. While the document references this approach as a “raw mark text supplement,” is this method acceptable and compliant with Apple’s UX and technical guidelines?

  1. MFA requirement before provisioning

In Section 4: Security Guidelines, it is stated that the user must have passed MFA at least once before starting the provisioning flow. In our implementation, users must complete MFA on every login (including on recognized devices) before the provisioning UI becomes available. Even though this is not tied specifically to “unrecognized devices,” is our MFA requirement sufficient to satisfy Section 4.2?

Summary:

  1. Is using a web-rendered Apple Pay button inside WKWebView (instead of a native PKPaymentButton) considered compliant?
  2. Is our MFA enforcement model (required on every login) aligned with the security requirements outlined in Section 4.2 of the Apple Pay In-App Provisioning documentation?

Hi @ComsiComsa,

On the button: If you proceed with a web-rendered button, ensure it uses Apple's official badge assets verbatim and verifiably triggers PKAddPaymentPassViewController. The native button overlay pattern eliminates all residual risk.

On MFA: Treat MFA-on-every-login as necessary but not sufficient. The highest-priority gap to address is adding an explicit step-up MFA challenge at the moment provisioning is initiated, scoped to that specific action -- regardless of when the user last authenticated.

On both: Your entitlement program agreement with Apple's partner team (obtained via Modulr as your issuer host) is the authoritative source and supersedes all published documentation. Engage your Apple Pay partner engineer contact to validate both the button implementation and the MFA model before submission. Apple Pay typically offers a technical review as part of the provisioning entitlement process specifically for this purpose.

Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Implementing Apple Pay In-App Provisioning in a WKWebView app
 
 
Q