STM Smart Checkout Pro – Widerrufsfunktion und Conversion-Extras für WooCommerce

Version 0.8.0 — 2026-09-04

• USt-IdNr.-Feld an der Kasse mit Live-Pruefung gegen die VIES-Schnittstelle der EU — auf der klassischen Kasse und auf der Block-Kasse.
• Bestaetigte USt-IdNr. aus einem anderen EU-Mitgliedstaat nimmt die Umsatzsteuer aus der Bestellung (Reverse Charge); der Nettopreis bleibt, die Kundschaft zahlt weniger.
• Die eigene USt-IdNr. des Shops ist eine Einstellung: erst mit ihr liefert die EU eine Anfragekennung — den Beleg der qualifizierten Bestaetigungsanfrage.
• Jede Bestellung merkt sich Nummer, Ergebnis, Anfragekennung und Datum; die Bestellansicht zeigt sie, und bei Befreiung traegt die Bestellung den Reverse-Charge-Satz.
• Bestaetigung, Bestelluebersicht und E-Mail nennen die USt-IdNr. der Kundschaft — bei einer innergemeinschaftlichen Lieferung gehoert sie nach Par. 14a Abs. 3 UStG auf die Rechnung.
• Neue Filter fuer Sonderfaelle: stmcp_b2b_exempt, stmcp_b2b_superseded_by, stmcp_b2b_eu_countries, stmcp_vies_timeout.

• Ausfall-Logik: Eine nicht erreichbare VIES-Schnittstelle gewaehrt NIEMALS eine Befreiung. Die Bestellung geht trotzdem durch — mit Umsatzsteuer und einem Hinweis, warum. Am echten Ausfall des EU-Dienstes gegengeprueft: Antwortet die EU mit einer HTML-Seite statt mit JSON, wird der HTTP-Status festgehalten und einmal wiederholt, statt das Ergebnis als unlesbar abzutun.
• Eine von der EU abgelehnte Nummer wird dagegen hart abgewiesen; sie ist kein Tippfehler, den der Shop schlucken sollte.
• Wo Germanized Pro seine eigene USt-ID-Pruefung eingeschaltet hat, bleibt dieses Modul vollstaendig still — zwei Felder an einer Kasse waeren zwei Befreiungen um denselben Warenkorb.
• Ab Werk ausgeschaltet. Das Modul greift als einziges in die Steuerberechnung ein; ohne ausdrueckliches Ja des Shops passiert nichts.
• Gemessen statt angenommen: Die VIES-Schnittstelle beantwortet auch FEHLER mit HTTP 200 (errorWrappers), deshalb entscheidet hier der Antwortkoerper und nie der Statuscode. Deutschland gibt weder Name noch Anschrift heraus, also haengt keine Entscheidung an einem Namensabgleich.
• Gemessen statt angenommen: WC_Customer::is_vat_exempt steht zwar nicht in den WC_Data-Feldern, wird von WC_Customer_Data_Store_Session aber sehr wohl in der Sitzung gehalten. Ein Modul, das das Flag nur einschaltet, kann die Befreiung nie zurueckziehen — deshalb widerruft es die selbst gewaehrte Befreiung wieder, und nur diese.
• Die Kundennotiz bleibt unberuehrt. Ein frueherer Entwurf haengte den Reverse-Charge-Satz dort an; auf einer echten Testbestellung stand er dann zweimal auf der Bestaetigung und zweimal in der E-Mail — einmal davon so, als haette die Kundschaft ihn geschrieben.

Version 0.7.0 — 2026-09-04

• Kaufkarten an der Kasse: bis zu drei Angebote direkt ueber dem Kaufknopf, je mit Bild, Ueberschrift, eigenem Satz und Preis. Ein Klick legt das Produkt in den Warenkorb, ein Klick nimmt es wieder heraus.
• Ein Produkt, das schon im Warenkorb liegt, wird nie angeboten — gleich wie es hineinkam.

• Die Karte legt einen ECHTEN Warenkorbposten an, keine Gebuehr. Damit stimmen Steuerklasse, Bestand, Versandrelevanz und die Lieferzeit von Germanized, und die Rechnung weist die Ware aus statt einer Gebuehrenzeile ohne Produktdaten.
• Karten mit geloeschtem, ausverkauftem oder unverkaeuflichem Produkt erscheinen gar nicht erst. Ein Angebot, dessen Klick scheitern wuerde, ist schlimmer als keines.
• Die Produkt-ID aus der Anfrage wird gegen die eingestellten Karten geprueft, nicht geglaubt — sonst waere die Schnittstelle ein Weg, beliebige Produkte in fremde Warenkoerbe zu legen.
• Klassische Kasse, wie die uebrigen Pro-Funktionen. Die Block-Kasse braeuchte die Store-API und eine eigene Messung; das ist ein eigener Schritt.
• Der Platz ist ueber stmcp_bumps_hook verschiebbar.

Version 0.6.0 — 2026-09-03

• Bundle-Rabatte: ein Prozentsatz auf den Warenkorb, sobald genug VERSCHIEDENE bezahlte Produkte darin liegen — drei frei einstellbare Regeln mit Prozentsatz, Mindestanzahl, optionaler Kategorienbegrenzung und eigenem Namen in der Bestellsumme.
• Ehrliche Zustandsanzeige auf Warenkorb und Kasse: sie sagt, wie viel noch fehlt, und nach Erreichen, was gespart wurde — und sie verspricht nie einen Rabatt, der nicht eingestellt ist.

• Die Steuerklasse des Rabatts folgt jetzt den Waren: liegen alle beteiligten Positionen in derselben Klasse, wird der Abzug dort gebucht statt pauschal im Regelsatz.

• Der Rabatt ist eine negative WooCommerce-Gebuehr. Das braucht kein Gutscheinformular, wirkt auch bei abgeschalteten Gutscheinen und erreicht PayPal als echten Discount statt als unerklaerte Differenz.
• Greifen mehrere Regeln, bekommt die Kundschaft die beste — sie addieren sich nicht.
• Germanized liest Gebuehrenbetraege je nach Einstellung als brutto statt netto; bei steuerbefreiten Kunden (Reverse Charge) wuerde es den Steueranteil verwerfen und der Rabatt still schrumpfen. Beide Faelle sind abgefangen.
• Die dafuer noetige Korrektur an Germanized greift NUR, wenn mindestens eine Bundle-Regel eingestellt ist. Sie gilt sonst auch fuer Versandkosten, und ein Shop ohne Bundle-Regel darf von einer nicht eingeschalteten Funktion nichts merken.

Version 0.5.4 — 2026-09-03

• The grace period is no longer read as a broken licence. When a term ends, the shop moves the licence 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 licence was not valid for this site or product, received no updates, and could not move the licence to another domain, in exactly the fortnight the shop promises all three.
• The licence 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 licence. The update server's own header had promised since 1.0.0 that an expired licence may still activate; the code did not 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 licence status is translated now, 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 licence gets a "Renew licence" 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 licence 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 licence page when an older server answers — which is exactly the moment a customer wants the link.

Version 0.5.2 — 2026-09-03

• The licence binding now holds for updates as well. Activating a licence 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 somebody 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 licence was activated on.
• A licence used on another site reports it plainly on the licence screen instead of failing quietly: the plugin keeps working, updates arrive on the activated site, and releasing the licence 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 licence 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 at 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 stylised marks in each provider's house colour, 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 "Kauf auf Rechnung" 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 optional 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 under 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 dies 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

• Licence and updates. A licence 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 licence binds to one production site; staging and local hosts (staging., dev., .local and similar) do not consume that binding.
• An unreachable licence server is never read as an invalid licence — the previous verdict stands and is retried shortly, so a network hiccup cannot tell a paying customer their licence 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 stays 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. Pro 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.