Flipnzee Auctions — Escrow Safety, Shared Purchase Locks & Buy Now Improvements

This release builds on Lesson 142 — Robust Mobile Bid History Fix, which improved responsive bid history presentation while preserving bidder privacy.

Since that baseline, Flipnzee Auctions has evolved beyond auction display and bidding into a broader website and domain marketplace with purchase-intent management, shared listing reservations, Escrow.com integration, transaction diagnostics, and stronger payment-lifecycle safeguards.

This release summary covers the intervening development through Lesson 197 — Responsive Purchase-In-Progress Status.

1. Auction Interface and Bidder Privacy

Responsive Bid History — Lesson 142

• Contained bid history inside a responsive wrapper.
• Prevented the bid-history table from extending beyond the auction card.
• Allowed long date and time values to wrap.
• Applied fixed column widths and more compact mobile text and cell padding.
• Retained anonymous public bidder labels.

Bidder Privacy — Lesson 140 and Subsequent Maintenance

• Public displays use anonymous labels such as Bidder 1 and Bidder 2.
• Highest-bidder and winning-bidder displays preserve bidder privacy.
• Actual bidder information remains available to authorized administrators.
• Existing bidding, watchlist, and auction management functionality is retained.

Auction Card and Navigation Improvements

• Added compact, responsive auction-card presentation.
• Improved featured-image and logo sizing for website listings.
• Added stable auction-specific anchors so related marketplace links can direct visitors to the relevant auction.
• Added clearer account access through Login and Sign Up buttons.
• Improved frontend wording and presentation without unnecessarily changing the existing bidding workflow.

2. Escrow.com Integration and Purchase Lifecycle

Sandbox Diagnostics and Verification

Expanded administrator tools for inspecting existing Escrow-linked purchase intents, including:

• Read-only transaction and customer verification diagnostics.
• Improved handling of successful Integration Helper responses that return an empty body or JSON null.
• More useful authentication and HTTP error reporting.
• Exact transaction ID and purchase-reference matching.
• Verification of supported transaction and payment-state information.
• Environment-aware handling of linked Sandbox and Production transactions.

These diagnostics help administrators inspect provider state without treating an incomplete response as proof of payment.

Webhook Validation and Payment-State Safety

• Strengthened verification of incoming webhook events against the linked Escrow transaction.
• Added conditional, monotonic purchase-intent status transitions.
• Improved handling of duplicate, stale, malformed, or unsupported events.
• Prevented manual status changes and deletion of Escrow-linked purchase intents where those actions could undermine transaction reconciliation.
• Reduced exposure of raw provider response data in diagnostic logs.
• Retained the distinction between the legacy manual Transactions workflow and Escrow-linked Buy Now intents.

Production Transaction Safeguards

• Added a controlled, administrator-initiated Production Buy Now workflow with explicit safety checks.
• Added duplicate-reference lookup and exact transaction/reference verification before linking a provider transaction.
• Retained the disabled-by-default live transaction safety gate.
• Added checks for listing publication, price consistency, purchase-hold expiry, and auction eligibility.
• Preserved each transaction's recorded environment rather than assuming that the globally selected environment determines the environment of every existing transaction.

Production readiness checks and successful API authentication do not, by themselves, prove that a genuine Production webhook has been delivered or that a complete live payment lifecycle has succeeded.

3. Email Notifications and Buyer Agreement Delivery

• Added administrator notifications for new Buy Now requests.
• Added buyer acknowledgement emails that distinguish a purchase request from a completed transaction.
• Added administrator-controlled email testing.
• Added delivery of a verified Production Escrow agreement link when available.
• Added an administrator-only resend action for eligible linked Production agreements.
• Validated agreement links for HTTPS and the expected Escrow domain.
• Recorded notification outcomes for troubleshooting, without treating WordPress mail acceptance as proof that an email reached the inbox.

Email delivery failures do not automatically cancel or unlink an external transaction.

4. Webhook Auditing and Reconciliation

Webhook Diagnostics

• Added bounded webhook receipt and processing-stage audit information.
• Recorded sanitized details for request receipt, payload rejection, transaction verification, mismatches, stale-event handling, and local synchronization.
• Added safe endpoint probes to check that malformed requests are rejected before provider lookups or transaction-state changes.
• Separated synthetic endpoint tests from evidence of genuine Escrow-originated event delivery.

Scheduled Transaction Reconciliation

• Added administrator-triggered reconciliation of eligible linked transactions.
• Added scheduled reconciliation with bounded batches and per-intent cooldowns.
• Improved monitoring of the last successful run, recent failures, attempted transactions, verified results, status changes, and skipped items.
• Added safeguards requiring the exact linked transaction ID and purchase reference to match.
• Required supported and consistent provider state before applying a local lifecycle transition.

Reconciliation can help detect missed updates, but it is not a substitute for verifying genuine webhook delivery.

Production Technical Preflight

Added read-only checks covering relevant Production configuration, including:

• Saved environment selection.
• Presence of Production credentials without displaying their values.
• Production API connectivity.
• Expected Production webhook registration.
• HTTPS and administrator email configuration.
• Scheduled reconciliation readiness.
• Production Buy Now safety-gate state.

The audit distinguishes configuration checks from actual webhook delivery and other readiness requirements that need separate verification.

5. Shared Listing Reservations and Purchase Coordination

Shared Listing Locks — Lesson 189

• Added a shared listing reservation keyed by the canonical WordPress listing ID.
• Reserved a listing before creating a fixed-price purchase request.
• Released unattached reservations when validation or intent insertion failed.
• Synchronized the shared lock with eligible purchase-intent lifecycle transitions.
• Coordinated Analytics fixed-price requests with auction bidding to reduce conflicting purchase attempts.
• Preserved existing listing and auction database structures without introducing a schema migration for this feature.

Abandoned Sandbox Hold Cleanup — Lesson 190

• Added an administrator-only, nonce-protected cleanup action for eligible abandoned Sandbox test intents.
• Required explicit confirmation that buyer funds were not secured.
• Used the existing lifecycle mechanism to cancel the local intent and release its shared reservation.
• Kept the external Escrow transaction separate: the local cleanup action does not cancel or modify the provider-side transaction.
• Blocked cleanup for Production-linked transactions and protected payment states.

Sale Lock Diagnostics — Lessons 194–195

• Added read-only diagnostic information for shared listing locks.
• Correlated missing lock-owner records with other purchase intents on the same listing that retain Escrow transaction IDs.
• Clarified that another intent containing an Escrow transaction reference is not necessarily the owner of the orphaned lock.
• Strengthened Flipnzee Analytics recovery safeguards so linked provider-transaction history blocks automatic or unverified lock removal.
• Improved recovery messages with intent ID, local status, transaction ID, environment, and last recorded event.

These changes are designed to reduce accidental release of a lock while a related provider transaction still requires investigation.

6. Public Buy Now Availability and Status — Lessons 196–197

Lesson 196 — Public Buy Now Under-Process State

• Checks the shared listing lock when rendering the public auction page.
• Shows the Buy Now link only when the auction and purchase conditions allow it.
• Replaces the clickable Buy Now action with a non-clickable Purchase Under Process status when a pending purchase intent or shared listing lock is present.
• Prevents the direct Buy Now form URL from presenting the purchase form while the listing remains locked.
• Retains server-side purchase protections instead of relying solely on frontend presentation.

Lesson 197 — Responsive Purchase-In-Progress Status

• Reworded the status to Purchase in progress.
• Places the status on its own line beneath the Buy Now price.
• Allows wrapping on narrow screens to prevent text from running across the row.
• Adds a subtle amber status treatment for better visibility.

This update changes presentation only. It does not manually clear locks, alter purchase-intent states, modify auction records, change Escrow settings, or create or approve transactions.

7. Compatibility and Data Safety

Throughout these changes, the project has retained its focus on preserving existing marketplace functionality while strengthening operational reliability.

• Existing auction, bidding, watchlist, and administration workflows remain part of the plugin.
• Existing linked transaction records are protected from unsafe manual deletion or status changes where applicable.
• Sandbox and Production transactions remain separate.
• Shared listing locks are not treated as proof that a sale has completed.
• Diagnostic checks do not automatically authorize a payment, approve funds, or transfer ownership.
• The manual ownership-transfer process remains separate from payment-status verification.
• The documented lesson updates do not introduce a database schema migration for the features described above.

Testing and Production Cautions

Before using the plugin for real-money transactions, verify the deployed package and test the complete workflow in an appropriate staging or Sandbox environment.

Recommended checks include:

1. Confirm public bidder anonymity and responsive bid-history rendering.
2. Verify that active auction cards and listing-specific links work correctly.
3. Test purchase requests, shared listing locks, cancellation, expiry, and recovery safeguards.
4. Verify webhook processing against the exact linked Escrow transaction.
5. Check scheduled reconciliation and its handling of failures or unsupported provider states.
6. Test administrator and buyer email notifications.
7. Verify Production API access and webhook registration independently of actual event delivery.
8. Confirm that the public Buy Now action is disabled while a purchase is genuinely in progress.
9. Verify that a closed or replaced auction does not leave behind an unexplained shared listing lock.
10. Confirm that no live transaction is created, changed, or approved unexpectedly during diagnostic or recovery operations.

Passing PHP syntax checks or ZIP integrity checks does not establish that every live WordPress, hosting, or Escrow scenario has been tested successfully.

Upgrade Instructions

1. Back up the WordPress database and existing plugin files.
2. Download the ZIP attached to the intended GitHub release.
3. Update Flipnzee Auctions through WordPress → Plugins → Add New Plugin → Upload Plugin.
4. Confirm the installed plugin version and that the administrator pages load correctly.
5. Review Escrow settings, webhook diagnostics, reconciliation health, and the Production readiness audit.
6. Inspect the public auction and Buy Now states before relying on the updated workflow.
7. Keep the Production transaction safety gate disabled until the required payment-lifecycle checks have been completed.

Release Information

• Plugin: Flipnzee Auctions
• Development coverage: Lesson 142 through Lesson 197
• Latest documented lesson: Lesson 197 — Responsive Purchase-In-Progress Status
• Plugin version in the uploaded Lesson 197 package: 1.12.24
• Previous release baseline: Lesson 142 — Robust Mobile Bid History Fix
• Repository: https://github.com/SplendidDigital/flipnzee-auctions
• Previous release: https://github.com/SplendidDigital/flipnzee-auctions/releases/tag/142

This release summary documents the cumulative changes in the intervening development period. Confirm the final ZIP contents and release tag before publishing it as a new GitHub release.