Skip to content
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

Refactor payment method registration to include all registered payment gateways #10380

Open
mdmoore opened this issue Feb 14, 2025 · 0 comments
Labels
category: refactor The issue/PR is related to refactoring. focus: checkout payments impact: high This issue impacts a lot of users as reported by our Happiness Engineers. priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.

Comments

@mdmoore
Copy link
Member

mdmoore commented Feb 14, 2025

Describe the bug

Currently, WooPayments conditionally registers payment methods for the checkout block, filtering out those that are ineligible based on requirements like country, total, etc. This is problem because WooCommerce core expects all registered payment gateways to have a matching call to registerPaymentMethod() and WooPayments registers each UPE payment method as a gateway, via register_gateway() in PHP. Relevant code here. When a registered gateway does not have a matching call to registerPaymentMethod(), a warning is displayed in the checkout editor stating that the missing payment method is incompatible with the checkout block. This is a false positive and only occurs due to the mismatch described above.

One situation that triggers this warning occurs when an enabled payment method has a minimum purchase amount, and the logged-in admin has items in their cart that do not meet that minimum. The checkout block relies on StoreAPI data for cart totals; therefore, the enabled payment method is not registered via registerPaymentMethod() in that scenario.

Ideally, all payment methods should be registered via registerPaymentMethod() and their display should be controlled via canMakePayment as opposed to conditionally registering each payment method.

This might also be an opportunity to ensure payment method names are displayed properly in the checkout block editor. For example, when the Payment Options block is highlighted, a list of payment methods appears in the sidebar. Rather than detailing each enabled payment method, WooPayments is duplicated for each payment method:

Image

To Reproduce

  1. Enable Affirm in the WooPayments settings
  2. On the front end, add < $50 worth of items to the cart. The Affirm minimum is $50.
  3. Open the checkout page in the editor
  4. See the incompatibility warning.

Actual behavior

WooPayments payment methods are not always registered via registerPaymentMethod() which can lead to false incompatibility warnings.

Screenshots

Expected behavior

WooPayments payment methods should all be registered via registerPaymentMethod() and no incompatibility notices should appear.

Additional context

  1. A good thread on the topic - p1739531148782289/1739228658.873269-slack-CU6SYV31A
  2. Payment methods do not declare support for Cart and Checkout blocks if they cannot be enabled in the Payments settings #9363 (comment)
@mdmoore mdmoore added category: refactor The issue/PR is related to refactoring. focus: checkout payments labels Feb 14, 2025
@pierorocca pierorocca added type: bug The issue is a confirmed bug. priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. impact: high This issue impacts a lot of users as reported by our Happiness Engineers. labels Feb 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: refactor The issue/PR is related to refactoring. focus: checkout payments impact: high This issue impacts a lot of users as reported by our Happiness Engineers. priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.
Projects
None yet
Development

No branches or pull requests

2 participants