-
Notifications
You must be signed in to change notification settings - Fork 69
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
fix: ensure BNPL enablement is not adding unnecessary currencies #8212
Conversation
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: 0 B Total Size: 1.26 MB ℹ️ View Unchanged
|
@@ -2747,7 +2747,7 @@ protected function get_account_branding_secondary_color( $default_value = '' ): | |||
* | |||
* @return string The domestic currency code. | |||
*/ | |||
protected function get_account_domestic_currency(): string { | |||
public function get_account_domestic_currency(): string { |
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 changed this from protected
to public
so that it could be called in the PaymentMethodsCompatibility
multi-currency class. I think it's fine?
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 think it's fine, but overall, this method seems to be placed in the unexpected class. I'd expect it to be located somewhere in the includes/class-wc-payments-account.php
near get_account_country()
and get_account_default_currency()
methods :)
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.
All good, thank you @frosso! 🚀
Changes proposed in this Pull Request
When BNPL methods are enabled (either via onboarding or via the settings pages), we're adding unnecessary currencies.
BNPL methods are set only to accept "domestic payments". I.e.: customers can't use BNPL unless they're paying with the same currency as the merchant's account currency.
Since BNPL methods are configured to only accept "domestic" payments, we should only add the "domestic" currency if needed.
This PR fixes the backend logic and the UI when removing currencies from the multi-currency settings.
Before - Klarna shouldn't be disabled if EUR is disabled and the account's default currency is USD:
After - Klarna is no longer displayed in the modal:
The messaging on onboarding is fixed here: #8202
The messaging on the settings page when the payment method requires additional setup will be fixed on a separate PR.
Testing instructions
Test 1
Test 2
giropay
as a PM, and not Klarnanpm run changelog
to add a changelog file, choosepatch
to 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