EffortLess Easy Online Payment

Changelog

1.1.7

• Fixed three dead third-party links in the External services section, found by the WordPress.org review team: ECPay’s Terms of Service and Privacy Policy URLs (both 404) now point at ECPay’s current support-site pages, and LINE Pay’s Terms of Use URL (400 error) now points at LINE Pay’s current Merchant Terms of Use. Every External services URL was re-checked with a live HTTP request before release.

1.1.6

• Restructured this readme so the plugin’s real documentation (previously under custom headings like Features, Multisite, Settings, Apple Pay sandbox, Going live, Security notes and Notes and limitations) now lives under Installation and Frequently Asked Questions, the only two headings besides Description that WordPress.org’s readme parser keeps separate. Every custom heading’s content is merged by that parser into the Description section before its length is checked, which is why a persistent “Description section too long” scan warning survived several rounds of shortening the literal Description paragraph — the paragraph itself was never the source of the excess length. No documentation content was removed, only relocated; External services keeps its own required heading, so its content still contributes to that combined length, but is small enough on its own to stay within limit.

1.1.5

• Shortened the Description section further and removed apostrophes, em dashes and an arrow character from it. Superseded by the 1.1.6 restructuring above, which addresses the actual cause.

1.1.4

• Fixed two spots in this readme where a section-heading-style double-equals reference appeared inside a sentence rather than as an actual heading — a readme parser that isn’t strictly line-anchored can mistake that for a section boundary and mis-scan surrounding content. Reworded both to plain text references instead.

1.1.3

• Fixed the order lookup used by every capture path (checkout capture, LINE Pay return, ECPay notify, Stripe webhook) to no longer bypass other plugins’ post-query filters (e.g. a translation plugin’s language scoping) — it previously set suppress_filters to true.
• Shortened the Description section in this readme; no functional change (the removed detail is fully covered under the Settings section below).

1.1.2

• Updated “Tested up to” to WordPress 7.1.

1.1.1

• Fixed a backward-compatibility bug: a site that had a single payment gateway configured before this release (e.g. Stripe only, no PayPal) lost checkout entirely after upgrading, because the new Enabled Gateways setting defaulted to PayPal instead of the site’s actual configured gateway. Enabled Gateways now correctly falls back to the site’s Active Gateway whenever no Enabled Gateways value has been saved.
• On a checkout page offering more than one gateway, a Stripe SDK load failure no longer shows a shared red error message across the whole checkout form — the other gateways’ buttons keep working, and the failure is only logged to the browser console. A checkout misconfigured with no gateways at all now shows a clear “temporarily unavailable” message instead of rendering blank.
• The Stripe card fields container no longer renders visibly before Stripe actually loads, avoiding an orphaned “or pay with card” divider on checkouts where Stripe isn’t an eligible gateway.
• Removed an unused data attribute on the checkout markup left over from an earlier Apple Pay implementation.
• Hardened the checkout order REST endpoint against a malformed array-valued gateway parameter.

1.1.0

• Added multi-gateway checkout choice: a site can now enable more than one payment gateway at once (new “Enabled Gateways” checkboxes in Settings, alongside the existing Active Gateway select). Checkout shows a button for every enabled gateway that is configured and supports the product’s currency, in a fixed order (PayPal, Stripe, LINE Pay, ECPay), and the customer chooses which one to pay with. A gateway that doesn’t support the product’s currency never shows a button even when enabled (LINE Pay: USD, TWD or THB only; ECPay: TWD only).
• The Active Gateway setting’s role is now narrower: it is the default Enabled Gateways falls back to when saved empty, and it drives the settings screen’s Sandbox/Live mode notice — checkout’s own fallback gateway and its wallet-button gateway are now decided by a fixed priority order instead, and Active Gateway is no longer the only gateway offered at checkout.
• When wallet buttons (Apple Pay) are enabled and more than one wallet-capable gateway (PayPal, Stripe, ECPay) is enabled and eligible, only one gateway’s wallet button is shown, chosen by a fixed priority order: PayPal, then Stripe, then ECPay — never more than one wallet button at once. LINE Pay has no wallet integration.

1.0.0

• First stable release. Verified a complete live PayPal Sandbox transaction end to end using this exact release build: order creation against PayPal’s real Orders v2 API, buyer approval through PayPal’s own sandbox checkout page, and capture against PayPal’s real Capture API, independently cross-checked directly against PayPal afterward. No code changes; this release marks the plugin’s first version confirmed to complete an actual gateway transaction rather than being verified by code review and automated tests alone.

0.2.25

• Full code and security review of the whole plugin. Documented a gap in the uninstall instructions: on a Multisite network, the shared Network Admin payment settings (including PayPal live/sandbox credentials a Super Admin may have configured) weren’t mentioned in the manual-removal steps, so they could be left behind indefinitely after uninstalling. No code behavior changed; the dedicated security review found no exploitable issue.

0.2.24

• Restricted the Products and Orders admin screens to administrators only: both custom post types previously used plain WordPress post capabilities, which meant an Editor-role user could view every order (customer name, email, phone, delivery address, gateway IDs) and delete payment records, and an Author-role user could create or edit products with an arbitrary price. Both now require the manage_options capability, matching every other admin action this plugin already gates the same way.
• Fixed the Apple Pay domain-verification file handler to compare against the same site-URL-derived path the settings page tells you to check, instead of a hardcoded domain-root path — on a WordPress install in a subdirectory, the handler previously never matched the URL the plugin itself advertised.
• Fixed a gap where a Super Admin’s blank Network Admin domain-verification field could silently clear a subsite’s own value on save; it’s now only inherited when the network field actually has content, matching how the existing Apple Pay toggle inheritance already works.
• Added a distinct admin email when a captured payment’s amount doesn’t match the expected order total, so this integrity check is no longer silent — previously the order was flagged internally but nobody was notified.
• Fixed a race window where a concurrent or retried capture request on an order already flagged for a mismatched amount could receive a false “payment succeeded” response instead of the correct error; the order’s own status was never affected, only what a second, near-simultaneous request was told.
• Added a lightweight lock around payment capture to reduce the chance of a duplicate admin notification when two capture attempts for the same order land at nearly the same moment (e.g. the buyer’s browser and a gateway webhook arriving together).
• Fixed several smaller inconsistencies found reviewing the whole plugin together: a stale settings description that said “both gateways” when there are four; a missing context field in the gateway interface’s own documentation; a duplicated order-lookup method between two files, now shared; an unused capture-time field written by only one of the four gateways, now removed since nothing displayed it; and a checkout return URL now validated against the site’s own domain before being handed to a payment gateway as a redirect target.
• Translated the remaining hardcoded English text in the admin settings, network settings, and order/product detail screens so the plugin’s declared text domain actually covers the full admin interface.
• readme.txt: documented every Product editor field (previously only partially covered), added ECPay to a shipping-address limitation note that only mentioned two of the three affected gateways, and noted that the Apple Pay domain-verification URL resolves under a subdirectory install’s own path.

0.2.23

• Fixed a stale Settings description that still listed only PayPal, Stripe and LINE Pay as Active Gateway options; it now also mentions ECPay.

0.2.22

• Added a PHPUnit test suite for development use. This is dev-only tooling: it is not shipped in the release package and has no effect on the plugin’s behavior when installed on a site. It covers the ECPay CheckMacValue signature algorithm, Stripe webhook signature verification, capture idempotency (a completed order’s capture_order() is never invoked twice), capture amount- and currency-mismatch handling, the reserved order-meta keys that a capture result cannot overwrite, and a regression test for the multisite Apple Pay settings-inheritance behavior fixed in an earlier release. No plugin logic was changed for this work — the only edits outside tests/ are the version bump itself.

0.2.21

• Code-standards cleanup: the three original REST routes (order creation, capture, and the LINE Pay return handler) now use named, individually-justified permission callbacks instead of the bare PHP function __return_true, matching the pattern already used by the ECPay and Stripe routes. No behavior change — these routes were already, and remain, intentionally public.
• Fixed the two remaining PHPCS findings: a read-only admin-notice flag that didn’t need nonce verification, and two custom-table-free order lookups by gateway ID that have no faster built-in WordPress alternative. Both are now individually documented rather than left as open warnings.
• Verified this release end-to-end against a real WordPress 7.0 core install (not just the working tree): installed from a built zip, activated with no errors, and rendered every admin screen plus a live checkout page with no PHP warnings, notices, or fatal errors.

0.2.20

• The wallet-buttons (“Apple Pay”) setting is now enforced server-side for ECPay checkout too, not just hidden client-side — a request that asks for Apple Pay falls back to the standard credit/debit card flow when the setting is disabled, matching how the other gateways already handle this. No change when the setting is enabled.
• Reworded a stale readme.txt sentence that described ECPay checkout as credit/debit-card-only; it now also mentions the Apple Pay option added in 0.2.19.
• readme.txt: noted that Apple Pay through ECPay may need to be separately enabled on the merchant’s ECPay account, and broadened the multisite note about per-site wallet-button settings to cover ECPay as well as Stripe.

0.2.19

• Added Apple Pay as a second ECPay payment option, alongside the existing credit/debit card checkout — same AllInOne Checkout form-POST flow and capture logic, just a different ChoosePayment value, since Apple Pay’s payment confirmation behaves identically to card’s (unlike ATM/CVS/barcode, which remain out of scope). Reuses the existing wallet-buttons setting, now covering all three gateways that offer one (PayPal, Stripe, ECPay). No separate domain registration is needed for ECPay’s Apple Pay, unlike PayPal or Stripe. The wallet-buttons setting defaults to enabled, so existing ECPay sites will start showing the Apple Pay button to eligible Safari visitors automatically; the setting is also now enforced server-side, so a checkout still falls back to the standard credit/debit card flow when the setting is disabled, even if the request asks for Apple Pay.

0.2.18

• Fixed the Express Checkout Element’s wallet container staying permanently hidden after a shipping-country or amount change re-evaluated available payment methods; the “available” branch now also clears the inline display: none set by the earlier “unavailable” branch, not just visibility.

0.2.17

• Fixed Stripe wallet buttons being mounted into a hidden-attribute container, which deviated from Stripe’s documented pattern and risked the Express Checkout Element failing to size itself; buttons are now shown/hidden with style.visibility, matching Stripe’s own example.
• Fixed the Express Checkout Element’s confirm handler not signaling failures back to the wallet’s payment sheet, which could leave it stuck open after a declined or errored payment.
• Fixed a multisite issue where the Network Admin’s PayPal-only Apple Pay override could silently control the wallet-buttons setting on a subsite whose active gateway is Stripe; the override now only applies when the subsite’s active gateway is PayPal.

0.2.16

• Added Apple Pay and Google Pay to Stripe checkout, via Stripe’s Express Checkout Element sharing the same Elements instance as the existing card fields. Reuses the existing wallet-buttons setting (previously labeled “Apple Pay”, now gateway-agnostic) rather than adding a separate processor selector, since only one gateway is active per site at a time. Requires registering this site’s domain in the Stripe Dashboard before the wallet buttons appear; card checkout is unaffected either way.
• This setting defaults to enabled, so existing Stripe sites will start showing wallet buttons automatically (once, and only once, their domain is registered in the Stripe Dashboard) — no other action is needed.

0.2.15

• Split the Stripe webhook signing secret into separate Test and Live fields, matching every other Stripe credential’s per-Mode pattern — a single shared secret previously kept working with a stale value after switching Mode, silently failing signature verification.
• Added WP_DEBUG-guarded diagnostic logging to the Stripe webhook’s order-not-found and wrong-gateway branches, so a failed or ignored webhook call can be diagnosed from the PHP error log.
• Added a Frequently Asked Questions entry covering the Stripe webhook’s real preconditions.

0.2.14

• Added an optional Stripe webhook endpoint (payment_intent.succeeded / payment_intent.payment_failed) so a payment is captured even if the buyer’s browser never completes the client-side confirmation round trip. Verifies Stripe’s own HMAC-SHA256 request signature before trusting anything in the payload, and reuses the exact same amount-verification and idempotency logic the client-driven capture path already uses.

0.2.13

• Fixed ECPay’s notify endpoint being unreachable on any subdirectory WordPress install: the inbound request path is now compared against the same home_url()-derived path used to build ECPay’s ReturnURL, instead of a bare constant that never matched once a site had a subdirectory in its address.
• Fixed the ECPay notify handler being able to finalize an order that belongs to a different, unrelated gateway (which has no CheckMacValue-style signature check of its own) — it now requires the resolved gateway to actually be ECPay before processing.
• Fixed ECPay’s notify handler sanitizing POSTed values before verifying ECPay’s CheckMacValue signature, which could reject a genuine notification whose fields happened to contain characters sanitize_text_field() strips or alters.
• ECPay notify failures caused by an invalid signature or a not-yet-configured gateway now withhold the “1|OK” acknowledgement so ECPay’s own retry mechanism can recover once the issue is fixed; every other outcome (order not found, unrelated gateway, amount mismatch, already-completed, success) still acks normally.
• Added WP_DEBUG-guarded error logging to every ECPay notify failure path, matching the existing PayPal/Stripe/LINE Pay logging pattern.
• Fixed the checkout page’s “processing” status for ECPay never re-checking the order’s current status on a later page load — it previously stayed on “processing” forever even after the order had since completed or failed.
• ECPay checkout is now restricted to credit/debit card (ChoosePayment=Credit); ECPay’s ATM, convenience-store and barcode payment methods are not yet supported and are documented as out of scope.

0.2.12

• Added ECPay as a fourth payment gateway option (ECPay’s AllInOne Checkout — a signed form-POST checkout: the customer’s browser submits a signed form directly to ECPay, authorizes there, and ECPay confirms the result to your site server-to-server). TWD only, whole-number amounts; a checkout attempt in any other currency or with a fractional total is rejected before contacting ECPay.
• ECPay’s payment confirmation uses its own server-to-server notification (which ECPay itself retries for about a day if unreachable) as the sole authoritative capture path, reusing the same capture/amount-verification logic PayPal, Stripe and LINE Pay already share. The page the customer’s browser returns to after paying is a separate, not-guaranteed-to-fire mechanism that only ever displays the order’s already-current status — it never changes order state itself.

0.2.11

• Fixed the LINE Pay captured-amount check: it previously echoed back the same order total it sent to LINE Pay’s Confirm API, so the amount-mismatch check compared a value against itself and could never fail. It now sums LINE Pay’s own Confirm response (the per-payment-method amounts LINE Pay reports it captured) for a genuinely independent check, matching how PayPal and Stripe already report a captured amount sourced from their own API response. LINE Pay’s Confirm response has no currency field, so the currency side remains a comparison against the expected value; this is documented as a limitation of LINE Pay’s API.
• Fixed the “Payment cancelled.” notice on the checkout page, which could never appear because the cancel redirect carries no order identifier.
• The “payment successful” notice on the checkout page now also requires the order to be a genuine order post with a stored Completed status, not just a guessable order ID for the right product.
• Added rate limiting to the LINE Pay return endpoint, consistent with the other checkout endpoints.
• Documented that a LINE Pay order left unfinished when the customer closes the tab before returning to the site stays pending indefinitely, with no automatic reconciliation.

0.2.10

• Added LINE Pay as a third payment gateway option (LINE Pay Online API v4, a redirect checkout — the customer authorizes on LINE Pay’s own site and is returned to yours once payment is confirmed). Supports USD, TWD and THB only; a checkout attempt in any other currency is rejected before contacting LINE Pay.
• The capture/amount-verification logic PayPal and Stripe checkout already used is now shared with LINE Pay’s return handler, rather than duplicated, so all three gateways get the same integrity checks.

0.2.9

• Added the missing readme.txt Description section, fixed the Installation walkthrough (it still referenced the per-product shipping field removed in 0.2.6, and never mentioned choosing a gateway or entering Stripe credentials), and restored a Notes and limitations section covering the single-active-gateway model, Stripe checkout charging the shipping fee without yet sending an address, the Taiwan-only shipping default, multisite inheritance being limited to PayPal, and shipping never applying to digital/service products.
• Corrected the External services entry for Stripe (it claimed quantity is sent to Stripe; it is not) and expanded the Settings reference to cover the multisite inherit checkbox and the Network Admin screen.
• Aligned the site-level Apple Pay domain-association field to use the same newline-preserving sanitizer as the network-level field, and removed an unused internal property. No behavior changes.

0.2.8

• readme.txt: trimmed Tags to 5, added a Donate link, an External services disclosure section (PayPal, Stripe, Apple Pay), a setting-by-setting Settings reference, and a Frequently Asked Questions entry.
• Added a dismissible “support the development” notice on the plugin’s settings screen, with a donate link in the plugin header.
• Fixed a number of pre-existing code-standards findings: missing docblocks, unslashed $_POST/$_SERVER reads before sanitization, the Apple Pay domain-verification field now uses a newline-preserving sanitizer, and parse_url() replaced with wp_parse_url(). No behavior changes.

0.2.7

• Fixed PayPal checkout sending an empty shipping address under SET_PROVIDED_ADDRESS when the “Collect a full delivery address” setting was off; the provided-address path is now only used once an address has actually been entered, otherwise physical products fall back to letting PayPal collect the address (GET_FROM_FILE).
• Fixed the PayPal shipping address mapping: it previously mapped only the second-level administrative division (admin_area_2) from the city field and never populated the first-level division (admin_area_1), silently dropping the district field some destinations require. admin_area_1 is now mapped from city and admin_area_2 from district.
• Removed the “Restrict countries” shipping setting: with it off, a submitted country code skipped format validation, and the checkout country selector was always built from the enabled delivery-country list regardless of the setting, so it had no effect either way. Delivery is now always limited to countries with an enabled rule.
• A shipping-enabled site with zero enabled delivery countries now behaves the same as shipping being off, instead of showing an empty, unusable country selector.
• Apple Pay no longer requests a separate delivery address/phone number when the checkout’s own shipping form is already collecting one, avoiding two potentially different delivery addresses on the same order.
• The order-notification email now includes the delivery address when one was collected.

0.2.6

• Added a country-based shipping system for physical products: an admin-configured allowlist of delivery countries and per-country fees (defaults to Taiwan only), server-side validated at checkout, with an optional full delivery-address collection step. Replaces the previous flat per-product shipping fee, which has been removed from the product editor.
• PayPal checkout now passes the validated delivery address through as a provided shipping address (SET_PROVIDED_ADDRESS) for physical products, instead of relying on the buyer’s PayPal account address.
• Stripe checkout’s charged total includes the shipping fee for physical products (via the shared server-side pricing calculation), but Stripe does not yet collect or receive a delivery address — that is planned for a future update.

0.2.5

• Fixed the Stripe checkout to use Stripe’s deferred-payment-intent pattern: the Payment Element now mounts with a display-only estimate and the real order/PaymentIntent is only created when the buyer clicks Pay, using the quantity selected at that moment. Previously the order and PaymentIntent were created at page load with quantity fixed at 1, so a buyer who changed quantity before paying was charged for the original quantity instead of the displayed total, and an order/PaymentIntent was also created on every page view regardless of purchase intent.
• Restricted the Stripe PaymentIntent to card payments only, matching this plugin’s card-only checkout scope and avoiding a redirect-based payment method failing with no return-URL handling page.
• Fixed the capture amount-verification check incorrectly flagging a routine pending/processing Stripe payment for manual review; the check now only runs once a payment has actually completed.
• Reduced the detail forwarded from Stripe API error responses to the public order-creation endpoint to buyer-actionable card/validation errors only, since Stripe error messages can otherwise include configuration or key-related detail.
• Fixed the currently-active gateway setting being used to capture every order regardless of which gateway actually created it; capture now uses the gateway recorded on the order itself, so changing the active gateway mid-checkout can no longer route a capture to the wrong API.
• Filled in missing gateway setting defaults on read so a saved settings option from before Stripe was added, or one missing individual fields, is completed with defaults instead of leaving them unset.
• Generalized remaining PayPal-only wording in checkout/order messages and the plugin description now that Stripe is a second gateway option.

0.2.4

• Added Stripe as a second payment gateway option (embedded card checkout via Stripe Elements and PaymentIntents). A new “Active Gateway” setting selects PayPal or Stripe; only one gateway is active per site. No Apple Pay/Google Pay through Stripe and no Stripe webhook in this version.
• Settings storage restructured: gateway credentials now live under a nested “gateways” structure instead of top-level fields, to support more than one gateway.

0.2.3

• Fixed the order of the capture amount-verification check so the expected order total/currency are read before any gateway-returned data is written, and reserved the post-meta keys this check owns so gateway data can never overwrite them.
• Removed a leftover duplicate plugin bootstrap call left over from a prior internal file reorganization.
• Fixed a rare race condition on first use of the internal checkout security secret.
• Updated the uninstall instructions comment to mention the checkout security secret option.

0.2.2

• Internal refactor: extracted all PayPal-specific code behind a new ELEOP_Gateway interface (ELEOP_Gateway_PayPal), so a future payment gateway can be added without changing checkout, settings, or order-management code. No user-visible change — checkout behavior, the admin UI, and stored settings are unaffected.
• Replaced the wp_salt()-derived checkout security token with a dedicated, randomly generated secret stored in its own option, per this project’s standing rule against deriving plugin secrets from WordPress authentication material.

0.2.1

• Renamed plugin identity from “EffortLess Paypal Online Payment” (ELPOP_) to “EffortLess Easy Online Payment” (ELEOP_): class, constants, option names, CPT slugs, REST namespace, shortcode tag, and asset identifiers all updated accordingly. No functional changes.

0.2.0

• Added full WordPress Multisite support.
• Added Network Admin shared PayPal / Apple Pay settings.
• Added per-site inheritance control.
• Kept products, orders and storefront settings isolated per site.
• Shared network secrets remain hidden from subsite administrators.

0.1.0

• Initial release.