Improve the activate payment step in NOX by streamlining the test account migration #59616
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Open
6 tasks
|
Size Change: -182 B (0%) Total Size: 5.85 MB
|
📝 Walkthrough""" WalkthroughThe changes remove the "activate" sub-step from the WooPayments onboarding business verification flow, including deletion of its component and associated logic. Related API calls and state management for test account migration are updated, and a new payload key is added to signal migration intent during KYC session retrieval. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI
participant API
User->>UI: Start onboarding (business verification)
UI->>API: Request KYC session (with migrate_to_live flag)
API-->>UI: Respond with KYC session details
User->>UI: Complete business and embedded steps
UI->>API: POST to finish onboarding step
API-->>UI: Respond with completion
UI->>User: Navigate to next step
""" 📜 Recent review detailsConfiguration used: .coderabbit.yml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (19)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/index.tsx(1 hunks)plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/sections/activate-payments.tsx(0 hunks)plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/test-account/index.tsx(2 hunks)plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsService.php(1 hunks)
💤 Files with no reviewable changes (1)
- plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/sections/activate-payments.tsx
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-06-30T09:26:55.361Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/components/stepper/index.tsx:57-67
Timestamp: 2025-06-20T13:08:44.017Z
Learning: For WooCommerce Payments onboarding step tracking in useEffect hooks, only include the active step in the dependency array, not the context object. The sessionEntryPoint is static throughout the onboarding session and tracking should only fire on actual step navigation, not context changes.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/sections/activate-payments.tsx:33-35
Timestamp: 2025-06-17T10:52:16.648Z
Learning: In WooPayments onboarding flows, vladolaru prefers to handle error tracking on the backend rather than frontend when API calls like disableWooPaymentsTestAccount() fail.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:484-488
Timestamp: 2025-06-17T11:30:23.806Z
Learning: In the WooCommerce Payments settings provider state tracking system (plugins/woocommerce/src/Internal/Admin/Settings/Payments.php), when an extension is deactivated and its snapshot key disappears, only the 'extension_active' flag should be set to false while keeping other state flags like 'account_connected', 'needs_setup', 'test_mode', etc. unchanged. This is intentional behavior to preserve historical state information.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-06-30T09:26:55.361Z
Learning: Summarize the changes, testing steps, and rationale in a way that is easy for reviewers to understand.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx:43-50
Timestamp: 2025-06-18T07:56:06.961Z
Learning: In plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx, the user vladolaru prefers to keep the current setUpPlugin function signature with optional positional context parameter rather than refactoring to an options object or making context required.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/utils/render-frontend.tsx:0-0
Timestamp: 2025-06-16T16:12:12.148Z
Learning: For WooCommerce checkout blocks, lazy loading was removed in favor of direct imports to prevent sequential "popping" effects during component loading. This approach prioritizes user experience over code splitting, with minimal bundle size impact and improved performance (1.7s to 1.1s speed score improvement). The checkout flow benefits from having all components load together rather than incrementally.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsRestController.php:619-625
Timestamp: 2025-06-17T10:33:54.736Z
Learning: In the WooCommerce WooPayments REST controller, it's acceptable to let ApiException bubble up from onboarding-related method calls like get_onboarding_step_status() and mark_onboarding_step_completed() rather than wrapping them in local try/catch blocks.
Learnt from: vladolaru
PR: woocommerce/woocommerce#59160
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx:0-0
Timestamp: 2025-06-26T14:56:54.917Z
Learning: In WooCommerce payments onboarding components (like plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx), when updating local React state based on API calls, the local state should only be updated after the API call succeeds to prevent inconsistent state if the save operation fails. The pattern is to move setPaymentMethodsState calls inside the .then() callback of the API promise.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:431-439
Timestamp: 2025-06-17T14:19:30.933Z
Learning: In plugins/woocommerce/src/Internal/Admin/Settings/Payments.php, the process_payment_provider_states() method intentionally filters out payment providers that don't have a _suggestion_id. This is by design to only track state changes for gateways from partner extensions, not core WooCommerce gateways or other installed gateways.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:471-475
Timestamp: 2025-06-17T10:59:56.461Z
Learning: In WooCommerce payments settings, when processing payment provider states, if a gateway appears in the payment providers list (from get_payment_gateways()), its underlying extension must be active by definition. Inactive or uninstalled extensions don't have their gateways available, so setting 'extension_active' to true for all processed gateways is correct.
plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsService.php (9)
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:484-488
Timestamp: 2025-06-17T11:30:23.806Z
Learning: In the WooCommerce Payments settings provider state tracking system (plugins/woocommerce/src/Internal/Admin/Settings/Payments.php), when an extension is deactivated and its snapshot key disappears, only the 'extension_active' flag should be set to false while keeping other state flags like 'account_connected', 'needs_setup', 'test_mode', etc. unchanged. This is intentional behavior to preserve historical state information.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:431-439
Timestamp: 2025-06-17T14:19:30.933Z
Learning: In plugins/woocommerce/src/Internal/Admin/Settings/Payments.php, the process_payment_provider_states() method intentionally filters out payment providers that don't have a _suggestion_id. This is by design to only track state changes for gateways from partner extensions, not core WooCommerce gateways or other installed gateways.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:471-475
Timestamp: 2025-06-17T10:59:56.461Z
Learning: In WooCommerce payments settings, when processing payment provider states, if a gateway appears in the payment providers list (from get_payment_gateways()), its underlying extension must be active by definition. Inactive or uninstalled extensions don't have their gateways available, so setting 'extension_active' to true for all processed gateways is correct.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/components/stepper/index.tsx:57-67
Timestamp: 2025-06-20T13:08:44.017Z
Learning: For WooCommerce Payments onboarding step tracking in useEffect hooks, only include the active step in the dependency array, not the context object. The sessionEntryPoint is static throughout the onboarding session and tracking should only fire on actual step navigation, not context changes.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsRestController.php:619-625
Timestamp: 2025-06-17T10:33:54.736Z
Learning: In the WooCommerce WooPayments REST controller, it's acceptable to let ApiException bubble up from onboarding-related method calls like get_onboarding_step_status() and mark_onboarding_step_completed() rather than wrapping them in local try/catch blocks.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/sections/activate-payments.tsx:33-35
Timestamp: 2025-06-17T10:52:16.648Z
Learning: In WooPayments onboarding flows, vladolaru prefers to handle error tracking on the backend rather than frontend when API calls like disableWooPaymentsTestAccount() fail.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx:43-50
Timestamp: 2025-06-18T07:56:06.961Z
Learning: In plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx, the user vladolaru prefers to keep the current setUpPlugin function signature with optional positional context parameter rather than refactoring to an options object or making context required.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/Klarna.php:26-33
Timestamp: 2025-06-17T10:34:20.195Z
Learning: The `KP_Settings_Page::get_setting_status('credentials')` method from the Klarna plugin returns a boolean value, not string values like 'complete' or 'incomplete'. The usage of `FILTER_VALIDATE_BOOLEAN` with this method is appropriate.
Learnt from: vladolaru
PR: woocommerce/woocommerce#59160
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx:0-0
Timestamp: 2025-06-26T14:56:54.917Z
Learning: In WooCommerce payments onboarding components (like plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx), when updating local React state based on API calls, the local state should only be updated after the API call succeeds to prevent inconsistent state if the save operation fails. The pattern is to move setPaymentMethodsState calls inside the .then() callback of the API promise.
plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/index.tsx (6)
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/components/stepper/index.tsx:57-67
Timestamp: 2025-06-20T13:08:44.017Z
Learning: For WooCommerce Payments onboarding step tracking in useEffect hooks, only include the active step in the dependency array, not the context object. The sessionEntryPoint is static throughout the onboarding session and tracking should only fire on actual step navigation, not context changes.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx:43-50
Timestamp: 2025-06-18T07:56:06.961Z
Learning: In plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx, the user vladolaru prefers to keep the current setUpPlugin function signature with optional positional context parameter rather than refactoring to an options object or making context required.
Learnt from: vladolaru
PR: woocommerce/woocommerce#59160
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx:0-0
Timestamp: 2025-06-26T14:56:54.917Z
Learning: In WooCommerce payments onboarding components (like plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx), when updating local React state based on API calls, the local state should only be updated after the API call succeeds to prevent inconsistent state if the save operation fails. The pattern is to move setPaymentMethodsState calls inside the .then() callback of the API promise.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx:76-90
Timestamp: 2025-06-13T13:37:35.793Z
Learning: In plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx, the `shouldAnimate` flag is expected to be `false` only on initial render and may remain `true` after the first edit; it does not need to be reset.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/utils/render-frontend.tsx:0-0
Timestamp: 2025-06-16T16:12:12.148Z
Learning: For WooCommerce checkout blocks, lazy loading was removed in favor of direct imports to prevent sequential "popping" effects during component loading. This approach prioritizes user experience over code splitting, with minimal bundle size impact and improved performance (1.7s to 1.1s speed score improvement). The checkout flow benefits from having all components load together rather than incrementally.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:484-488
Timestamp: 2025-06-17T11:30:23.806Z
Learning: In the WooCommerce Payments settings provider state tracking system (plugins/woocommerce/src/Internal/Admin/Settings/Payments.php), when an extension is deactivated and its snapshot key disappears, only the 'extension_active' flag should be set to false while keeping other state flags like 'account_connected', 'needs_setup', 'test_mode', etc. unchanged. This is intentional behavior to preserve historical state information.
plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/test-account/index.tsx (9)
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/components/stepper/index.tsx:57-67
Timestamp: 2025-06-20T13:08:44.017Z
Learning: For WooCommerce Payments onboarding step tracking in useEffect hooks, only include the active step in the dependency array, not the context object. The sessionEntryPoint is static throughout the onboarding session and tracking should only fire on actual step navigation, not context changes.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx:43-50
Timestamp: 2025-06-18T07:56:06.961Z
Learning: In plugins/woocommerce/client/admin/client/settings-payments/components/other-payment-gateways/other-payment-gateways.tsx, the user vladolaru prefers to keep the current setUpPlugin function signature with optional positional context parameter rather than refactoring to an options object or making context required.
Learnt from: vladolaru
PR: woocommerce/woocommerce#59160
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx:0-0
Timestamp: 2025-06-26T14:56:54.917Z
Learning: In WooCommerce payments onboarding components (like plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/payment-methods-selection/index.tsx), when updating local React state based on API calls, the local state should only be updated after the API call succeeds to prevent inconsistent state if the save operation fails. The pattern is to move setPaymentMethodsState calls inside the .then() callback of the API promise.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/sections/activate-payments.tsx:33-35
Timestamp: 2025-06-17T10:52:16.648Z
Learning: In WooPayments onboarding flows, vladolaru prefers to handle error tracking on the backend rather than frontend when API calls like disableWooPaymentsTestAccount() fail.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx:76-90
Timestamp: 2025-06-13T13:37:35.793Z
Learning: In plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx, the `shouldAnimate` flag is expected to be `false` only on initial render and may remain `true` after the first edit; it does not need to be reset.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/utils/render-frontend.tsx:0-0
Timestamp: 2025-06-16T16:12:12.148Z
Learning: For WooCommerce checkout blocks, lazy loading was removed in favor of direct imports to prevent sequential "popping" effects during component loading. This approach prioritizes user experience over code splitting, with minimal bundle size impact and improved performance (1.7s to 1.1s speed score improvement). The checkout flow benefits from having all components load together rather than incrementally.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/Payments.php:484-488
Timestamp: 2025-06-17T11:30:23.806Z
Learning: In the WooCommerce Payments settings provider state tracking system (plugins/woocommerce/src/Internal/Admin/Settings/Payments.php), when an extension is deactivated and its snapshot key disappears, only the 'extension_active' flag should be set to false while keeping other state flags like 'account_connected', 'needs_setup', 'test_mode', etc. unchanged. This is intentional behavior to preserve historical state information.
Learnt from: vladolaru
PR: woocommerce/woocommerce#58784
File: plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsRestController.php:619-625
Timestamp: 2025-06-17T10:33:54.736Z
Learning: In the WooCommerce WooPayments REST controller, it's acceptable to let ApiException bubble up from onboarding-related method calls like get_onboarding_step_status() and mark_onboarding_step_completed() rather than wrapping them in local try/catch blocks.
Learnt from: samueljseay
PR: woocommerce/woocommerce#59051
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/mini-cart-contents/inner-blocks/mini-cart-footer-block/index.tsx:66-70
Timestamp: 2025-06-23T05:47:52.696Z
Learning: For WooCommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, the standardized conditional pattern for experimental features should be `if ( isExperimentalMiniCartEnabled() ) { blockSettings.save = () => <InnerBlocks.Content />; }` - defaulting to the traditional Save component and only overriding when the experimental feature is enabled.
🧬 Code Graph Analysis (1)
plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/test-account/index.tsx (1)
plugins/woocommerce/client/admin/client/settings-payments/utils.ts (1)
recordPaymentsOnboardingEvent(424-452)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (19)
- GitHub Check: JavaScript - @woocommerce/admin-library [unit]
- GitHub Check: PHP: 8.4 WP: latest [WP latest] 1/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: PHP: 7.4 WP: latest - 1 [WP 6.7.2] 2/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: Core API tests - @woocommerce/plugin-woocommerce [api]
- GitHub Check: Core e2e tests 5/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core e2e tests 6/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: PHP: 7.4 WP: prerelease [WP 6.8.2-RC1] 2/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: Metrics - @woocommerce/plugin-woocommerce [performance]
- GitHub Check: Core e2e tests 4/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: PHP: 8.4 WP: latest [WP latest] 2/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: PHP: 7.4 WP: latest - 1 [WP 6.7.2] 1/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: Core e2e tests 1/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: PHP: 7.4 WP: prerelease [WP 6.8.2-RC1] 1/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: Core e2e tests 2/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core e2e tests 3/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Lint - @woocommerce/plugin-woocommerce
- GitHub Check: Lint - @woocommerce/admin-library
- GitHub Check: Check Asset Sizes
- GitHub Check: build
🔇 Additional comments (4)
plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsService.php (1)
1072-1073: Clean implementation supporting the streamlined migration flow.The addition of the
migrate_to_liveflag effectively signals to the backend whether the current account is a test account, enabling the streamlined migration process without the intermediate "activate" step. The implementation is straightforward and follows the existing payload pattern.plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/business-verification/index.tsx (1)
39-39: Excellent simplification removing unnecessary complexity.The removal of the conditional "activate" step streamlines the business verification flow by eliminating the intermediate step. This change aligns perfectly with the PR objective of simplifying the test account migration process.
plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/test-account/index.tsx (2)
19-19: LGTM! Clean import optimization.The import was correctly updated to only include the functions that are actually used in the component.
94-101: LGTM! Correct context destructuring cleanup.The removal of
refreshStoreDatafrom the destructuring is appropriate since it's no longer used in the component.
Comment on lines
175
to
190
| const handleContinue = () => { | ||
| setIsContinueButtonLoading( true ); | ||
|
|
||
| recordPaymentsOnboardingEvent( 'woopayments_onboarding_modal_click', { | ||
| step: currentStep?.id || 'unknown', | ||
| action: 'activate_payments', | ||
| source: sessionEntryPoint, | ||
| } ); | ||
|
|
||
| setIsContinueButtonLoading( true ); | ||
|
|
||
| // Disable test account and proceed to live KYC. | ||
| disableWooPaymentsTestAccount() | ||
| .then( () => { | ||
| setIsContinueButtonLoading( false ); | ||
|
|
||
| // This will refresh the steps and move the modal to the next step. | ||
| navigateToNextStep(); | ||
|
|
||
| return refreshStoreData(); | ||
| } ) | ||
| .catch( () => { | ||
| // Handle any errors that occur during the process. | ||
| setIsContinueButtonLoading( false ); | ||
| // Error tracking is handled on the backend, so we don't need to do anything here. | ||
| } ); | ||
| apiFetch( { | ||
| url: currentStep?.actions?.finish?.href, | ||
| method: 'POST', | ||
| } ).then( () => { | ||
| navigateToNextStep(); | ||
| } ); | ||
| }; |
There was a problem hiding this comment.
Add error handling and loading state reset.
The function has critical issues that will affect user experience:
- Loading state never resets: The button will remain in loading state indefinitely after success or failure
- No error handling: API failures will be silent, leaving users confused
- Poor UX: Users won't know if the operation succeeded or failed
Apply this diff to fix the issues:
const handleContinue = () => {
setIsContinueButtonLoading( true );
recordPaymentsOnboardingEvent( 'woopayments_onboarding_modal_click', {
step: currentStep?.id || 'unknown',
action: 'activate_payments',
source: sessionEntryPoint,
} );
apiFetch( {
url: currentStep?.actions?.finish?.href,
method: 'POST',
- } ).then( () => {
- navigateToNextStep();
- } );
+ } )
+ .then( () => {
+ navigateToNextStep();
+ } )
+ .catch( ( error ) => {
+ console.error( 'Failed to activate payments:', error );
+ // Note: Error tracking is handled on the backend as per learnings
+ } )
+ .finally( () => {
+ setIsContinueButtonLoading( false );
+ } );
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const handleContinue = () => { | |
| setIsContinueButtonLoading( true ); | |
| recordPaymentsOnboardingEvent( 'woopayments_onboarding_modal_click', { | |
| step: currentStep?.id || 'unknown', | |
| action: 'activate_payments', | |
| source: sessionEntryPoint, | |
| } ); | |
| setIsContinueButtonLoading( true ); | |
| // Disable test account and proceed to live KYC. | |
| disableWooPaymentsTestAccount() | |
| .then( () => { | |
| setIsContinueButtonLoading( false ); | |
| // This will refresh the steps and move the modal to the next step. | |
| navigateToNextStep(); | |
| return refreshStoreData(); | |
| } ) | |
| .catch( () => { | |
| // Handle any errors that occur during the process. | |
| setIsContinueButtonLoading( false ); | |
| // Error tracking is handled on the backend, so we don't need to do anything here. | |
| } ); | |
| apiFetch( { | |
| url: currentStep?.actions?.finish?.href, | |
| method: 'POST', | |
| } ).then( () => { | |
| navigateToNextStep(); | |
| } ); | |
| }; | |
| const handleContinue = () => { | |
| setIsContinueButtonLoading( true ); | |
| recordPaymentsOnboardingEvent( 'woopayments_onboarding_modal_click', { | |
| step: currentStep?.id || 'unknown', | |
| action: 'activate_payments', | |
| source: sessionEntryPoint, | |
| } ); | |
| apiFetch( { | |
| url: currentStep?.actions?.finish?.href, | |
| method: 'POST', | |
| } ) | |
| .then( () => { | |
| navigateToNextStep(); | |
| } ) | |
| .catch( ( error ) => { | |
| console.error( 'Failed to activate payments:', error ); | |
| // Note: Error tracking is handled on the backend as per learnings | |
| } ) | |
| .finally( () => { | |
| setIsContinueButtonLoading( false ); | |
| } ); | |
| }; |
🤖 Prompt for AI Agents
In
plugins/woocommerce/client/admin/client/settings-payments/onboarding/providers/woopayments/steps/test-account/index.tsx
around lines 175 to 190, the handleContinue function lacks error handling and
does not reset the loading state, causing the continue button to remain in
loading indefinitely and leaving users uninformed on failure. To fix this, add a
catch block to handle API errors by showing an appropriate error message or
feedback, and ensure that setIsContinueButtonLoading(false) is called in both
the success and failure cases to reset the loading state properly.
Test using WordPress PlaygroundThe changes in this pull request can be previewed and tested using a WordPress Playground instance. Test this pull request with WordPress Playground. Note that this URL is valid for 30 days from when this comment was last updated. You can update it by closing/reopening the PR or pushing a new commit. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes proposed in this Pull Request:
This PR improves the WooPayments business verification onboarding flow by streamlining the test-to-live account migration process.
Key Changes:
migrate_to_liveflag when the current account is a test accountCloses WOOPLUG-4517
Closes #58563
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
/disable//deleteendpoint is madehttps://dashboard.stripe.com/test/connect/accounts/YOUR_ACCOUNT_ID/activity. Make sure to replace the account id with the one you found in WCPay Dev.logstash.logand delete everything there. This will make it easy to follow the logs, but it is not required.logstash.logfile and search forStarting the deletion of a test accounturl: /wp-cron.php?doing_wp_cron(meaning this was executed via cron) and ajob_dataparameter withhandle_account_async_deletionas themethodname.Testing that has already taken place:
Changelog entry
Changelog Entry Details
Significance
Type
Message
Changelog Entry Comment
Comment