chore: unwrap bridge envelope in ApplePayWebView message handler#48
chore: unwrap bridge envelope in ApplePayWebView message handler#48
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
unickq
changed the title
# Conflicts: # example/src/App.tsx
There was a problem hiding this comment.
Pull request overview
This PR adjusts the Apple Pay WebView message handler to correctly unwrap the injected bridge postMessage envelope so Apple Pay (and iframe height) messages can be interpreted from the inner payload.
Changes:
- Unwrap
__boltBridgepostMessageenvelopes inApplePayWebViewbefore handling height changes and Apple Pay result messages. - Add a root
podscript to runpod installfor the example iOS app. - Update example app configuration/demo code and refresh
example/ios/Podfile.lock.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
src/payments/ApplePayWebView.tsx |
Adds bridge-envelope unwrapping and routes Apple Pay parsing through the unwrapped payload. |
package.json |
Adds a convenience pod script for installing example iOS pods. |
example/src/boltConfig.example.ts |
Updates the example config template (currently includes a concrete publishable key and staging env). |
example/src/App.tsx |
Updates demo state typing and stores Apple Pay results in tokenResult. |
example/ios/Podfile.lock |
Updates the resolved BoltReactNativeSdk pod version/checksum after running pods. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
example/src/App.tsx
Outdated
| }); | ||
| const threeDSecure = useThreeDSecure(); | ||
| const [tokenResult, setTokenResult] = useState<TokenResult | null>(null); | ||
| const [tokenResult, setTokenResult] = useState< |
There was a problem hiding this comment.
May need to rethink or rename this - an ApplePayResult is not just a token but includes other data too. This should be clearer.
There was a problem hiding this comment.
I wanted to rename it to setPaymentResult, but that may not be a payment either. Even if it's just an example app. So removed
unickq
force-pushed
the
mchursin/apple-pay-logs
branch
from
47f1ef5 to
3b47aff
Compare
|
|
||
| const handleMessage = useCallback( | ||
| (event: WebViewMessageEvent) => { | ||
| dispatcher.handleMessage(event); |
There was a problem hiding this comment.
think we may need to discuss the envelope process, because this dispatcher already has an unwrapping process in it, so any changes means changing code in 2 places now
There was a problem hiding this comment.
You're right, but I was focused on fixing the ApplePay flow and wasn't familiar with the dispatcher's unwrapping internals.
There was a problem hiding this comment.
to have this as a result
unickq
force-pushed
the
mchursin/apple-pay-logs
branch
from
3b47aff to
f80a4a5
Compare
Description
This pull request introduces an update to how messages from the native bridge are handled in the
ApplePayWebViewcomponent, ensuring that bridge message envelopes are properly unwrapped before processing.ApplePayWebView Message Handling Improvements:
src/payments/ApplePayWebView.tsxto unwrap bridge postMessage envelopes produced byinjectedBridge.ts, ensuring the actual payload is extracted and parsed correctly before further processing. This improves compatibility with the native bridge message format.parseBoltMessageto use the unwrapped message, preventing issues with nested or stringified payloads.Testing
ScreenRecording_04-02-2026.15-24-54_1.mov
Security Review
Important
A security review is required for every PR in this repository to comply with PCI requirements.
Security Impact Summary
n/a