Centralize Swift checkout message ingress validation

[markmur]

What changes are you making?

This PR centralizes Swift message admission behind an internal CheckoutMessageIngressPolicy.

Incoming WebKit messages now pass through an internal CheckoutMessageIngressPolicy before reaching the checkout protocol client:

let ingressPolicy = CheckoutMessageIngressPolicy(
    configuredOrigins: ShopifyCheckoutKit.configuration.allowedMessageOrigins,
    checkoutURL: loadedCheckoutURL
)

switch ingressPolicy.evaluate(message, in: self) {
case .accepted:
    break
case let .rejected(rejection):
    // Rejected messages are untrusted input, not checkout lifecycle failures. Warn and
    // drop them without allowing unrelated page activity to terminate a healthy checkout.
    OSLogger.shared.warn(
        "Rejected checkout message from \(rejection.origin): \(rejection.reason.logDescription)"
    )
    return
}

// Only admitted messages continue into the existing checkout protocol handling.

The WebKit-specific overload adapts authenticated frame, origin, and request URL metadata into the policy's transport-neutral IncomingCheckoutMessage model. The core evaluator remains independently testable, while the WebView call site no longer assembles admission metadata itself.

The policy validates that metadata before a message reaches the checkout protocol client. Keeping this decision at the native WebView boundary means the protocol client can focus on handling admitted checkout protocol messages rather than transport trust.

Rejection behavior

A rejected message means that specific input was not trusted. It does not mean the checkout session failed: checkout may be displaying an external surface that also posts messages, and unrelated page activity must not be able to terminate an otherwise healthy checkout. The rejection branch logs the warning inline and returns before protocol processing begins.

• Rejected child-frame, origin, and explicit-port-zero messages are logged at warning level and dropped.
• Rejected messages never reach the checkout protocol client.
• Rejection does not transition PreloadState to .failed or evict the preload.
• Rejection does not create a CheckoutError or call .onFail / checkoutDidFail(error:).
• The rejection model remains internal because this approach does not expose a public diagnostics stream.

Consumer API

Consumers only configure the origins they trust. The existing lifecycle APIs remain reserved for actual checkout failures:

ShopifyCheckoutKit.configure {
  $0.allowedMessageOrigins = [
    "https://checkout.example.com",
    "https://*.example.com",
  ]
}

There is no message-rejection subscription. Rejections remain an internal security signal that is warning-logged and dropped.

React Native consumer API

No React Native event or callback is added. Rejected native messages are warning-logged and dropped; they do not dispatch onFail:

checkoutKit.present(checkoutUrl, {
  onFail(error) {
    // Called for checkout lifecycle failures, not rejected messages.
    reportCheckoutFailure(error);
  },
});

---

Before you merge

Important

• I've added tests to support my implementation
• I have read and agree with the Contribution Guidelines
• I have read and agree with the Code of Conduct
• I've updated the relevant platform README (platforms/swift/README.md and/or platforms/android/README.md)

[markmur]

• Centralize Kotlin checkout message ingress validation #645
• Centralize Swift checkout message ingress validation #644 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[bitrise]

Install this build

Open Tophat, select your target device, then click Install. Links open on the Mac running Tophat.

SDK	Install
Swift	Install with Tophat

Checkout Kit E2E results

Status	Suite	Target	Platform	OS version tag	Device
✅	swift-ios	swift	ios	latest	iPhone 15 iOS 27 Beta