Release v0.1.16

0.1.16

Fixed

• POS orders paid with PayArc ignored the per-gateway order status.
  WooCommerce POS picks the status for a paid order from the gateway recorded
  on the order, but a PayArc payment is created and completed over AJAX, polling
  or the webhook, never through the WooCommerce pay form that records the
  chosen gateway. The order kept an empty or default (cash) payment method, so
  the POS fell back to "Completed" whatever was configured for PayArc Terminal
  under POS → Settings → Checkout. The gateway is now recorded on the order
  just before it is marked paid. It is deliberately not recorded when a payment
  merely starts, so an abandoned terminal attempt cannot leave PayArc Terminal
  on an order that is then paid another way.

Release v0.1.15

0.1.15

Added

• Declines now say why. When a terminal payment resolves as declined or
  failed, the processor response code/text, PayArc error, and card entry mode
  from the authoritative transaction payload are shown to the cashier
  ("Payment was not approved. Processor response: 51 Insufficient funds.
  Card entry: contactless."), appended to the order note, and logged with the
  resolved attempt. Previously only the bare status word was recorded, so an
  issuer decline was indistinguishable from a merchant configuration fault.

Fixed

• Starting a new payment resets the activity-log dedupe state, so a repeated
  status from a previous attempt is logged again for the new attempt.

Internal

• Terminal record field extraction consolidated into a single helper.

Release v0.1.14

0.1.14

Merchant-experience follow-ups from the first live 0.1.13 session.

Fixed

• Callback authentication no longer depends on PayArc support. PayArc's
  docs confirm the callback bearer token is only issued during account setup
  and cannot be fetched through the API. The plugin now generates its own
  secret when you press Connect PayArc and embeds it in the callback URL sent
  with every sale; inbound callbacks verify against it automatically. The
  "Callback bearer token must be configured" validation warning is gone — the
  PayArc-issued bearer remains supported as an optional extra check.
• The cashier activity log no longer repeats the same status. Polling
  re-reported "Payment sent to terminal." every couple of seconds; consecutive
  duplicate entries are now collapsed.
• No more false "no POS identifier" notice for the configured terminal.
  The Terminal Registry mirrors an already-provisioned terminal without its
  pos_identifier; when such a record matches the configured serial (or an
  identified terminal), it is treated as registry metadata instead of being
  reported as an unidentified device. Genuinely unknown registry records are
  still surfaced.

Changed

• The Enable/Disable checkbox now reads "Enable PayArc Terminal on the online
  checkout" and explains that WooCommerce POS manages its own gateways — most
  stores should leave it unchecked.
• The callback bearer token field is documented as optional.

Upgrade note

Press Connect PayArc once after updating so the callback URL token is
generated.

Release v0.1.13

0.1.13

Release focus: make production V3 terminal payments actually work. Every change in
this release is backed by live probes run against the production PayArc V3 API on
2026-07-23 (sale 200 on the real terminal, poll, cancel 200, final state ABORTED).

Fixed

• Production sales no longer fail with 401 UNAUTHORIZED. The V3 transactions
  API (payarcconnectapi.payarc.net) authenticates with the merchant
  SecretKey/API bearer JWT, not the curvpos Login AccessToken the plugin used to
  send. The SecretKey is now the default V3 credential; on a 401 the client
  automatically retries with a force-refreshed Login AccessToken and remembers
  whichever credential PayArc accepts (v3_auth_credential). If both are
  rejected, the error names the host and directs the merchant to PayArc support.
• X-Idempotency-Key is sent on every V3 call, including GETs. The V3 API
  rejects requests without it (HTTP 400), which would have broken transaction
  polling and callback reconciliation.
• Polling tolerates the post-sale visibility window. PayArc accepts a sale
  (200 + traceId) but GET /v3/transactions/{traceId} returns
  TRANSACTION_NOT_FOUND for several seconds afterwards. Polling now treats
  that as "keep waiting" instead of surfacing an error to the cashier while the
  terminal is live.
• ABORTED is recognized as a final state. A cancelled terminal request
  reports ABORTED; polling now stops and re-enables retry instead of waiting
  for the five-minute timeout.
• Stored Connect token expiry 0 is treated as expired instead of
  never-expiring, and a Login response without ExpiresIn stores a 20-minute
  default lifetime.

Changed

• PayArc API failures now throw PayArcRequestException carrying the
  machine-readable PayArc error code and HTTP status.
• The connected-state guards (mode, credential fingerprint, Live-requires-
  Connect) run for every credential, not only the AccessToken path.
• The callback bearer token field explains that PayArc support provides the
  value and the Connect button cannot fetch it.

Notes

• Inbound callbacks are still rejected until the PayArc-provided callback
  bearer token is entered in the gateway settings; payments complete via
  polling in the meantime.

Release v0.1.12

PayArc Terminal for WooCommerce 0.1.12

This release fixes the reason terminal payments never started from WooCommerce POS, and removes a false alarm that sent merchants to PayArc support over a healthy terminal.

Payment authorization

• Start Payment no longer fails with "Access denied. (HTTP 403)" in WooCommerce POS. POS renders the order-pay checkout under the customer's user context while the cashier submits the payment, so the nonce minted for the page did not verify for the submitting user. The payment lifecycle handler checked that nonce first and returned 403 before the signed order token was ever consulted, so the sale never reached PayArc.
• Payment lifecycle requests are now authorized by either a valid signed order token (an HMAC over the order id and order key) or a valid nonce with order access. Capability-only requests still require the nonce, so no CSRF path is opened for shop managers. Forged, empty, and cross-order tokens are rejected.
• Denied payment requests are now logged server-side as PayArc payment request denied, recording the action, order id, the reason, and which credentials were present — never their values. Previously this rejection produced no server-side trace at all, which is what made the failure invisible in merchant logs.

Terminal diagnostics

• A registry record with no POS identifier is no longer reported as a fault. PayArc's Terminal Registry schema makes pos_identifier nullable, and the Sale API addresses a terminal by its 10-digit serial number, not by pos_identifier. The plugin was logging a WARNING per record on every connect and refresh, and telling merchants to ask PayArc support to provision the terminal — for a terminal that was working correctly.
• Such records now log at info level as no_pos_identifier, and the connection message states plainly that this is normal and that the terminal serial number is what PayArc Connect uses. Disabled terminal records still log as warnings.
• The log message is now PayArc terminal record not selectable, replacing the overstated "dropped during normalization".

Notes

• docs/payarc-api-spike.md previously stated that pos_identifier is the Connect V3 terminalId. That was wrong and is the origin of the false alarm above. It now records the documented contract: terminalId is the 10-digit terminal serial number (^[0-9]{10}$) and tenantId is the last 12 digits of the MID (^[0-9]{12}$).
• The checkout activity panel added in 0.1.11 is what surfaced this bug as Access denied. (HTTP 403). It remains collapsed by default — open Show activity at checkout when diagnosing a cashier report.
• The callback bearer token remains unconfigured on some installs. Payments still complete by polling, but configuring it in the gateway settings is recommended; see the callback_token_not_configured warning noted in 0.1.11.

Validation

• php tests/run.php — all 13 regression files pass, including new coverage that a signed order token alone authorizes a cashier request and that forged, empty, cross-order, and capability-only nonce-free requests are still rejected.
• Not verified against live POS hardware or a physical PayArc terminal.

Release v0.1.11

PayArc Terminal for WooCommerce 0.1.11

This release makes payment failures visible on both ends. Previously a failed terminal payment could produce no server logs and only a generic message at checkout; now every step of the transaction is logged server-side and the cashier sees what actually went wrong.

Logging

• The payment path now logs every step with masked identifiers: sale started, sale accepted (with masked trace id), sale request failed (exception class and redacted message), cancel requested/failed, and the poll that resolves a payment attempt to its final status.
• Payment AJAX failures are logged with the real exception instead of being silently swallowed; the client response stays generic.
• PayArc callbacks are logged: accepted (masked trace id) or rejected with the exact reason — callback token not configured, missing or malformed Authorization header, or token mismatch. Rejection warnings are throttled to 5 per source per minute, and no token material is ever logged.
• All payment-path logging is failure-guarded so diagnostics can never interrupt a payment.

Checkout panel

• The payment activity log at checkout is now collapsible (Show/Hide activity) with a Clear button, timestamped entries, and auto-scroll, so cashier reports can be matched against server logs.
• Failed requests now show the server's sanitized error message and HTTP status instead of always printing "Unable to contact the payment service."
• When the session is not authorized for the order, the panel now says so explicitly instead of showing a silently disabled Start Payment button.
• Panel controls use delegated event handlers so they keep working when checkout re-renders, and a payment that is approved but cannot submit the order form now reports that clearly.

Notes

• If the callback bearer token is not configured, every PayArc callback is rejected and the order relies on polling to complete; the new callback_token_not_configured warning makes this visible. Configure the callback bearer token in the gateway settings.
• To diagnose a "terminal did not respond" report: check the checkout activity log for the failing step and HTTP status, then match the timestamp and order id against the PayArc sale ... entries in WooCommerce > Status > Logs (source: payarc-terminal-for-woocommerce).

Release v0.1.10

PayArc Terminal for WooCommerce 0.1.10

This release surfaces PayArc terminals that exist but have no POS identifier assigned, so an empty terminal list after Connect is no longer a dead end — the merchant sees the terminal, why it can't be selected, and what to do next.

Changed

• Terminal Registry records without a pos_identifier are now surfaced as non-selectable informational entries instead of disappearing silently. Connect and refresh results include a count and each record's terminal name/type (with the standard masked placeholder — never raw device ids or codes).
• When such records exist, the connection result message explains the situation: "PayArc reports N terminal(s) without a POS identifier assigned. Ask PayArc support to provision the terminal for PayArc Connect, or enter the PayArc-confirmed terminal serial number manually."
• The terminal dropdown on the settings page lists these records as disabled entries, including when no selectable terminal was discovered.
• The same unprovisioned terminal reported by both PayArc Login and the Terminal Registry is shown once.

Notes

• Identifier-less records remain excluded from the selectable terminal registry and from terminal_count, so terminal selection and payments are unaffected.
• The masked per-record drop warnings introduced in 0.1.9 (drop_reason: missing_identifier) are unchanged; connect and refresh completion logs additionally report an unidentified_terminal_count.

Release v0.1.9

PayArc Terminal for WooCommerce 0.1.9

This release removes over-strict client-side format validation that could hide a merchant's terminal, and adds diagnostic logging so terminal-discovery issues can be explained from a single log excerpt.

Changed

• Terminal identifiers are no longer required to be exactly 10 digits. PayArc's Terminal Registry documents pos_identifier as optional metadata with no format requirement, and PayArc's server is the authoritative validator — any non-empty terminal serial number is now accepted, and PayArc's own error is surfaced if a serial is wrong.
• Terminal Registry records with any non-empty identifier now appear in the terminal list; previously, records with shorter or alphanumeric identifiers were silently dropped.
• A manually entered terminal serial number is preserved regardless of format, and the settings form no longer enforces a 10-digit input pattern.
• Tenant id pre-flight validation now only requires a non-empty value; derivation from the last 12 digits of the MID is unchanged.
• Validation and help copy no longer insists on a "10-digit" serial number.

Logging

• Every terminal record excluded during normalization now logs a masked warning with a drop_reason (missing_identifier or disabled), so registry_terminal_count vs terminal_count mismatches are self-explanatory.
• Connect and terminal refresh completion logs include a new default_terminal_in_fetched_list flag showing whether the saved terminal serial number is one PayArc actually reports.
• Diagnostic logging never interrupts terminal discovery, and no raw identifiers or secrets reach the logs.

Notes

• A terminal serial number that PayArc does not recognize now fails at payment time with PayArc's error message instead of being blocked at save time.

Release v0.1.8

PayArc Terminal for WooCommerce 0.1.8

This release improves the PayArc gateway settings UI for saved secret fields.

Changed

• Saved PayArc secret fields now show a masked value ending in the last four characters instead of the word Configured.
• Empty PayArc secret fields now use clearer No saved value / Enter value copy.

Security

• Secret inputs still render with an empty value attribute so full saved tokens are not exposed in admin HTML.

Release v0.1.7

PayArc Terminal for WooCommerce 0.1.7

This test release updates terminal handling based on PayArc support's clarification that Terminal Registry records are reporting metadata only.

Changed

• PayArc Connect V3 remains the transaction API version.
• Gateway settings now ask for the 10-digit PayArc terminal serial number used as the V3 terminalId.
• Terminal Registry lookup is optional metadata and no longer blocks payments when it is empty, missing, or does not include the entered serial number.
• Connect and Refresh preserve a manually entered terminal serial number instead of clearing it when Terminal Registry returns no terminals.

Notes

• Ask PayArc support to validate the terminal serial number for the merchant account before testing.
• Terminal transactions still authenticate through PayArc Login and use the returned Connect AccessToken.