STM Smart Checkout Pro – Cancellation function and conversion extras for WooCommerce

Version 0.8.0 — 2026-09-04

• VAT ID number field at the cash register with live verification against the EU's VIES interface — on the classic cash register and on the block cash register.
• A verified VAT ID number from another EU member state removes the VAT from the order (reverse charge); the net price remains, and the customer pays less.
• The shop's own VAT ID number is a setting: only with it does the EU provide a request identifier — the proof of the qualified confirmation request.
• Each order remembers the number, result, request ID and date; the order view displays them, and upon release, the order carries the reverse charge rate.
• Confirmation, order summary and email state the customer's VAT ID number — in the case of an intra-Community supply, it must be included on the invoice according to Section 14a Paragraph 3 of the German VAT Act.
• New filters for special cases: stmcp_b2b_exempt, stmcp_b2b_superseded_by, stmcp_b2b_eu_countries, stmcp_vies_timeout.

• Failure logic: An unreachable VIES interface NEVER grants an exemption. The order still goes through—with VAT and an explanation. Verified against a real EU service outage: If the EU responds with an HTML page instead of JSON, the HTTP status is recorded and retried, instead of dismissing the result as unreadable.
• A number rejected by the EU, on the other hand, will be firmly rejected; it is not a typo that the shop should accept.
• Where Germanized Pro has its own VAT ID check enabled, this module remains completely silent — two fields at a checkout would result in two exemptions for the same shopping cart.
• Disabled by default. This module is the only one that interferes with the tax calculation; nothing happens without the shop's explicit consent.
• Measured instead of assumed: The VIES interface also responds to ERRORS with HTTP 200 (errorWrappersTherefore, the response body is the deciding factor here, never the status code. Germany does not release names or addresses, so no decision depends on a name comparison.
• Measured instead of assumed: WC_Customer::is_vat_exempt Although it's not in the WC_Data fields, it is... WC_Customer_Data_Store_Session but it is indeed held in the session. A module that merely enables the flag can never revoke the exemption—therefore, it revokes the exemption it has granted itself, and only that exemption.
• The customer note remains unchanged. An earlier draft included the reverse charge clause there; in a real test order, it appeared twice on the confirmation and twice in the email—once as if the customer had written it.

Version 0.7.0 — 2026-09-04

• Purchase cards at the checkout: up to three offers directly above the purchase button, each with a picture, title, custom text, and price. One click adds the product to the shopping cart, another click removes it.
• A product that is already in the shopping cart will never be offered — no matter how it got there.

• The card creates a genuine shopping cart item, not a fee. This ensures that the tax class, stock level, shipping relevance, and delivery time from Germanized are correct, and the invoice lists the goods instead of a fee line without product data.
• Maps with deleted, sold-out, or unsaleable products don't appear at all. An offer that would fail to click is worse than no offer at all.
• The product ID from the request is checked against the stored cards, but not accepted — otherwise the interface would be a way to place arbitrary products into other people's shopping carts.
• Classic POS, like the other Pro features. Block POS would require the Store API and its own measurement system; that's a separate step.
• The space is over stmcp_bumps_hook movable.

Version 0.6.0 — 2026-09-03

• Bundle discounts: a percentage off the shopping cart once enough DIFFERENT paid products are in it — three freely configurable rules with percentage, minimum quantity, optional category limit and custom name in the order total.
• Honest status display on the shopping cart and checkout: it shows how much is still needed, and once reached, what has been saved — and it never promises a discount that is not set.

• The tax class of the discount now follows the goods: if all items involved are in the same class, the deduction is booked there instead of as a lump sum in the standard rate.

• The discount is a negative WooCommerce fee. This doesn't require a coupon form, works even with coupons disabled, and reaches PayPal as a genuine discount instead of an unexplained difference.
• If multiple rules apply, the customer gets the best one — they do not add up.
• Germanized reads fee amounts as gross instead of net, depending on the settings; for tax-exempt customers (reverse charge), it would discard the tax portion and the discount would silently decrease. Both cases are handled.
• The necessary correction to Germanized only takes effect if at least one bundle rule is configured. Otherwise, it also applies to shipping costs, and a shop without a bundle rule should not be aware of a deactivated function.

Version 0.5.4 — 2026-09-03

• The grace period is no longer read as a broken license. When a term ends, the shop moves the license to a grace period: fourteen days in which the product keeps running, updates keep arriving and the customer is told so by mail. This plugin's update server knew nothing of that state — it required "active" and answered "invalid" for everything else. A customer inside the grace period was therefore told the license was not valid for this site or product, received no updates, and could not move the license to another domain, in exactly the fortnight the shop promises all three.
• The license screen names the state and the date it ends, and carries the renewal link — same place, same language as the other states.
• Activation now refuses only a revoked license. The update server's own header had promised since 1.0.0 that an expired license may still activate; the code didn't do it.
• Decided on the date rather than on the stored status, because that status is set by a daily cron and lags by up to a day. The answer is right in the hours between the term ending and the cron running.

Version 0.5.3 — 2026-09-03

• The sentence under the license status is now translated, and it carries a link. It came from the update server, which writes it once for every shop in a language it cannot know — so a German shop read a German status line with an English sentence beneath it. The follow-up is written in the plugin now, where it can be translated, and an expired license gets a "Renew license" link straight to the customer account. The server's own text remains as the fallback for a verdict this version does not know yet.
• A license activated elsewhere explains the way out in the same place: release it on the other site, then activate it here.

• The update server sends the renewal address with every answer that carries package information (licence API 1.2.0), so it can move without a plugin release. The plugin falls back to the shop's license page when an older server answers — which is exactly the moment a customer wants the link.

Version 0.5.2 — 2026-09-03

• The license binding now holds for updates as well. Activating a license binds it to one site — but the update request never mentioned the site, so the server had nothing to compare and the binding relied entirely on a cooperating client. A key passed on to someone else downloaded from anywhere. The plugin sends its host with every update request now, and the server (licence API 1.1.0) holds back the download when that host is not the one the license was activated on.
• A license used on another site reports it plainly on the license screen instead of failing quietly: the plugin keeps working, updates arrive on the activated site, and releasing the license there is one click.
• Three cases still receive their update, each for its own reason: a request without a host, because every copy in the field before this version sends none and taking updates from paying customers for our own omission would be the wrong fix; a license that has not been activated yet, because there is nothing to compare; and a staging host, which does not bind in the first place.

Version 0.5.1 — 2026-09-03

• The express zone says what is missing. A shop switched the zone on, saw nothing and had no way of knowing why — the answer was in a browser console, which is the wrong place for a setting. The provider table on the Checkout tab now names the provider's own settings that are demonstrably not in place.
• For PayPal Payments it reports three things, each read from PayPal's own options: that on the classic checkout PayPal paints its button only after a customer picks PayPal as the payment method, so only a wallet can fill the band before that; that "Checkout" is missing from PayPal's own button locations, where that is the case; and that Apple Pay is switched on while the domain association file does not exist, which is the one reason Apple Pay silently never appears.
• Every check stays silent when the option it reads is absent or shaped differently than expected. A provider that renames its settings must never produce a warning about a shop that is fine, and "Apple Pay needs Safari" stays advice in the paragraph rather than a warning in the table.

Version 0.5.0 — 2026-08-31

• Express zone. One defined band above the checkout form for wallet and one-step buttons, instead of a PayPal button sitting under the payment methods and a WooPayments button somewhere else.
• The buttons are STEERED, never rebuilt. An express button carries a payment session and is rendered by the provider inside its own cross-origin iframe; a plugin that draws its own breaks at the till on the day the provider changes something.
• Providers that publish a placement filter are handed the zone's hook and render inside it from the start — no move, no re-render, no reload. Verified in the installed copy of WooCommerce PayPal Payments, where one filter (woocommerce_paypal_payments_checkout_button_renderer_hook, default woocommerce_review_order_after_payment) moves PayPal, Apple Pay and Google Pay together.
• PayPal's card fields are deliberately left alone. That hook renders the card FORM, not an express button, and it belongs to the payment methods where the customer chose it.
• Everyone else keeps their place and is grouped into the same band by the layout. WooPayments, Klarna and the second PayPal plugin publish no placement filter — checked in their installed sources, not assumed from documentation.
• Nothing is ever moved in the DOM. Re-parenting a rendered container reloads the provider's iframe and throws away whatever wallet session it had negotiated; CSS order produces the same picture and touches nothing.
• The heading and the "OR" divider appear only after the script has measured real height in the zone. Gateways print their container whether or not they show a button in it, so presence proves nothing.
• A row on the Checkout tab lists every express-capable gateway that is active and says for each whether it is steered or grouped — and says plainly that a button inside a provider's iframe cannot be verified from here.
• Off by default: switching it on relocates live payment buttons on a running shop, which is the shop's decision to make.
• A slot child counts as filled only when the iframe it renders into has height. On a live shop PPCP's wrapper stood 55px tall around a PayPal iframe measuring 0x0 — the same 0x0 with the zone switched off, so the button was not painting there at all. Height on the wrapper alone would have put the heading over a blank strip.
• The band is placed by a descendant rule, not a child rule. Not every theme leaves the hook's output as a direct child of the checkout form — Basel wraps it in a column div, and a child selector missed it there while matching on a default theme. Measured on both.

• The concept named three placement filters. Only PayPal's exists in the installed sources; WooPayments offers a locale filter but no location filter, and no Stripe gateway was present to check against. The registry is filterable (stmcp_express_renderer_hooks, stmcp_express_providers) so an agency can add a gateway we have never seen — but nothing goes in on the strength of a documentation page.

Version 0.4.0 — 2026-08-31

• Method customizer. WooCommerce shows what each gateway calls itself, and that is rarely what a customer needs to read: "Direkte Banküberweisung" says nothing about when the goods ship, and the order of the list is whatever the gateways happened to be installed in. Own name, a note under the name, a symbol and a sort position — one row per enabled method on the Checkout tab.
• All four go through documented WooCommerce filters (woocommerce_gateway_title, _description, _icon, woocommerce_available_payment_gateways). Nothing is re-rendered and no gateway markup is replaced, so a provider that updates its own template keeps working.
• The note is ADDED to the provider's text, never instead of it. A gateway description often carries a legal or technical line the provider requires, and swallowing that would be the shop's problem, not ours.
• Sorting is stable: methods the shop has not placed keep their relative position around the ones it has, so switching a gateway on does not silently reshuffle the rest.
• 33 symbols ship with the plugin — the plugin's own stylized marks in each provider's house color, taken from the Magento module of the same family. They are not the providers' logo files, and assets/icons/CREDITS.txt says so: a shop wanting a real provider logo uploads it to its own media library instead.
• The symbol is the one choice that cannot be judged without seeing it, so the settings screen previews it live on selection.

Version 0.3.0 — 2026-08-31

• Payment-dependent required fields. A shop offering "purchase on account" needs a telephone number and often a company; the same shop asking for both on prepayment loses customers for nothing. WooCommerce knows one answer per field — required, or not. A matrix on the Checkout tab makes the answer depend on the chosen payment method: fields down the side, enabled gateways across the top.
• Only fields WooCommerce leaves optionally appear in the matrix. Making a field it already requires "required for bank transfer" would be a no-op dressed as a setting, and a table over every checkout field would be unreadable. Shops whose legal or B2B plugin brings its own field — a VAT ID, a customer number — add it through the stmcp_payment_required_candidates filter.
• The server has the last word, on woocommerce_after_checkout_validation. The browser marks the fields the current choice demands so nobody has to submit the form to find out, but that half is a courtesy and the rule is checked again after submit either way.
• A field the shop already requires is never touched by the browser half and never reported twice by the server half: WooCommerce puts the field id in its own error data, and an error already carrying that id is left alone. Two messages for one empty box read as a bug.
• The settings are plain booleans below payfields.. in Lite's own option. Lite's sanitizer rebuilds that option from its field registry on every save and drops what it does not know, so a new setting type from Pro would not survive — registered bool keys do. That is why this is a matrix of checkboxes rather than a multi-select.
• The list of enabled gateways is refreshed while the settings screen is open and cached in an option. Booting the gateway registry on every front-end request to build a settings schema would be a heavy price for a list that changes twice a year.

Version 0.2.0 — 2026-08-31

• Safe mode. A fatal error while the checkout renders no longer costs a shop its orders: the incident is recorded, and from the next request on the Smart Checkout stands down through Lite's own stmc_active filter while WooCommerce's standard checkout takes over. The shop keeps selling until someone has looked at it.
• It engages for any fatal that happens while our checkout renders, not only for fatals inside our own files — a layout hook of ours calling a theme function that no longer exists this in the theme's file, and that is exactly the dangerous case. The recorded file name says where the fault actually was, so the report neither blames us for someone else's error nor excuses us for our own.
• The state is visible and leavable, the rule preview mode learned the hard way: an error notice on every admin screen, a row on the General tab, and one button that switches the checkout back on. Nothing clears itself silently.
• The recorded path is shortened to the WordPress root and the message to its first line — this text is meant to be readable, pasted into a support mail and screenshotted, and none of that should carry the server's directory layout or a full stack trace.
• The filter runs at priority 100, after the site adapter and any shop-specific override. A safety net that something else can overrule is not a safety net.

Version 0.1.1 — 2026-08-30

• License and updates. A license key screen under WooCommerce, activation and release of the site against the STM update server, and updates delivered straight into the WordPress plugins screen.
• A license binds to one production site; staging and local hosts (staging., dev., .local and similar) do not consume that binding.
• An unreachable license server is never read as an invalid license — the previous verdict stands and is retried shortly, so a network hiccup cannot tell a paying customer their license is broken.
• After the term ends the plugin keeps working and only updates stop. The plugins screen still shows that a newer version exists, and says why it is out of reach.

• The withdrawal page could keep an English title on German shops. The self-heal for title and slug ran inside the upgrade routine, which only fires while the stored version differs from the running one — and that routine records the version in the same pass, so a page created before the translations were loaded was never looked at again.
• Healing now runs on its own signature of plugin version plus locale, which also covers a shop that changes its language later. A title the shop owner edited is still never overridden.

Version 0.1.0 — 2026-08-30

• Online withdrawal complex (EU directive 2023/2673, mandatory withdrawal function since 19 June 2026): a public form on an automatically created page, reachable for guests and customers, with automatic menu placement.
• The form pre-fills for logged-in customers — billing details plus their most recent order (number, date, address), everything editable.
• The address is entered as separate fields exactly like the checkout, not as one free-text blob.
• Soft order matching that never blocks a submission: a withdrawal is accepted even when the order cannot be identified, because a form that turns the consumer away does not serve its purpose.
• Merchant notification and customer receipt emails.
• Withdrawals management screen under WooCommerce with a status workflow, its own database table, and a counter badge for new requests.
• "Withdraw this order" in My Account, with a configurable period after which the button disappears while the public form remains reachable.
• Mobile sticky order bar: on phones a slim bar with the order total and a buy button stays pinned while the real button is out of view. The proxy click runs every native validation rather than submitting directly.
• Ultra-compact layout: the three-column stage one type step down with tighter cards and fields. On touch screens density yields to reachability — 16px field text and full-height targets.

• Requires STM Smart Checkout (the free plugin) to be installed and active. Per registers on priority 30 with a class_exists guard, because WordPress sorts active_plugins alphabetically and -pro sorts before /.
• The effective layout is resolved from the raw stored option, so a checkout set to ultra-compact degrades to its nearest relative if Pro is momentarily inactive, instead of silently falling back to the default.
• Translation catalogue is split, not copied: Pro ships only its own strings, in German (formal and informal), plus a .pot for translators.