Compatibility Center

The Compatibility Center is a list of small, targeted workarounds for problems that are not caused by Dino Discounts but that shoppers meet while using a discount — a coupon box that disappears, an Apply button that reloads the page, a payment sheet that will not close. Each fix was reproduced on a real store, and each was confirmed to still happen with Dino Discounts switched off. Alongside the fixes, advice rows point out store setups that need a change in another plugin’s settings or in Dino’s.

None of these fixes can change what a customer is charged. They only change how the cart or checkout page behaves in the browser (or, in one case, how Dino marks up its own message). A build check stops this code from reaching the discount engine.

Where to find it

Go to WooCommerce → Dino Discounts → Dev Tools. The Compatibility fixes panel sits under the Performance Log.

Each row shows three things:

Column	What it tells you
Fix	The problem, in a shopper’s words. Click it to open the full explanation.
On your store	What Dino found when it checked your store (see Detection).
State	Whether the fix is off, on, or on and confirmed working.

Open a row and you see What goes wrong, Why it happens, What switching this on does, the versions it was measured against, and whose defect it is. The switch — Apply this fix — sits underneath, so you always read the explanation before you reach it.

Switching a fix on and off

Most fixes are off until you switch them on. Two are on by default: the Stripe wallet fix, which turns itself on where your store is measured as affected, and the Stripe express-button fix, which was already running on stores with the Stripe gateway and stays on.
Switching a fix off is always allowed and is pure removal: Dino stops loading the fix and your store behaves exactly as it did before, from the next page load. Nothing is stored that needs undoing.
You can only switch a fix on where it could do something. If Dino has worked out that a fix does not apply to your store, the switch is greyed out.
“Needs your confirmation”. If the plugin a fix works around has moved to a version outside the range the fix was checked against, the row stands down. You can still switch it on, but you are asked to confirm (Apply this fix anyway?) and shown whose defect it is and what switching it off does.
The row records who switched it and when, and which version of the other plugin was installed at the time.
Advice-only rows have no switch. They explain a conflict Dino doesn’t work around, and the third heading reads What you can do instead. Their State reads Advice only.

What the State column means

State	Meaning
Off	Not switched on.
On, checking	Switched on; Dino is waiting for your storefront to report whether it worked.
On, working	Switched on, and your storefront shows the problem is gone.
On, not working	Switched on, but your storefront still shows the problem.
On, nothing to do	Switched on, but the page no longer has the part it works on.
On, not applying	Switched on, but not being loaded — the On your store column says why.

How detection works

Dino never offers a fix just because a particular plugin is installed. Most stores running that plugin do not have the problem, so every entry checks for the problem itself.

Plugin and version. For entries aimed at another plugin, Dino checks that plugin is active and reads its version.
The problem itself, measured one of three ways:
- From your store’s setup, where the problem comes from what is installed and how it is set up rather than from anything a page does. Dino reads that each time you open Dev Tools, so the row is always current and nothing is added to your storefront.
- On the server, where the problem shows there, such as a request your server refuses. Dino records it as it happens, and nothing is added to your storefront. Dino prefers this wherever it is accurate. It only records a request from a shopper with a cart or a signed-in account. Anyone can send a request your server refuses, so a row that reads such a request needs the same agreeing run as a probe, from more than one network. A row that reads what your checkout showed decides on its latest reading.
- With a storefront probe otherwise. A small script runs on the page the problem affects (normally the checkout) and reports back whether the problem is there. A single report decides nothing: Dino needs at least three reports, at least two minutes apart, that all agree before it concludes anything. One report that disagrees is enough to hold the answer back. An entry that switches itself on also needs those reports from more than one network, so one visitor on one connection cannot switch it on. Where an entry is about a particular plugin, the script is only served on a store that has it. Anywhere else the row reads Not applicable to this store without it.

The On your store column then reads one of:

Status	Meaning
Affects this store	The problem was measured on your storefront, or your store’s setup has it.
Affects this store — version not measured	The problem was measured, but you run a version of the other plugin the fix was not tested on, inside the range it is believed to work for.
Stood down	The problem is no longer there, the other plugin has moved outside the tested range, or the other plugin has fixed it. The caption says which.
Not applicable to this store	The plugin is not active, your storefront does not have the part the fix works on, or your store’s setup does not have the problem.
Could not check	Not measured yet. Visit the affected page, then come back. Some problems only show while a shopper is using the checkout, so they stay unmeasured until one does. A store-setup row reads this only if its check failed.
On — not yet measured	A fix that was already running on your store before it had a switch. It applies without waiting for a measurement.

What the storefront reports is advice, never a switch-off. If you have switched a fix on, a “problem gone” or “nothing here to fix” reading never stops it loading — you decide. A switched-on fix does stop loading when the other plugin is no longer active, when the other plugin has fixed the problem itself, or when the other plugin has moved outside the tested range (unless you confirmed it anyway).

Removing an entry from your site

A developer can hide an entry from the panel altogether with the dino_discounts_compat_entries filter. It can remove entries but cannot add one.

add_filter( 'dino_discounts_compat_entries', function ( $ids ) {
    return array_diff( $ids, array( 'eael-layout-wrapper-leak' ) );
} );

See the hook reference.

The fixes

Eighteen entries ship in the current version. The id is what the removal filter and the REST API use.

Eleven are fixes with a switch. All eleven are reversible, and all except the two Stripe fixes are off by default. The other seven are advice only: the Smart Coupons auto-apply entry, the four store-setup entries and the two Price Based on Country entries.

Applying a code reloads the checkout

id: coupon-form-submit-unbound · Default: off · Page: checkout

The conflict. Code on the site — usually a page-builder checkout snippet — clears and rebuilds the order summary in a way that strips WooCommerce’s coupon handler off the coupon form. With no handler, pressing Apply submits the whole page: the checkout reloads and anything the shopper had typed but not saved is lost. This is a defect in the site’s own checkout code, not a particular plugin.
Detection. The probe checks the checkout for a coupon form with no submit handler of its own. A stock store reads clean, and so does a store that has repaired its own script.
The fix. Attaches a replacement coupon handler to the page rather than to the form, so it survives however often the summary is rebuilt. Applying a code then updates the totals in place. If the site’s own handler is restored later, WooCommerce’s handler stops the event before it reaches Dino’s, so a code is never applied twice.
Switching it off. Applying a code goes back to reloading the page.
Note. This fix does not stand itself down when it works, because the form is still missing its own handler. The row keeps showing Affects this store while the fix is doing its job.

A second discount code does nothing

id: coupon-form-stuck-processing · Default: off · Page: checkout

The conflict. WooCommerce marks the coupon box as busy while a code is applied and clears that mark afterwards. Code on the site replaces the coupon box mid-apply, so the mark is cleared on a box that is no longer on the page. The visible box stays marked busy, and WooCommerce silently ignores Apply on a busy box. For about 50 ms to 3 seconds after the first code, a second code does nothing — no message, no change. It then recovers by itself.
Detection. The probe looks for a coupon box still marked busy after an apply has finished, with no coupon request in flight. It can only measure this while a shopper is applying a code, so a new store shows Could not check until one does — visiting the checkout yourself won’t measure it.
The fix. Watches for a code finishing and clears the leftover busy mark from whichever coupon box is actually on the page. If the site’s own repair does the same, whichever runs second finds nothing to do.
Switching it off. A second code entered straight after the first is ignored for a few seconds again.

The Discount Code box disappears from the order summary

id: eael-coupon-box-reseat · Default: off · Page: checkout

The conflict. A site script moves the coupon box into the order summary of an Essential Addons for Elementor (EAEL) Woo Checkout widget. EAEL rebuilds that summary from scratch on every update — a country change, a shipping choice, a code — and the rebuilt summary does not include the box. The box vanishes and only comes back on reload. EAEL’s rebuild fires no event, and the site script runs only once, so nothing puts it back. This reproduces with Dino Discounts deactivated.
Detection. Essential Addons must be active. The probe then looks for a coupon box that was on the checkout and is gone after the summary repaints, with the order summary still rendering. On a stock EAEL checkout the box is never inside the summary, so the rebuild loses nothing and the fix is not offered.
The fix. Takes a copy of the box while the page is intact, watches for the summary being rebuilt, and puts the box back in the same place with whatever the shopper had typed. It does nothing while a coupon box is already on the page, so it never fights a site script that restores the box itself.
Expect this. WooCommerce prints “code applied” / “code not valid” inside the box and then rebuilds the summary, so with the fix on that message appears and disappears again about a second later. Without the fix, the box and the message both vanish for good.
Switching it off. The box goes back to disappearing when the summary updates.
Measured against. EAEL Lite 6.7.0 / Pro 6.7.3 with the site’s “Checkout - JS” Elementor snippet.

The order total drifts further down the page on every update

id: eael-layout-wrapper-leak · Default: off · Page: checkout

The conflict. The same kind of site layout script builds a new wrapper (.checkout-middle-section) around the coupon box every time it runs and never removes the old one. Empty wrappers stack up between the items and the totals, so the subtotal, shipping and total slide further down the page with each update.
Detection. Essential Addons must be active. The probe then looks for a surplus empty wrapper. One wrapper is the layout working as designed. Wrappers that hold something are left alone. A checkout with no wrapper at all reads Not applicable.
The fix. Removes the spare empty wrappers. It never touches a wrapper with anything in it, so the one holding the coupon box is safe, and it always keeps the last one, so your stylesheet’s spacing still applies.
Expect this. The totals sit about 30px higher than before, because the empty block pushing them down is gone. The coupon box itself does not move. If you want the gap back, add it as CSS spacing on the remaining wrapper.
Switching it off. The empty wrappers come back from the site script’s next run.
Related. This leak usually only becomes visible once the coupon box is re-seated, because EAEL’s rebuild otherwise throws the wrappers away along with the box. The two entries are designed to be used together.

The free gift offers a quantity you cannot change

id: ssc-gift-line-quantity-stepper · Default: off · Page: checkout · Plugin: ScratchSleeves Checkout 2.6.6 – 2.x

The conflict. ScratchSleeves Checkout’s order-summary template draws a ”− 1 +” quantity control on every line, including a Dino free gift. The gift is always exactly one and its quantity is fixed on the server, so the control looks usable but every press is refused.
Detection. ScratchSleeves Checkout must be active and inside the version range. The probe then looks for a visible plus/minus button on a free-gift line. A store that turns the plugin’s editable summary off, or marks its gift products “sold individually”, has no stepper and isn’t offered the fix.
The fix. A CSS rule hides the plus and minus buttons on the free-gift row only. The count of 1 stays, the Remove control still works so the gift can be declined, and paid lines keep their full control. The rule is not !important, so your own CSS can still override it. It works whether or not you show the “Free gift” cart label at checkout.
Switching it off. The plus and minus buttons come back on the gift row.
Versions. Measured on 2.6.6 and 2.7.0. A 3.x release stands the entry down for re-measurement.

Basket messages appear beside the order summary

id: ssc-cart-notices-in-summary · Default: off · Page: checkout · Plugin: ScratchSleeves Checkout 2.7.x

The conflict. ScratchSleeves Checkout keeps its own message area inside the order-summary panel and writes basket confirmations there (”… removed from your basket.”). Discount messages appear in the page’s main message area, so the shopper has two places to watch. This is the plugin’s design, not a bug as such, and moving it is a judgement call — which is why it is a switch.
Detection. ScratchSleeves Checkout must be active and inside the version range. The probe checks whether the plugin’s message area and Dino’s message area sit in different places on the checkout. If either area is missing — a child theme that overrides the template, or a page where Dino’s area does not render — there is nothing to bring together and the row reads Not applicable.
The fix. Moves the plugin’s message area so it sits directly under Dino’s messages, and moves it back into place if the page rebuilds it. The plugin still writes and clears its own messages, and screen readers still announce them. Dino adds nothing to that area and changes nothing in it.
Switching it off. The message area goes back beside the order summary on the next page load.
Versions. Measured on 2.7.0 only. Any other minor release (2.6, 2.8 …) stands the entry down.

Changing the country at checkout does not update the prices

id: ssc-country-field-unbound · Default: off · Page: checkout · Plugin: ScratchSleeves Checkout 2.7.x

The conflict. WooCommerce updates the totals when a field carrying its address-field class changes. ScratchSleeves Checkout rewrites the class list on address fields to set their width and drops that class from the country rows. Changing the country then does nothing: no request, no new totals, no new currency or shipping, and no error. The “Ship to a different address” tickbox is wired up separately, so it still works, which makes the country field look randomly broken.
Detection. ScratchSleeves Checkout must be active and inside the version range. The probe then checks whether the country rows are missing the class on the rendered checkout.
The fix. Puts the missing class back on the country rows, so WooCommerce’s own handler takes over again. It binds nothing new and sends no request itself. The prices update because WooCommerce asks for them, as on any other store.
Switching it off. Changing the country goes back to doing nothing.
Versions. Measured on 2.7.0 only. Any other minor release stands the entry down.

Applied-discount messages sit on top of the checkout heading

id: checkout-notice-negative-margin · Default: off · Page: checkout

The conflict. A rule in the site’s own checkout stylesheet moves every WooCommerce success message 140px up the page on screens 768px and wider. It is written against WooCommerce’s message style, not any one plugin’s, so it lifts every “applied” message whoever produced it. One message lands on the page heading; two or more land on each other as well. This reproduces with Dino Discounts deactivated — a plugin that emits one message per discount simply makes it visible.
Detection. The probe reads the rendered margin of a success message on the checkout, on a screen 768px or wider. A store whose own stylesheet already outranks the rule, or that has deleted it, reads a normal margin and isn’t offered the fix. A phone-width visit measures nothing, and a checkout with no message on it reads Not applicable.
The fix. One CSS rule puts the message’s top margin back to zero on screens 768px and wider, and nothing else: the white text the site’s rule sets stays, and nothing applies below 768px. The messages then sit below the heading, one under another. The proper repair is to delete the margin rule from the checkout stylesheet, after which the entry stands down on its own.
Switching it off. The site’s rule applies again and the messages go back onto the heading.
Measured against. The site’s “Checkout - css” snippet, on an Essential Addons Woo Checkout at 1280px with three messages.

A refused Apple Pay order leaves the payment sheet stuck open

id: stripe-express-wallet-not-released · Default: on where measured as affected · Pages: classic and block checkout · Plugin: WooCommerce Stripe Gateway 10.8.2 to 10.9.0

The conflict. When the store refuses an express (Apple Pay / Google Pay) order — a code already used, an item just sold out, an address it cannot ship to — the Stripe gateway shows the error on the page behind the wallet but never tells the wallet the payment failed. The sheet stays open over a dimmed checkout, Cancel does nothing, and the shopper has to reload the page to get out. This is a defect in the gateway’s own code and happens with Dino Discounts deactivated.
Detection. The Stripe gateway must be active at a version from 10.8.2 to 10.9.0. The probe then checks that a wallet button a shopper could actually press is on the checkout, classic or block, because Stripe decides per visitor whether to show one. A store where none ever appears is Not applicable.
The fix. Watches for the store refusing an express order and, only then and only while the wallet is still waiting, sends the wallet the “payment did not go through” signal the gateway missed. The sheet closes and the shopper is back on the checkout, where the reason is already shown. It works the same way on the block checkout, which uses a different gateway script with the same defect. An accepted order is never touched. A payment that fails after the order has been created is out of its reach.
Why it is on by default. A shopper stuck behind the payment sheet abandons the order and does not write in, so you would never hear about it. The entry turns itself on only once an hourly background check has measured your store as affected. You do not need to visit Dev Tools for that, and the row then says On by default since ….
Switching it off. Allowed, as for every fix. A refused express order then leaves the sheet open again.
Versions. Checked against each version from 10.8.2 to 10.9.0, because it sits on the payment path. From 10.9.1 the gateway closes the sheet itself, so the entry stands down there, as it does on any version before 10.8.2.

Apple Pay and Google Pay stop working after the checkout updates

id: stripe-express-element-remount · Default: on · Page: classic checkout · Plugin: WooCommerce Stripe Gateway 10.2.0 and later

The conflict. Each time a classic checkout updates — a free gift removed, the address or shipping option changed — the Stripe gateway builds a new express (Apple Pay / Google Pay / Link) button and puts it in the same spot as the old one without removing the old one. Tapping the wallet then fails with “Could not find a ready Element to create a PaymentMethod from” until the shopper reloads. This is a defect in the gateway’s own code.
Detection. The Stripe gateway must be active, and the checkout page must be a classic one. The probe watches a checkout update while a wallet button is showing and reports whether the gateway put the new button into the old spot.
The fix. Clears the old button out of its spot just before the gateway builds the new one. The wallet button is missing for a moment while the checkout updates. If an update fails part-way, the button stays missing until the next update succeeds, rather than showing and not working.
Why it is on by default. Dino applied this on every store with the Stripe gateway before it had a switch, so it stays on without waiting for a measurement. The row says On by default since …, because this fix was already running on your store.
Switching it off. Allowed, as for every fix. The gateway then builds each new button on top of the old one again.
Versions. Measured on 10.2.0, 10.8.2 and 11.1.1, with no upper version limit. Dino reads the gateway’s own script and stands the entry down when the gateway starts removing its old button itself, or stops creating the spot this fix clears.

A translation plugin rewrites the amount in the spend-more message

id: translation-rewrites-nudge-amount · Default: off · Pages: cart (measured), every place the spend-more message shows · Plugin: TranslatePress 3.3.4 – 3.x

The conflict. TranslatePress translates whole sentences through its machine-translation service. Dino’s “spend a little more to save” message has the amount inside the sentence, so the service re-formats the amount for the language — “14,10 €” beside your other prices showing “€22.95”. The figure is right, but two formats on one page look broken. Other prices are unaffected because they are not inside a sentence.
Detection. TranslatePress must be active and inside the version range. The probe reads the classic cart page on a translated page and checks whether the message’s amount is formatted differently from the store’s own prices beside it. On the source-language page of a store that serves translations it stays silent. Only a store that shows no sign of serving translations reads Not applicable. The block cart is not measured.
The fix. Unlike the others, this changes Dino’s own markup instead of loading a script. Each amount in the message is wrapped as “do not translate” (translate="no" and data-no-translation), so TranslatePress translates the words around it and leaves the figure as your store formats it. It applies everywhere the message renders, mini-cart included.
Expect this. The words either side of the amount are now translated as separate pieces, which TranslatePress sends to its service once more and which can read a little less naturally. A figure you type into the message template yourself is not covered.
Switching it off. The message goes back to one sentence with the amount inside it.

Smart Coupons’ auto-apply setting stops the checkout summary updating

id: smart-coupons-auto-apply-eael · Advice only — no switch · Page: checkout · Plugins: Smart Coupons + Essential Addons for Elementor

The conflict. On a checkout built with the Essential Addons Woo Checkout widget, a shopper applies or removes a coupon and the order summary keeps showing the old total until they reload. Smart Coupons’ Auto apply coupons setting checks every summary update for a security token that only WooCommerce’s own checkout sends. Essential Addons’ summary request does not carry it, so Smart Coupons refuses the request (HTTP 403) and the summary is never redrawn. This reproduces with Dino Discounts deactivated.
Detection. Smart Coupons must be active with Auto apply coupons switched on, and Essential Addons must be active with its Woo Checkout widget in use. Dino then watches, on the server, for Smart Coupons refusing Essential Addons’ summary request. No script is added to the checkout. That request is only sent when a shopper applies or removes a coupon, so the row reads Could not check until one does. No version range is claimed, so a Smart Coupons update never stands the row down on its own. The panel says which versions it was found on.
What you can do. Switch off Auto apply coupons at WooCommerce → Settings → Smart Coupons → General. Coupons set to apply automatically then stop doing so, and Smart Coupons stops checking guest usage limits, so weigh that before changing it. Dino never changes another plugin’s settings.
The admin notice. Dino also shows an admin notice for this conflict. The notice links straight to this row, and the row stays readable after the notice is dismissed.

Store-setup advice

These four rows come from what is installed on your store and how it is set up. Each is read when you open Dev Tools, so none adds anything to your storefront. No version range is claimed for any of them.

Another discount plugin can stack its discounts on top of dino’s

id: discount-plugin-stacking · Advice only — no switch · Pages: cart, checkout

The conflict. Another discount or pricing plugin is active and Dino keeps applying beside it, so a shopper can get both plugins’ discounts on one product.
Detection. One of the plugins Dino knows as a discount engine is active (developers can extend the list with dino_discounts_incompatible_plugins), and Settings → Other discount plugins is not set to Yield. In Yield mode Dino steps aside while the other plugin is active, so nothing stacks and the row reads Not applicable to this store.
What you can do. Run one discount engine, or keep each on products the other does not discount, or switch Other discount plugins to Yield. See Coexistence with other discount plugins.
The admin notice. The plugin-conflict notice names the plugin and links to this row.

A page cache must not serve the cart and checkout

id: page-cache-on-cart-checkout · Advice only — no switch · Pages: cart, checkout

The conflict. A page cache serves a saved copy of a page. The cart and checkout differ for every shopper, so a cached copy can show the wrong discounts or totals.
Detection. A page-cache plugin Dino knows of is active (extendable with dino_discounts_caching_plugins), and its own settings do not show that it keeps the cart and checkout out. Dino reads the settings of WP Super Cache, W3 Total Cache, WP Rocket, LiteSpeed Cache, SiteGround Optimizer, Breeze and Hummingbird. The row reads Not applicable to this store when the page cache is off, when the plugin’s never-cache list covers both pages, or when the plugin honours the “do not cache” marker WooCommerce puts on them, which all seven do unless code on the site overrides it. Where Dino cannot tell, such as a plugin it does not read, SiteGround’s server cache, or Hummingbird’s FastCGI cache, the row still warns.
What you can do. Make sure /cart/ and /checkout/ are on your caching plugin’s list of pages it never caches. See Caching.
The admin notice. The caching notice names the plugin and links to this row.

Rule previews show prices in your base currency

id: multi-currency-preview-prices · Advice only — no switch · Page: admin only

The conflict. A multi-currency plugin is active whose per-currency prices Dino does not read yet, so rule-editor previews show prices in your store’s base currency. Shoppers are not affected.
Detection. WPML/WCML, Aelia Currency Switcher or WOOCS is loaded (developers can extend the list with dino_discounts_multi_currency_plugins), or, without Price Based on Country, a plugin hooked on WooCommerce’s currency-switched action. See Multi-currency compatibility.
What you can do. Nothing needs changing. Read preview prices as base-currency prices.
No admin notice. Nothing a shopper sees is affected, so this lives only here.

Your prices and your country rules may use different addresses

id: country-source-pricing-basis · Advice only — no switch · Pages: cart, checkout

The conflict. Your multi-currency plugin prices from one of the shopper’s addresses and Dino’s Country matching uses setting matches rules on another. A shopper who ships to a different country than they bill is priced for one country and matched for discounts against the other.
Detection. Dino compares its own setting with the pricing address of Price Based on Country, of WPML/WCML when it prices by location, of Aelia Currency Switcher’s “force currency by country” setting, or of a plugin that reports it through dino_discounts_pricing_country_basis. Where Dino cannot read the other plugin’s address, the row asks you to check.
What you can do. Make both settings name the same address. The admin notice offers a one-click change to Dino’s setting when Dino can read the other plugin’s.
The admin notice. The notice names Dino’s setting, and the other plugin’s where Dino knows it, and links to this row.

Price Based on Country advice

Two rows for stores that price with Price Based on Country. Neither has a switch, and neither changes Price Based on Country or WooCommerce.

Check that changing country at checkout still changes the currency

id: wcpbc-caching-support-inert-country · Advice only — no switch · Page: checkout · Plugin: Price Based on Country

The question. On one store with Price Based on Country’s Load product prices in the background setting on, changing the country at checkout left prices in the old currency, even after a reload. The currency selector still worked. We have not confirmed that this setting is the cause, so the row asks you to check rather than reporting a defect.
Detection. Price Based on Country is active and Load product prices in the background is on. Read when you open Dev Tools.
What you can do. Change the country on your checkout to one you price in another currency and check the prices change. If they do not and your shop is not behind a page cache, try switching the setting off at WooCommerce → Settings → Pricing zones → Options.

A currency change made on the checkout can be undone by the checkout’s own update

id: wcpbc-checkout-currency-switch-race · Advice only — no switch · Page: checkout · Plugin: Price Based on Country

The conflict. As the classic checkout loads, WooCommerce sends an update that saves the shopper’s address. Price Based on Country keeps the shopper’s pricing country in the same place. A shopper who changes currency with the selector in the first moment on the checkout reloads the page, but the update is still running on the server, and if it finishes last the old currency comes back. Reloading does not recover it. This happens with Dino Discounts deactivated.
Detection. Dino records, on the server, whether a Price Based on Country country selector or currency switcher rendered on a classic checkout a shopper loaded with something in their cart. No script is added to the checkout. The row reads Could not check until someone loads the checkout. A block checkout does not send that update, so it reads Not applicable to this store.
What you can do. The simplest remedy is not to show the currency selector on the checkout. The currency a shopper picks applies across the shop, so they can still change it on every other page, including the cart.

Mini-cart and checkout summary support — which cart drawers and order summaries Dino annotates out of the box.
Performance Monitoring — the other half of the Dev Tools tab.