Webalive plugin

2.1.17 (2026-06-20)

• Settings: moved 'Late Cancellations' (cancel-time) from the Schedule tab into the Basic tab so it sits next to the 'Let Guests View and Cancel Bookings' toggle (same setting group).
• Admin booking edit popup: when 'Fixed start times' is configured, the time <select> now correctly pre-selects the booking's existing time by normalising the stored h:i A value to the 24-hour H:i format used by the fixed-times options. Previously editing a booking left the time field blank and submitting saved an empty/incorrect time.
• Admin booking form (add/edit modal): the party-size dropdown is no longer capped by the public 'Max Party Size' (party-size) / 'Min Party Size' (party-size-min) / per-location max-people settings. Admins and Booking Managers can now select any party size from 1 up to the global upper limit (100) when creating or editing a booking from wp-admin.

2.1.16 (2026-06-02)

• Consent checkbox: the privacy-page link inside the booking-form consent statement now opens the page in a lightweight vanilla-JS modal (loaded in an iframe) instead of navigating away. Uses no Bootstrap so it stays compatible with the Colibri theme. Adds .watb-modal styles to booking-form.css and the small handler to booking-form.js.

2.1.15 (2026-06-02)

• New setting under Schedule: 'Fixed start times' (HH:MM, comma-separated). When set, the booking form's time picker is replaced by a select limited to exactly those times. Combined with multiple schedule rules (e.g. 11:30–13:30 and 13:45–17:00) this lets you offer a small number of fixed seating slots without the customer being able to pick arbitrary times in between.
• Added 'At least 12 hours in advance' and 'At least 48 hours in advance' to the Late Cancellations dropdown, so customers can be required to cancel/modify 12 t or 48 t before their booking.

2.1.14 (2026-05-22)

• QuickPay reconciler heartbeat now writes on every admin pageload (moved before throttle) with an error_log() fallback if the DB insert fails, so it's verifiable that the reconciler is actually running.
• Admin "Take deposit" modal: removed hardcoded placeholder transaction values (SF20896 / #531954373), added full i18n on all labels, now displays the booked deposit amount, allows entering a partial capture amount, and falls back to a translated default subject and message when the optional subject-admin-deposit-taken / message-admin-deposit-taken settings are empty.
• Bookings list "Handle deposit" link now passes the deposit amount and currency so the modal can render them.
• New AJAX endpoint watb-admin-deposit-modal wires the "Take deposit" button to QuickPay capture (full or partial amount), so the modal is now functional instead of decorative.
• capture_quickpay_payment() accepts an optional explicit amount (in minor units) for partial captures.

2.1.13 (2026-05-22)

• QuickPay reconciler runs on every admin pageload (no longer gated to the bookings list) and writes a heartbeat log row to wp_wa_payment_log so it is always possible to verify it executed. A manual trigger ?watb_qp_reconcile=force is available on any admin page for users with manage_options. Capability gate widened to manage_options or manage_bookings; the per-pageload cost is bounded by a 5-minute transient so the reconciler does not hammer QuickPay's API.

2.1.12 (2026-05-22)

• Reconciliation now also recovers QuickPay payments that never received the customer-return (continue) call. For each wp_wa_payment row that has a transid but no aq_status_code, WATB queries the QuickPay REST API (GET /payments/{id}) and — if the payment is Approved — fills in the card/acquirer details on the payment row and marks the booking paid with the correct deposit. Combined with 2.1.10 this means that all historic payments (whether QuickPay-data was stored locally or not) are repaired the first time an admin opens the bookings list.

2.1.11 (2026-05-22)

• Compatibility: Tested with WordPress 7.0.

2.1.10 (2026-05-22)

• Reconciliation tool for historic QuickPay payments. When the booking admin list (Bookings) is opened, WATB now scans wp_wa_payment for rows that QuickPay has marked Approved (aq_status_code = '000') but where the matching booking still has empty deposit / receipt_id. Those bookings are patched in place: deposit is taken from the stored amount, receipt_id is set from the QuickPay transaction id, and the booking status is recalculated via determine_status(true). Each repair is logged to wp_wa_payment_log. This fixes bookings created before 2.1.9 (when the QuickPay server-to-server callback was not registered) so they now show the correct deposit and status.

2.1.9 (2026-05-22)

• QuickPay payment registration is now reliable even if the customer never returns to the site from QuickPay. A server-to-server callback URL is registered with QuickPay when the payment is created (?watb_action=callback&id=…). Both the return (continue) and the QuickPay callback now share the same verification + booking-update logic: the payment row is re-verified against the QuickPay REST API, then the booking deposit, receipt id and status are written. The flow is idempotent — whichever request arrives first marks the booking paid, and the second is a no-op. This fixes cases where a payment showed as Approved in QuickPay but the booking remained in "Afventer betaling" with 0 kr deposit.
• Added log entries to wp_wa_payment_log for every step of continue and callback to make future diagnostics possible.

2.1.8 (2026-05-22)

• QuickPay payment button on the booking page now uses the same look as the booking form's main submit button: it is rendered as a <button> inside <div class="watb-form-submit">, so the existing .watb-booking-form .watb-form-submit button styling from the active WATB theme (minimal, contemporary, columns, columns-alternate, booking-form) applies automatically. No new CSS needed.

2.1.7 (2026-05-21)

• QuickPay credentials are now auto-imported from Webalive Food & Drink Menu (WFDM) when they are missing in Table Booking. If WFDM is installed and configured on the same site, its ordering-quickpay-* values (API key, Agreement ID, Merchant ID, Private Key, Payment Window key, last used order number) are copied into the matching watb-quickpay-* settings — each field is only copied when WATB's own value is empty, so existing WATB credentials are never overwritten.

2.1.6 (2026-05-21)

• New setting "Payment text shown to customer" (Bookings > Settings > Payments > Quickpay): a free-text/textarea message that is shown to the customer above the QuickPay payment button during checkout.
• QuickPay payments are now never autocaptured. The payment is only authorised at checkout; you decide later whether to charge it.
• New bulk action in the bookings list: "QuickPay: Capture payment" — captures the authorised amount on the selected booking(s) via the QuickPay REST API.
• New bulk action in the bookings list: "QuickPay: Cancel / refund payment" — cancels an authorised-but-not-yet-captured payment, or refunds it if already captured.

2.1.5 (2026-05-21)

• QuickPay integration switched from the legacy Payment Window form-POST + async callback flow to the QuickPay REST API (api.quickpay.net), matching the approach used by Webalive Food & Drink Menu (WFDM). No more dependency on Quickpay-for-WooCommerce style code.
• Payments are now created server-side via POST /payments + PUT /payments/{id}/link, and the user is redirected to QuickPay's hosted payment window via a simple link.
• On return, payment status is verified by polling GET /payments/{id} (HTTP Basic auth using watb-quickpay-apikey), instead of relying on the async webhook callback.
• Removed the bundled lib/wa-quickpay/ library (was unused dead code parallel to the gateway implementation).
• Settings watb-quickpay-mercantid, watb-quickpay-formkey and watb-quickpay-privatekey are kept for backwards compatibility but are no longer used by the payment flow. Only watb-quickpay-apikey, watb-quickpay-agreementid and watb-currency are required.

2.1.4 (2026-05-15)

• Fixed fatal error when WooCommerce logger class is unavailable: QuickPay logger now initializes safely and skips logging operations if no WooCommerce logger exists.