-
Couldn't load subscription status.
- Fork 694
Support radarOptions for saved PMs with CSC in ConfirmationToken flow #11757
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
Conversation
Add tests to verify that hCaptcha tokens (radarOptions) are properly passed through to confirm params when using saved payment methods with client-side confirmation (CSC) and confirmation tokens. Tests verify: - radarOptions included in confirm params when hCaptchaToken is provided - radarOptions excluded when hCaptchaToken is null Updated test helpers to support CSC flow testing by adding parameters for observing confirmPaymentIntent calls and controlling intent status. Tests currently fail as implementation is pending. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]> Committed-By-Agent: claude
Add radarOptions/hCaptcha support for saved payment methods when using client-side confirmation (CSC) with confirmation tokens. This addresses the gap where radarOptions couldn't be passed for saved PMs in the CT flow, only for new PMs (via payment_method_data.radar_options). Implementation: - Add radarOptions parameter to ConfirmStripeIntentParamsFactory.create(confirmationTokenId) - Thread hCaptchaToken through ConfirmationTokenConfirmationInterceptor CSC flow - Convert hCaptchaToken to RadarOptions when creating confirm params The solution "tacks radar_options onto the confirm params outside of the CT" as discussed, since the ConfirmationToken API doesn't support radar_options directly for saved PMs. This is a CSC-only feature - SSC is not supported (merchant responsibility). Tests verify radarOptions are correctly included/excluded based on hCaptchaToken presence for saved PM + CSC flow. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]> Committed-By-Agent: claude
Remove the unused observedConfirmParams parameter from test helper functions. The radarOptions tests now extract params directly from the action result using asConfirmParams<ConfirmPaymentIntentParams>(), making the Turbine observation of network calls unnecessary. Changes: - Removed observedConfirmParams parameter from createFakeStripeRepositoryForConfirmationToken - Removed confirmPaymentIntent override (never called in CSC flow) - Removed observedConfirmParams from runConfirmationTokenInterceptorScenario signature - Updated radarOptions tests to not pass unused observedParams parameter This simplifies the test helpers and makes them more focused on what they actually need to observe. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]> Committed-By-Agent: claude
|
Diffuse output: APKDEX |
| abstract fun create( | ||
| confirmationTokenId: String | ||
| confirmationTokenId: String, | ||
| radarOptions: RadarOptions? = null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd think we'd always want to specify a value for radar options here. Should we remove the null default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this looks right we should:
- New PMs: Don’t set radar options on confirm, it is already present on payment method data when creating a confirmation token
- Saved PMs: Set radar options at confirm time (not when creating the confirmation token)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For saved payment methods we should confirm the intent with the following args:
- confirmation_token
- radar_options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nvm this is on the create params, not create CT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think this PR has done what is required. I just removed the null default, which is not needed.
| intent = intent, | ||
| confirmationToken = confirmationToken, | ||
| shippingValues = shippingValues, | ||
| hCaptchaToken = null, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this null?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For new PM, radar options is attached in paymentMethodData.radarOptions if provided. hCaptchaToken = null here means we don't need to send radar options when confirming the intent. Sending radar options when confirming the intent is only required for saved PM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth a code comment saying this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yh, this is accurate. For new PMs, radar options is added to the create_params which will be transformed to paymentMethodData.radarOptions
You can find more details here
7d956f9 to
8a54a8a
Compare
Summary
Add radarOptions/hCaptcha support for saved payment methods when using client-side confirmation (CSC) with confirmation tokens. This addresses the gap where radarOptions couldn't be passed for saved PMs in the CT flow, only for new PMs (via
payment_method_data.radar_options)Motivation
The solution "tacks radar_options onto the confirm params outside of the CT" as discussed in this Slack thread, since the ConfirmationToken API doesn't support radar_options directly for saved PMs.
Testing
Screenshots
Changelog