POC - Centralized payment method definitions #10217
Conversation
… with the new centralized payment definitions.
…payment method ID.
Test the buildOption 1. Jetpack Beta
Option 2. Jurassic Ninja - available for logged-in A12s🚀 Launch a JN site with this branch 🚀 ℹ️ Install this Tampermonkey script to get more options. Build info:
Note: the build is updated when a new commit is pushed to this PR. |
|
Size Change: +834 B (0%) Total Size: 1.29 MB
ℹ️ View Unchanged
|
includes/payment-methods/Configs/Interfaces/BNPLPaymentMethodDefinition.php
Outdated
Show resolved
Hide resolved
includes/payment-methods/Configs/Traits/BNPL_Payment_Method.php
Outdated
Show resolved
Hide resolved
includes/payment-methods/Configs/Traits/BNPL_Payment_Method.php
Outdated
Show resolved
Hide resolved
includes/payment-methods/Configs/scripts/generate-payment-method-configs.php
Outdated
Show resolved
Hide resolved
includes/payment-methods/Configs/Traits/Base_Payment_Method.php
Outdated
Show resolved
Hide resolved
This reverts commit 70ec9bd.
I also got rid of the payment method class constants that were referring to another constant to get the ID. That required changes in a few other places to address errors. I added a new get_keywords() method to be able to implement these into the duplicate detection service.
…method "stripe_id"
…nd the build process
…y others we may need in the future.
…tion and move that functionality to a util class since it should largely be the same for all payment method definitions
…yment-method-definitions
There was a problem hiding this comment.
The approach you have here is really good and smart - I bet it wasn't easy to create the abstraction to support the use cases we have now.
I think you proved the viability pretty well by having Affirm/Afterpay/Klarna.
Tomorrow I'll take a closer look at better understanding the build steps and the complexity/extendability needs in case we need more use cases for the other "special" payment methods (like Alipay and the different supported currencies at checkout, which are based on the account's country).
Great job so far!
This reverts commit dccdc2d.
There was an issue with `require.context` not being available in Jest since it's a webpack thing. We're now mocking the CreatePaymentMethodIconComponent instead.
…github.com/Automattic/woocommerce-payments into poc/centralized-payment-method-definitions
|
@frosso this is ready for another review. There have been some significant changes since you last reviewed it.
|
There was a problem hiding this comment.
Thank you for the additional ping! I also appreciate the smaller PR approach 👍
I think building the definitions from the server-side and dynamically injecting them into the front-end via a JS variable sounds like a good approach 👍
So good that I think aligns pretty well with what I was attempting in my PR before I noticed your refactor here 🤣 #10376
One question: is there some flexibility in this approach to build the supported currencies or supported countries dynamically based on the account's country (for example)? I am asking because I see that the PaymentMethodDefinitionInterface::get_currencies() is a static method.
In your mind, would the payment method need to call \WC_Payments::get_account_service()->get_cached_account_data() statically to get the account data and the account's base country?
Asking because we're using this requirement in Klarna_Payment_Method and Alipay_Payment_Method, for example.
Possibly, though I think there's value in having
I guess it depends on the answer above. I'm ok with it doing that or accepting an |
@frosso One thing I noticed about this while looking into actual implementation of a new payment method is that this line is getting payment method data from a hard-coded list. Was it going to be part of your (in progress) PR to make that dynamic? Just thinking about how we can get rid of these lists that exist throughout the code base. I think it makes sense for |
Fixes #10400
Changes proposed in this Pull Request
This PR introduces a centralized system for defining payment methods in WooCommerce Payments, significantly reducing the complexity and maintenance burden of implementing new payment methods. Previously, adding or modifying payment methods required changes across multiple files with duplicated logic. This new architecture provides a single source of truth for payment method definitions.
This PR was born out of a POC for centralizing payment method definitions to reduce the amount of changes that need to be made while implementing (or removing support for) a new payment method. It's resulting from #10098
Once I've added the appropriate unit tests, I'll mark the PR as ready but, given it's size I thought it'd be good to get an initial review.Initially, I had converted Affirm, Afterpay/Clearpay, and Klarna to use the new definition system, but @FangedParakeet suggested I remove those changes so we're only reviewing the base functionality in this PR. All payment methods will be converted to use the new definition and registration system in separate issues (to be created). So this PR doesn't technically introduce any change in functionality for any payment method.
Testing instructions
npm run changelogto add a changelog file, choosepatchto leave it empty if the change is not significant. You can add multiple changelog files in one PR by running this command a few times.Post merge