Chunghwa Post \u4e2d\u83ef\u90f5\u653f<\/strong> (postserv.post.gov.tw) \u2014 Privacy: https:\/\/www.post.gov.tw\/post\/internet\/Group\/index.jsp?ID=156739569921<\/li>\n<\/ul>\n\nMoksa AI assistant (optional, admin-only)<\/h4>\n\n
When an administrator actively uses the in-admin Moksa AI assistant, the typed question and the store\/order data needed to answer it (for example an order number, status, totals or invoice\/shipping numbers) are sent to the AI provider you have connected in WordPress under Settings \u2192 Connectors<\/strong> \u2014 Anthropic, Google or OpenAI \u2014 through the WordPress 7.0 AI Client. This never happens automatically and only for the administrator using the assistant. The plugin does not store these conversations on any Moksa server, sends nothing to Moksa, and never transmits your AI provider keys (WordPress manages the connector credentials). The transmitted data is governed by the terms and privacy policy of the provider you choose: Anthropic \u2014 Terms: https:\/\/www.anthropic.com\/legal\/commercial-terms \u2014 Privacy: https:\/\/www.anthropic.com\/legal\/privacy ; Google \u2014 Terms: https:\/\/ai.google.dev\/gemini-api\/terms \u2014 Privacy: https:\/\/policies.google.com\/privacy ; OpenAI \u2014 Terms: https:\/\/openai.com\/policies\/terms-of-use\/ \u2014 Privacy: https:\/\/openai.com\/policies\/privacy-policy\/<\/p>\n\nMCP server (optional, off by default)<\/h4>\n\n
This plugin can optionally expose a standards-compliant, stateless MCP (Model Context Protocol) endpoint on your own site<\/strong> at \/wp-json\/moksa-for-woocommerce\/v1\/mcp<\/code>, so a standard MCP client you control (for example mcp-remote or Claude) can look up orders and reports through the WordPress REST API. This is not a Moksa service and is not a phone-home<\/strong>: nothing is sent to Moksa, the endpoint only runs on your server and only exposes the plugin's own WordPress Abilities. It is off by default<\/strong> and must be turned on under WooCommerce \u2192 Moksa AI \u2192 Settings. Access requires authentication with a WordPress Application Password for a user that has the \"edit orders\" capability (use a dedicated, limited account). By default only read-only tools are exposed; order-changing tools stay hidden unless you also enable the separate \"allow external AI to make changes\" option, and every request is permission-checked on your server.<\/p>\n\n\nMinimum Requirements<\/h4>\n\n\n- PHP 8.2+<\/li>\n
- WordPress 7.0+<\/li>\n
- WooCommerce 9.9+<\/li>\n<\/ul>\n\n
Setup<\/h4>\n\n\n- Install and activate the plugin.<\/li>\n
- Go to WooCommerce \u2192 Settings \u2192 Moksa for WooCommerce<\/strong> to enable the modules you need.<\/li>\n
- Configure the credentials for each enabled provider on its dedicated tab.<\/li>\n<\/ol>\n\n\n
\nDoes it work with the Block-based Checkout?<\/h3><\/dt>\nYes. Every payment method ships an AbstractPaymentMethodType<\/code> + React component, and the convenience-store picker \/ invoice fields render inside the Checkout block.<\/p><\/dd>\nIs it HPOS-compatible?<\/h3><\/dt>\nYes. All order meta uses $order->update_meta_data()<\/code> \/ $order->save()<\/code>, never update_post_meta()<\/code>.<\/p><\/dd>\nCan I mix providers?<\/h3><\/dt>\nYes. Payment, shipping and invoice modules are fully independent \u2014 any combination works.<\/p><\/dd>\n
What is the Moksa AI assistant and what does it need?<\/h3><\/dt>\nIt is an optional in-admin chat assistant for managing orders, e-invoices, shipping labels and module settings in natural language. It requires WordPress 7.0 (for the built-in AI Client) and an AI provider connected under Settings \u2192 Connectors<\/strong>; enable it under the plugin's Advanced settings. Every action that changes data first asks for your confirmation, and the assistant can never read or change your provider credentials, switch sandbox\/live mode, or issue refunds.<\/p><\/dd>\nCan external AI tools connect to my store over MCP?<\/h3><\/dt>\nYes, optional and off by default. Turn it on under WooCommerce \u2192 Moksa AI \u2192 Settings \u2192 \"Enable external MCP server\"<\/strong>. The plugin then serves a standards-compliant, stateless MCP (Model Context Protocol) endpoint at \/wp-json\/moksa-for-woocommerce\/v1\/mcp<\/code> that any standard MCP client (for example mcp-remote or Claude) can connect to directly \u2014 no bridge required.<\/p>\n\nAuthentication uses a WordPress Application Password for a user that has the \"edit orders\" capability; use a dedicated, limited account rather than an administrator. Connect your client to the endpoint with an Authorization: Basic <base64 of username:application-password><\/code> header. By default only read-only tools (look up orders, reports, settings overview) are exposed; order-changing tools stay hidden unless you also enable the \"allow external AI to make changes\" option, and destructive actions still require in-store confirmation. Every request is permission-checked on the server.<\/p><\/dd>\n\n<\/dl>\n\n\n1.5.0 - 2026-08-01<\/h4>\n\n\n- i18n: every translatable string is now written in English in the source, and Traditional Chinese ships as a real translation. Previously the source strings were Chinese, which meant the plugin could never be translated into any other language and WordPress.org reported it as having no Traditional Chinese localisation at all. 2,442 strings are covered, so Chinese stores see exactly the same wording as before.<\/li>\n
- i18n: Taiwanese cities and districts now use a translator context (
_x<\/code>), so the districts that share a name across cities \u2014 Zhongzheng in both Taipei and Keelung, for example \u2014 are no longer collapsed into one entry that translators cannot tell apart.<\/li>\n- Fix: invoice line-item units sent to the e-invoice services were wrapped in a translation call, so on a non-Chinese site they would have been submitted in the site language instead of the value the tax authority expects. They are now sent as fixed data.<\/li>\n
- Fix: the order-status labels shown as post-status counts in the admin order list are now translatable in their own right rather than reusing an unrelated shipment-tracking string.<\/li>\n
- Dev: the translation catalogue is generated from a single English-to-Chinese map and the build fails if any string is missing a translation, so a new string can no longer ship untranslated.<\/li>\n<\/ul>\n\n
1.4.9 - 2026-07-26<\/h4>\n\n\n- Security: two SmilePay logistics endpoints (T-cat tracking-number retrieval and C2B label data) were still declared with plain http:\/\/; both now use https:\/\/ (verified reachable), so every request the plugin makes is TLS-encrypted as the readme states.<\/li>\n
- Security: the module on\/off save handler and the order-status colour save handler verified neither a nonce nor a capability inside the method, relying on the WooCommerce settings page upstream. Both now verify the WooCommerce settings nonce and the manage_woocommerce capability inline, in the same form WooCommerce core uses.<\/li>\n
- Security: the quick-edit and bulk-edit handlers for the product temperature-zone field verified a nonce name that WooCommerce never issues for those forms, so the check always failed and the field silently stopped saving from quick\/bulk edit. They now verify the same woocommerce_quick_edit_nonce that WooCommerce core verifies, restoring the feature.<\/li>\n
- Security: the classic-checkout store validation and the PAYUNi store-restore handler now verify their nonces first, in straight-line form, before touching any request field.<\/li>\n
- readme: every provider entry now lists its test\/sandbox hostname inline and carries an explicit Terms link and an explicit Privacy link (providers publishing a single combined document have both links pointing at it, with a note); the AMEGO terms link points at the actual terms page; added the previously undocumented ecpayment-stage.ecpay.com.tw test hostname.<\/li>\n<\/ul>\n\n
1.4.8 - 2026-07-19<\/h4>\n\n\n- i18n: the text domain is now
moksa-for-woocommerce<\/code>, matching the assigned plugin slug (all 4,000+ gettext calls, the plugin header, the block-checkout scripts and the bundled zh_TW translation files were updated; the main plugin file was renamed accordingly).<\/li>\n- Security: the PChomePay webhook no longer trusts its payload at all. On top of the source-IP allowlist, every notification now triggers a server-to-server query back to PChomePay (
GET \/v1\/payment\/{id}<\/code>) and the authoritative API response gates the order transition: order_confirm<\/code> requires API status S with a matching amount, and expiry\/failure notifications are rejected for orders the API reports as paid. The allowlisted IPs are now filterable via moksafowo_pchomepay_notify_ips<\/code>.<\/li>\n- Security: the product temperature quick-edit \/ bulk-edit \/ product-save \/ variation-save handlers now re-verify the WooCommerce nonce and check
edit_product<\/code> capability in-place (fail-closed) instead of relying on the upstream caller having done so.<\/li>\n- readme: each SmilePay integration now explains that ssl.smse.com.tw is SmilePay's own API hostname (smse.com.tw and smilepay.net are operated by the same company, \u8a0a\u822a\u79d1\u6280); OpenAI policy links point at the individual terms and privacy pages.<\/li>\n<\/ul>\n\n
1.4.7 - 2026-07-12<\/h4>\n\n\n- Naming: the PHP namespace root was changed from
MoksaWeb\\Mowc\\<\/code> to Moksafowo\\<\/code>, so every global identifier the plugin declares (namespaces, constants, options, hooks, AJAX actions, database tables) now shares the single moksafowo<\/code> prefix.<\/li>\n- Naming: six filters were still published under WooCommerce-prefixed hook names (
woocommerce_get_sections_*<\/code>, woocommerce_get_settings_*<\/code>, woocommerce_shipping_*_is_available<\/code>) even though the methods that fire them fully override WooCommerce and never call the parent implementation. They are now moksafowo_*<\/code>.<\/li>\n- Naming: the checkout field namespace and admin CSS class prefix were unified under
moksafowo<\/code>; the unused legacy MOWP_VAULT_KEY<\/code> constant fallback was removed.<\/li>\n- Database: every table name now goes through
$wpdb->prepare()<\/code> using the %i<\/code> identifier placeholder, and every LIKE<\/code> pattern through %s<\/code>. No table name or search term is interpolated into SQL anywhere in the plugin, including uninstall.php<\/code>.<\/li>\n- Fix:
Aes::decrypt_cbc_hex()<\/code> validated its input only after calling hex2bin()<\/code>, which emitted a PHP warning on malformed input before the exception was thrown. It now validates first.<\/li>\n- Admin: order detail notes no longer expose the internal plugin codename.<\/li>\n<\/ul>\n\n
1.4.6 - 2026-07-12<\/h4>\n\n\n- Security fix: the NewebPay logistics store-map callback verified its signature only when a HashData value was actually supplied, so an attacker could omit it to skip verification. Now rejected (fail-closed) whenever HashData is missing.<\/li>\n
- Security fix: PayNow's secondary PassCode2 check (barcode\/e-wallet payments) was skipped when the field was empty instead of being required; now fail-closed.<\/li>\n
- Settings: corrected the SmilePay \"Mid\" field description, which still described the old skip-if-empty behaviour after the fail-closed fix.<\/li>\n
- readme: OpenAI's Terms\/Privacy links replaced with OpenAI's policy hub, which several individual policy sub-pages intermittently blocked as bot traffic.<\/li>\n
- Added explicit references to the exact WooCommerce core methods (
WC_Settings_Page<\/code>, WC_Shipping_Method::is_available()<\/code>) that mandate the woocommerce_*<\/code>-prefixed filter tag names flagged by the automated prefix scan \u2014 these are WooCommerce's own extension-point names, not ones this plugin defines.<\/li>\n<\/ul>\n\n1.4.5 - 2026-07-12<\/h4>\n\n\n- Security hardening: the SmilePay payment callback now rejects requests when the merchant verification code (\u53c3\u6578\u78bc) is not configured (fail-closed) and only accepts callbacks for orders actually paid via SmilePay.<\/li>\n
- The LINE Pay admin confirm action now uses the standard check_ajax_referer() flow.<\/li>\n
- Readme: clarified SmilePay\/ezPay combined terms & privacy documents and documented carrier tracking links (pure hyperlinks \u2014 the plugin never contacts those hosts) with verified policy links.<\/li>\n<\/ul>\n\n
1.4.4 - 2026-07-05<\/h4>\n\n\n- Removed a non-functional leftover PAYUNi credentials migrator (its map used identical source and target option names, so it did nothing).<\/li>\n
- The e-invoice donation-organization option is now written under a statically-prefixed, allow-listed option name.<\/li>\n
- Reworked the PAYUNi store-selection restore so the nonce verification is inline and explicit.<\/li>\n<\/ul>\n\n
1.4.3 - 2026-06-28<\/h4>\n\n\n- Completed the \"External services\" documentation in the readme to list every payment, shipping and e-invoice endpoint the plugin can contact, including the credit-card query endpoint and all sandbox\/test hostnames.<\/li>\n
- Minor security hardening of the PAYUNi store-selection AJAX handler: the request nonce is now verified before any other processing.<\/li>\n<\/ul>\n\n
1.4.2 - 2026-06-21<\/h4>\n\n\n- Improved the AI assistant's handling of multi-part questions (e.g. asking for revenue and pending-shipment counts in one message) so they are answered reliably in a single reply.<\/li>\n<\/ul>\n\n
1.4.1 - 2026-06-20<\/h4>\n\n\n- Further hardened output escaping on the admin order payment panel and the customer payment-information notice and email (allow-listed HTML at the point of output).<\/li>\n<\/ul>\n\n
1.4.0 - 2026-06-20<\/h4>\n\n\n- E-invoice fields on the block checkout now show, hide and validate through WooCommerce's native conditional field logic (JSON Schema) instead of custom scripting, for reliable behaviour across WooCommerce updates.<\/li>\n
- The mobile-barcode and personal-certificate carrier inputs are now separate fields, each with its own format validation.<\/li>\n
- Raised the minimum WooCommerce version to 9.9, required by the native conditional checkout fields.<\/li>\n
- Internal consolidation of the e-invoice checkout-field code, plus further hardening of asset loading and input handling.<\/li>\n<\/ul>\n\n
1.3.0 - 2026-06-18<\/h4>\n\n\n- New Moksa AI in-admin assistant (requires WordPress 7.0 AI Client and a configured AI connector): query and manage orders, e-invoices, shipping labels and module settings in natural language, with a human confirmation step before any change is applied.<\/li>\n
- Order tools via the WordPress Abilities API: find order by number, order details, order counts, status changes (single and batch), order notes, and an advanced order list.<\/li>\n
- Taiwan e-invoice actions: issue, void and allowance, plus per-channel issuing-method toggles.<\/li>\n
- Shipping: create a logistics booking and print labels (single and batch).<\/li>\n
- Manage settings by natural language: enable or disable provider modules, individual payment methods and invoice issuing methods \u2014 each behind a confirmation step. Credentials and sandbox\/live switches are never exposed.<\/li>\n
- Raised the minimum WordPress version to 7.0, required by the AI assistant and the Abilities API. Core payment, shipping and invoice features are unchanged.<\/li>\n
- Removed the unused SMS module.<\/li>\n<\/ul>\n\n
1.1.0 - 2026-06-05<\/h4>\n\n\n- All global identifiers renamed to the unique
moksafowo<\/code> prefix (options, hooks, AJAX actions, gateway IDs, script handles, order meta, custom order statuses) per WordPress.org review.<\/li>\n- Hardened all payment \/ logistics webhook handlers: signature verification before any use, full per-field input sanitization, no raw request logging.<\/li>\n
- Store-selection restore at checkout now requires a nonce.<\/li>\n
- All inline
<script><\/code> \/ <style><\/code> output replaced with wp_enqueue_*<\/code>, wp_add_inline_*<\/code> and wp_print_inline_script_tag()<\/code>.<\/li>\n- All dynamic admin card \/ tracking-link HTML now escaped through explicit
wp_kses<\/code> allowlists at output time.<\/li>\n<\/ul>\n\n1.0.0 - 2026-05-26<\/h4>\n\n\n- Initial public release on the WordPress.org Plugin Directory.<\/li>\n<\/ul>","raw_excerpt":"A Taiwan e-commerce toolkit for WooCommerce. Bundles Taiwanese payment, shipping and e-invoice integrations.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/319092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=319092"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/moksa0923"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=319092"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=319092"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=319092"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=319092"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=319092"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=319092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}