DocumentationGetting startedCompatibility
Compatibility
The fee is an ordinary WooCommerce fee line, so anything that reads a WooCommerce cart reads it too. This page names the tested versions, and the six plugins that needed code of their own.
Requirements
| Minimum | Tested up to | |
|---|---|---|
| PHP | 8.0 | current |
| WordPress | 6.2 | 7.1 |
| WooCommerce | 7.7.0 | 11.1.2 |
The minimums are floors, not targets — the plugin is developed against current WordPress and WooCommerce and tested down to the versions above.
Below the PHP or WooCommerce floor the plugin loads nothing and shows an admin
notice saying what to update. It stays activated and charges no fees, rather
than failing halfway through a checkout. The WordPress floor is enforced by
WordPress itself, from the plugin’s Requires at least header.
The “tested up to” column is read from the plugin’s own readme at build time, so it is whatever the current release declares.
Checkouts
| Checkout | Works | Notes |
|---|---|---|
| Classic (shortcode) | Yes | The original path, and the one most stores are still on. |
| Block checkout | Yes | The total updates live when the shopper changes payment method. |
| Express and wallet buttons | Partly | Apple Pay and Google Pay carry the fee through the official WooCommerce Stripe gateway: Pro recognises Stripe’s express sheet and prices the fee into it before the shopper authorises. Wallet buttons from other gateways are not corrected. Klarna’s one-step flow cannot carry a fee at all. |
Two caveats live on the limitations page rather than here, because they are things that do not work rather than things that do: the Checkout block has to sit in the page’s own content for the live total update to fire, and a wallet sheet opened from an order-pay page can show a total that has not had the fee added yet.
Order storage
The plugin declares compatibility with both, so WooCommerce will not warn about it either way:
- HPOS — high-performance order storage, WooCommerce’s own order tables.
- Legacy post storage — orders as posts, the way WooCommerce stored them before HPOS.
Fee lines are read and written through WooCommerce’s order API rather than by touching the tables, which is why switching storage does not affect anything this plugin wrote.
Payment gateways
Any gateway that WooCommerce lists can carry a fee. The plugin does not integrate with gateways one by one — it adds a fee to the cart or the order, and gateways read the total the same way they read any other. That includes the React-based settings screens that leave no room for extra fields of their own: WooCommerce Payments, Stripe, Klarna and the rest are configured from the one Pay for Payment screen instead.
Two exceptions, both on the limitations page: PayPal, whose user agreement prohibits surcharging, and Mercadopago, which drops fee lines through a bug in its own integration.
One gateway-specific rule worth knowing: cash on delivery respects its own “enable for shipping methods” setting. If COD is restricted to certain shipping methods in WooCommerce and the shopper has chosen another one, COD is not on offer and no COD fee is charged — the plugin reads that restriction from the gateway rather than asking you to repeat it.
Multi-currency
A fee is configured as a number, so on a multi-currency store something has to convert it. Five plugins are handled with code written for them, each detected automatically — nothing to switch on:
| Plugin | Minimum version | Notes |
|---|---|---|
| WooCommerce Price Based on Country (opens in a new tab) | 1.8 | Converts using the active pricing zone. |
| Converts using the active pricing zone. | ||
| WooCommerce Multilingual & Multicurrency (WCML) (opens in a new tab) | any | |
| CURCY – Multi Currency for WooCommerce (opens in a new tab) | 2.1.5 (free) / 2.1.9 (premium) | |
| FOX – Currency Switcher for WooCommerce (WOOCS) (opens in a new tab) | any | |
| WooCommerce Multi-currency (TIV.NET) (opens in a new tab) | 2.5.0 | See the note below on base currency. |
| See the note below on base currency. | ||
On a store running none of these, the fee is charged in the store’s own currency, which is the correct answer when there is only one.
Orders you create in the admin
Conversion follows the storefront. Every one of the five plugins above works out its rate from what a shopper is looking at, and that is where fees are charged, so on the checkout page this is simply correct.
An order you create by hand under WooCommerce → Orders has no shopper and no storefront. Some of these plugins therefore decline to convert anything at all there — CURCY returns the amount untouched inside wp-admin, by design, because it treats the admin as base-currency territory. Left alone that would put the shop’s own number onto an order in another currency: a fee set to 100 Kč charged as 100 €.
So no fee is added, and the order gets a note explaining why, which leaves you free to add one by hand at whatever rate you consider right. A missing fee you can see beats a plausible wrong one you cannot. This applies only to orders created in the admin, in a currency other than the shop’s, with Charge the fee on manual & order-pay orders switched on. Checkout and the order-pay page both run on the front end and convert normally.
Could this be automatic? Only partly, which is why it is not. It would mean converting against the order’s own currency instead of the storefront’s, and that question has no answer for every plugin here: WooCommerce Price Based on Country converts by pricing zone, and several zones may share one currency at different rates, so “convert this to euros” is genuinely ambiguous. I would rather leave a gap you can see than pick a number and put it on someone’s invoice.
One caveat I cannot currently stand behind
Support for WooCommerce Multi-currency has been described since 2020 as working when the store currency is USD. That sentence comes from the 2.0.15 release note and has been repeated ever since, but it has never been enforced anywhere in this plugin’s code — the integration hands the amount to WooCommerce Multi-currency’s own price controller and takes back whatever it returns. It describes that plugin’s behaviour at the time, not this one’s, and it has not been retested since.
So: if your base currency is USD, this is the configuration the integration was built against. If it is not, it may well work and I cannot promise it does. Running one and willing to tell me what happens? I would genuinely like to know.
Translation
WPML — fee titles are registered with WPML String Translation whenever payment method settings are saved, so the label a customer sees on the checkout page can be translated per language.
Everything else is translated the ordinary WordPress way. The text domain
is woocommerce-pay-for-payment and has not changed since version 2, so an
existing translation keeps working.
The admin ships in eight languages besides English, every string translated: Czech, German, Spanish, Italian, Dutch, Belgian Dutch, Slovak and Turkish. Czech is my own; the other seven follow the version 2 catalogues and have not been reviewed by a native speaker — if you are one and something reads oddly, the wp.org translation project is where a fix goes.
Not tested
WooCommerce Subscriptions. I do not own it, and I am not going to buy a licence to guess in public. A fee is added to the order the customer checks out with, the ordinary way; what happens on a renewal — which is generated rather than checked out, so cart fees never run for it — is something I have not verified and will not claim either way.
If you run Subscriptions alongside this plugin, tell me what you see and this section becomes a real answer. Same for anything else you are wondering about: the list above is what has been tested, not a boundary of what works.
Anything else
The rule of thumb: a fee added by this plugin is a standard WooCommerce fee line, tagged with the gateway it came from. Anything that reads WooCommerce fees — an invoicing plugin, an accounting export, a shipping label service — reads this one without knowing the plugin exists. Where that is not enough, Pro can write the fee as a product line instead, which is what invoicing plugins that ignore fee lines need.
If you are weighing a specific combination and would rather not find out the hard way, ask me — and the free version (opens in a new tab) costs nothing to try on a staging copy.
Running something not on this page and wondering? Ask — I would rather answer than have you find out on a live store.
Get in touch