Lesson 74 Implementation: Displaying Professional Manual Payment Instructions on the Payment Page

After completing the payment gateway selection workflow in the previous lessons, the next improvement was making the payment page more informative for buyers who choose Manual Payment.

Previously, selecting Manual Payment only displayed a simple confirmation message. In this lesson, the payment page was enhanced to show a professional payment instruction section containing a unique payment reference, payment amount, current status, and important guidance for the buyer.


What We Built

The payment page now displays a dedicated Payment Instructions section whenever the buyer selects Manual Payment.

The section includes:

  • Unique payment reference number
  • Winning bid amount
  • Current payment status
  • Important payment instructions
  • Existing transaction details remain visible below

This provides buyers with the information they need before sending payment.


Step 1 – Detect Manual Payment Selection

After validating the form submission and selected gateway, the payment page checks which payment method the buyer selected.

switch ( $selected_gateway ) {

    case 'manual':

        // Display manual payment instructions.

        break;

    default:

        // Unsupported gateway.

        break;
}

This structure prepares the plugin for adding more gateways like Escrow.com, Stripe, PayPal and USDT in future lessons.


Step 2 – Create the Manual Payment Instruction Section

Inside the Manual Payment case, a dedicated container was added.

<div class="flipnzee-manual-payment">

    <h3>Payment Instructions</h3>

    <p>
        Thank you for choosing Manual Payment.
    </p>

    <p>
        Please use the transaction reference below when sending your payment.
    </p>

</div>

This creates a clear visual separation between payment instructions and transaction information.


Step 3 – Generate a Unique Payment Reference

Instead of using only the transaction ID, a formatted payment reference was generated.

<?php

echo esc_html(

    'FLIP-' . str_pad(

        $transaction->id,

        6,

        '0',

        STR_PAD_LEFT

    )

);

?>

Example:

FLIP-000001

Using a formatted reference looks much more professional and is easier for buyers to include in payment notes.


Step 4 – Display Important Payment Information

A table was created to display the essential payment information.

<table class="widefat striped">

<tr>

    <th>Reference Number</th>

    <td>

        <?php

        echo esc_html(
            'FLIP-' . str_pad(
                $transaction->id,
                6,
                '0',
                STR_PAD_LEFT
            )
        );

        ?>

    </td>

</tr>

<tr>

    <th>Amount</th>

    <td>

        <?php

        echo esc_html(
            number_format_i18n(
                $transaction->winning_bid,
                2
            )
        );

        ?>

    </td>

</tr>

<tr>

    <th>Status</th>

    <td>

        Awaiting Payment

    </td>

</tr>

</table>

This gives buyers an organized summary before making payment.


Step 5 – Add Important Buyer Instructions

An instruction list was added below the payment summary.

<h4>Important</h4>

<ul>

    <li>
        Include the reference number with your payment.
    </li>

    <li>
        Keep proof of payment for verification.
    </li>

    <li>
        Your transaction will be reviewed before ownership transfer.
    </li>

</ul>

These reminders help reduce payment mistakes and prepare buyers for the verification process.


Final Result

After selecting Manual Payment, buyers now see:

  • Professional payment instruction heading
  • Payment reference number
  • Winning amount
  • Awaiting payment status
  • Important payment reminders
  • Original transaction details below

The payment page now feels much closer to a production-ready marketplace instead of a placeholder page.


What I Learned

This lesson demonstrated that payment pages should do much more than simply display transaction details. Buyers need clear instructions, a recognizable payment reference, and confirmation of the amount and status before making payment.

Generating a formatted reference number and presenting information in a structured table significantly improves usability and prepares the payment workflow for future enhancements.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:


What’s Next?

In Lesson 75, we will build the Payment Proof Upload feature, allowing buyers to submit proof of payment after completing a manual transfer. This will move the Flipnzee payment workflow one step closer to a complete marketplace transaction process.

Lesson 72 Implementation: Building a Future-Ready Payment Gateway Selection Interface

As the Flipnzee Auctions plugin continues to evolve into a professional website marketplace, one of the most important architectural decisions is how payment gateways will be integrated. Rather than hardcoding a single payment provider, this lesson introduces a flexible gateway selection system that can easily support multiple payment methods in the future.

Although no real payment gateways are connected yet, the plugin now provides a scalable framework for adding Escrow.com, Stripe, PayPal, Razorpay, cryptocurrency payments, and other providers without redesigning the payment page.


Why This Lesson Was Needed

Until the previous lesson, buyers could only see the transaction details and a placeholder payment gateway.

While functional, that approach wasn’t scalable. Every time a new payment provider was added, the payment page would need to be rewritten.

Instead, the payment page should simply ask:

“Which payment gateways are currently available?”

The Payment Manager should answer that question.

This separation of responsibilities makes the code easier to maintain and extend.


Objectives

In this lesson we:

  • Centralized payment gateway definitions
  • Added a helper method to retrieve available gateways
  • Introduced Escrow.com as the planned primary marketplace payment method
  • Generated the payment method list dynamically
  • Displayed future gateways as disabled
  • Added a disabled “Continue to Payment” button
  • Prepared the plugin for future payment gateway integrations

Step 1 – Centralizing Available Payment Gateways

Inside:

includes/class-payment-manager.php

a new helper method was introduced:

/**
 * Get available payment gateways.
 *
 * @return array
 */
public static function get_available_gateways() {

    return array(

        'escrow' => array(
            'label'   => 'Escrow.com (Recommended)',
            'enabled' => false,
        ),

        'manual' => array(
            'label'   => 'Manual Payment',
            'enabled' => true,
        ),

        'stripe' => array(
            'label'   => 'Stripe',
            'enabled' => false,
        ),

        'paypal' => array(
            'label'   => 'PayPal',
            'enabled' => false,
        ),

        'razorpay' => array(
            'label'   => 'Razorpay',
            'enabled' => false,
        ),

        'crypto' => array(
            'label'   => 'USDT Cryptocurrency',
            'enabled' => false,
        ),

    );

}

Instead of hardcoding gateway names inside the payment page, all available gateways are now managed from a single location.


Step 2 – Loading Gateways in the Payment Page

After validating the transaction, the payment page now requests the available gateways from the Payment Manager.

$gateways = Flipnzee_Payment_Manager::get_available_gateways();

This keeps the page independent from payment logic and allows new gateways to be introduced without modifying the frontend.


Step 3 – Rendering Gateway Options Dynamically

The payment page now loops through the available gateways to generate the interface.

<h3>Select Payment Method</h3>

<div class="flipnzee-payment-gateways">

<?php foreach ( $gateways as $gateway_id => $gateway ) : ?>

    <p>

        <label>

            <input
                type="radio"
                name="payment_gateway"
                value="<?php echo esc_attr( $gateway_id ); ?>"
                <?php checked( $gateway['enabled'] ); ?>
                <?php disabled( ! $gateway['enabled'] ); ?>
            >

            <?php echo esc_html( $gateway['label'] ); ?>

            <?php if ( ! $gateway['enabled'] ) : ?>

                <em>(Coming Soon)</em>

            <?php endif; ?>

        </label>

    </p>

<?php endforeach; ?>

</div>

This approach automatically displays every configured gateway without manually writing HTML for each payment provider.


Step 4 – Adding a Checkout Placeholder

Since actual payment processing has not yet been implemented, a disabled button was added.

<p class="flipnzee-payment-actions">

    <button
        type="button"
        class="button button-primary"
        disabled
    >
        Continue to Payment (Coming Soon)
    </button>

</p>

The button clearly communicates that payment processing will be introduced in a future lesson while maintaining a professional checkout layout.


Why Escrow.com Appears First

During implementation, the payment architecture was adjusted to better reflect Flipnzee’s purpose.

Instead of treating Stripe or PayPal as the primary payment method, the gateway list now starts with:

  • Escrow.com (Recommended)
  • Manual Payment
  • Stripe
  • PayPal
  • Razorpay
  • USDT Cryptocurrency

Since Flipnzee is designed as a marketplace for buying and selling websites, Escrow.com is expected to become the primary payment solution once its API integration is implemented.

Until then, it remains disabled and marked as “Coming Soon.”


Testing

After implementing the changes:

  • The Payment page continued displaying transaction information correctly.
  • Payment gateways were loaded dynamically.
  • Manual Payment appeared as the only selectable option.
  • Future gateways appeared disabled.
  • Escrow.com was displayed as the recommended marketplace payment solution.
  • The “Continue to Payment” button appeared in a disabled state.

No PHP syntax errors were encountered during testing.


Lessons Learned

This lesson reinforced several important software design principles:

  • Business logic should be separated from presentation logic.
  • Payment providers should be managed centrally.
  • Dynamic rendering reduces future maintenance.
  • Building a scalable architecture early simplifies later integrations.
  • Placeholder interfaces help guide future development while keeping the application stable.

Current Progress

The Flipnzee Auctions plugin now includes:

  • Auction management
  • Transaction creation
  • Purchase history
  • Individual purchase details
  • Dedicated payment page
  • Payment gateway architecture
  • Dynamic gateway selection interface
  • Escrow-ready payment framework

Although real payment processing has not yet been added, the plugin now has a solid architectural foundation that will make future integrations significantly easier.

Download Source Code

Download the starting version of the plugin before the lesson:

Download the completed version after this lesson:


Next Lesson

In Lesson 73, we’ll move beyond the static gateway list and begin building the actual payment flow by allowing buyers to submit their selected payment method, validating their choice, storing it with the transaction, and preparing the plugin to route users toward the appropriate payment handler. This will transform the current placeholder interface into the first stage of a working checkout process.

Lesson 71: Preparing the Payment Gateway Architecture for Future Integrations

Introduction

With a dedicated buyer payment page now operational, the next step is to prepare the plugin for actual payment gateway integration. Rather than immediately connecting to a provider like Stripe or PayPal, it is better to first build a clean, reusable architecture that allows multiple payment gateways to be added later without rewriting the auction workflow.

In this lesson, we’ll introduce a centralized payment manager that becomes responsible for generating payment requests, validating transactions, and routing buyers to the selected payment gateway. Although no real payment processing will occur yet, this lesson lays the foundation for supporting Stripe, PayPal, Razorpay, cryptocurrency payments, and additional gateways in future releases.


Learning Objectives

By the end of this lesson, you will learn how to:

  • Design a scalable payment architecture.
  • Separate payment logic from page rendering.
  • Create a dedicated Payment Manager class.
  • Validate transactions before initiating payment.
  • Prepare the plugin for multiple payment gateways.
  • Keep the codebase modular and maintainable.

Why This Lesson Is Important

A common mistake is embedding payment code directly inside the payment page shortcode. That approach quickly becomes difficult to maintain when additional gateways are introduced.

Instead, we’ll separate responsibilities:

  • Payment Page → displays information to the buyer.
  • Payment Manager → handles payment processing logic.
  • Gateway Classes (future lessons) → communicate with Stripe, PayPal, Razorpay, crypto wallets, etc.

This layered architecture follows good software engineering principles and makes the plugin easier to extend.


What We’ll Build

At the end of this lesson, the payment flow will look like this:

Buyer
   │
   ▼
Payment Page
   │
   ▼
Payment Manager
   │
   ▼
Selected Gateway
   │
   ├── Stripe (future)
   ├── PayPal (future)
   ├── Razorpay (future)
   └── Crypto (future)

Planned Implementation

During this lesson we will:

Step 1

Create

includes/class-payment-manager.php

Step 2

Move payment-related business logic into this class.


Step 3

Add a function to validate a transaction before payment begins.


Step 4

Create a placeholder method that returns the payment URL for the selected gateway.


Step 5

Update the payment page so it requests payment information from the Payment Manager instead of containing all business logic itself.


Step 6

Register and load the new class using the plugin loader.


Expected Folder Structure

includes/

class-payment-manager.php
class-payment-page.php
class-transaction-manager.php
class-my-purchases.php
class-my-purchase-details.php

Benefits

After completing this lesson, the plugin will have:

  • Better separation of concerns.
  • Easier maintenance.
  • Cleaner code.
  • Support for multiple gateways.
  • Simpler testing.
  • Future-proof architecture.

Skills You’ll Learn

  • Object-Oriented Programming (OOP)
  • Separation of Concerns
  • WordPress Plugin Architecture
  • Business Logic vs Presentation
  • Designing Extensible Systems
  • Preparing APIs for Third-Party Integrations

What Comes Next?

With the Payment Manager in place, the next lessons can focus on implementing real payment gateways without modifying the auction or transaction workflow.

A possible roadmap is:

  • Lesson 72: Creating the Payment Manager and Transaction Validation
  • Lesson 73: Adding a Gateway Interface and Default Gateway Selection
  • Lesson 74: Integrating the First Payment Gateway (e.g., Stripe or Razorpay Sandbox)
  • Lesson 75: Handling Payment Callbacks and Updating Transaction Status

By first building the architecture rather than jumping straight into gateway code, the Flipnzee Auctions plugin will remain clean, scalable, and capable of supporting multiple payment providers as the marketplace grows.

Lesson 70: Building the Payment Page Foundation for Completed Auctions


Introduction

After successfully completing the auction lifecycle in the previous lessons, the next logical step is to allow auction winners to complete their purchase.

By the end of Lesson 69, Flipnzee Auctions was already capable of:

  • Creating and managing auctions
  • Automatically closing expired auctions
  • Determining the winning bidder
  • Recording transactions
  • Displaying transactions in the WordPress admin
  • Showing buyers their purchases
  • Displaying purchase details
  • Providing a Pay Now button for unpaid purchases

Although the Pay Now button existed, clicking it resulted in a 404 Page Not Found error because the payment page itself had not yet been implemented.

Lesson 70 focuses on solving this problem by creating the foundation of the payment workflow.


Why This Lesson Is Important

Every online marketplace requires a secure payment flow after an auction ends.

Instead of jumping directly into integrating a payment gateway like Stripe or PayPal, it is better to build the underlying architecture first.

This lesson concentrates on creating the page that receives the transaction, validates it, and displays the purchase before any actual payment processing takes place.

Building the foundation first makes later gateway integration much cleaner and easier.


Objectives

In this lesson we will:

  • Create the Payment Page shortcode
  • Build a dedicated Payment Page class
  • Register the shortcode with the plugin loader
  • Display transaction information
  • Validate transaction IDs
  • Handle missing or invalid transactions gracefully
  • Prepare the page for future payment gateway integration

Planned Workflow

To keep development safe and manageable, this lesson will be completed in several small checkpoints.

Checkpoint 1

Create the Payment Page class.


Checkpoint 2

Register the payment shortcode.


Checkpoint 3

Display transaction information.


Checkpoint 4

Handle invalid transactions.


Checkpoint 5

Test the page using existing auction transactions.


Checkpoint 6

Commit the completed lesson to Git.


Expected User Flow

Auction Ends
        │
        ▼
Winner Determined
        │
        ▼
Transaction Created
        │
        ▼
Buyer Visits "My Purchases"
        │
        ▼
Clicks "Pay Now"
        │
        ▼
Payment Page Opens
        │
        ▼
Transaction Validated
        │
        ▼
Ready for Payment Gateway

Development Strategy

One important improvement in our workflow is the use of small Git checkpoints.

At the beginning of this lesson, the entire project was restored to the stable Lesson 69 state and committed to GitHub. This provides a reliable rollback point before introducing the payment workflow.

Rather than implementing the complete payment system in one attempt, each stage will be developed, tested, and committed separately. This incremental approach reduces risk, simplifies debugging, and ensures that any issues can be isolated without affecting previously completed features.


What We’ll Build Next

By the end of Lesson 70, clicking the Pay Now button should no longer produce a 404 error. Instead, buyers will be taken to a dedicated payment page displaying the transaction details, confirming the amount due, and preparing the auction purchase for payment processing in the upcoming lessons.


Next Lesson: Implementing the Payment Page and Connecting the “Pay Now” Workflow.

Lesson 69: Build the Buyer Payment Page


Why This Lesson?

A buyer can now:

  • Browse auctions.
  • Place bids.
  • Win an auction.
  • View purchases.
  • View transaction details.

The next logical step is allowing the buyer to proceed to payment.

Although payment gateways (Stripe, Razorpay, PayPal, etc.) will be integrated later, we should first build the payment page and workflow.


What We Will Build

A new frontend shortcode:

[flipnzee_payment]

This page will display:

Payment

Auction:
Wpnzee.com

Transaction ID:
#2

Winning Bid:
₹55,555,609.00

Status:
Pending

------------------------------------------------

Proceed to Payment

Initially, the button will simply display a placeholder message.

In later lessons it will connect to:

  • Stripe
  • Razorpay
  • PayPal

without redesigning the page.


New Workflow

My Purchases
      │
      ▼
View Details
      │
      ▼
Purchase Details
      │
      ▼
Proceed to Payment

Features

During this lesson we will:

  • Create a Payment shortcode.
  • Verify the buyer owns the transaction.
  • Retrieve transaction details.
  • Display payment summary.
  • Show a “Proceed to Payment” button.
  • Hide the button once the transaction is already marked as Paid.

Files Expected to Change

includes/class-payment.php
includes/class-shortcodes.php
flipnzee-auctions.php
includes/class-my-purchase-details.php

New Shortcode

[flipnzee_payment]

Payment Summary

The page will display:

FieldExample
Transaction ID#2
AuctionWpnzee.com
Winning Bid₹55,555,609.00
StatusPending

Button Behaviour

If:

Status = Pending

display

Proceed to Payment

If:

Status = Paid

display

✓ Payment Received

This provides immediate visual feedback and prevents duplicate payment attempts.


Skills You’ll Learn

During this lesson you’ll learn how to:

  • Build another reusable frontend shortcode.
  • Reuse secure transaction validation.
  • Conditionally display interface elements.
  • Create a payment-ready architecture.
  • Design pages that can later integrate with payment gateways without major refactoring.

Expected Outcome

By the end of Lesson 69, Flipnzee Auctions will have a complete post-purchase navigation flow:

Auction
      │
      ▼
Bid
      │
      ▼
Winner
      │
      ▼
My Purchases
      │
      ▼
Purchase Details
      │
      ▼
Payment Page

Although no real payment will be processed yet, the platform will be structurally ready for payment gateway integration in subsequent lessons.


Why this is a good next step

Instead of postponing payment until the end of development, we’re building the user journey in the same order a real buyer experiences it. When you later integrate Stripe, Razorpay, or another gateway, you’ll only need to replace the placeholder button action rather than redesign the buyer workflow. This keeps the development incremental and makes Version 1 feel complete from a user’s perspective.

Lesson 66: Building a Transaction Details Page for Flipnzee Auctions


Overview

In previous lessons, we built a complete transaction workflow:

  • Auctions close automatically.
  • Winners are determined.
  • Transactions are created automatically.
  • Administrators can view transactions.
  • Transaction statuses can be updated.

However, administrators still cannot inspect an individual transaction in detail.

In this lesson, we’ll build a dedicated Transaction Details page where administrators can view every aspect of a completed auction before moving on to escrow, payment, or ownership transfer.


What You Will Learn

In this lesson you will learn how to:

  • Create an admin details page.
  • Read a single transaction securely.
  • Display auction information.
  • Display buyer and seller information.
  • Display listing information.
  • Display winning bid information.
  • Display transaction timeline.
  • Prepare the page for escrow integration.

Why This Lesson Matters

Imagine receiving an email from a buyer asking:

“Has my payment been received?”

Currently an administrator would need to search several database tables.

Instead, we’ll provide a dedicated transaction page showing everything in one place.


Current Workflow

Auction

↓

Winner

↓

Transaction

↓

Transactions Table

New Workflow

Auction

↓

Winner

↓

Transaction

↓

Transactions Table

↓

Transaction Details

What We’ll Build

Each transaction will have a View action.

Example:

ID      Status

31      Pending

View

Clicking View opens:

Transaction #31

Auction
-----------------------------------
Auction ID
Listing
Winning Bid

Buyer
-----------------------------------
Username
Email

Seller
-----------------------------------
Username
Email

Status
-----------------------------------
Pending

Created

Last Updated

Files We’ll Modify

New

admin/class-admin-transaction-details.php

Modify

admin/class-admin-transactions.php

Modify

admin/class-transactions-table.php

Reuse

includes/class-transaction-manager.php

Features

Step 1

Create Transaction Details page.


Step 2

Register submenu page.


Step 3

Add View action.


Step 4

Load transaction.


Step 5

Display buyer details.


Step 6

Display seller details.


Step 7

Display auction details.


Step 8

Display transaction status.


Step 9

Display timestamps.


Step 10

Prepare escrow section placeholder.


Example Page

------------------------------------------------

Transaction #12

Status
Pending

-----------------------------------------------

Auction

Auction ID: 31

Listing:
PremiumDomain.com

Winning Bid:
₹55,555,609

-----------------------------------------------

Buyer

Username:
John

Email:
[email protected]

-----------------------------------------------

Seller

Username:
Rajeev

Email:
[email protected]

-----------------------------------------------

Created

2026-07-06 14:25

Updated

2026-07-06 14:31

------------------------------------------------

Future Escrow Section

The page will intentionally leave space for:

Escrow Provider

Payment Status

Escrow ID

Release Funds

Release Domain

Complete Transaction

These features will be implemented in later lessons without redesigning the page.


Skills You’ll Practice

  • WordPress admin pages
  • Secure URL parameters
  • Database lookups
  • WordPress user functions
  • Data presentation
  • Preparing for escrow integration
  • Clean admin UI design

Difficulty Level

Intermediate

This lesson combines custom admin pages, database retrieval, and structured data presentation. It also establishes the administrative workflow that will support escrow services, payment processing, and domain or website transfers in future lessons.


Final Thoughts

Lesson 66 marks another important milestone in the Flipnzee Auctions plugin. Instead of treating transactions as simple database records, administrators will be able to inspect every completed auction from a single screen. This improves usability, simplifies support, and creates the ideal foundation for integrating escrow providers, payment gateways, email notifications, and ownership transfer workflows as the plugin moves closer to powering live auctions on Flipnzee.com.

Lesson 64: Build a Transaction Management Dashboard in WordPress Admin


Objective

Create a dedicated Transactions page in the WordPress admin where administrators can monitor every completed auction transaction.

This will become the operational dashboard before adding escrow integration.


What We Will Build

A new admin menu:

Flipnzee Auctions
├── Auctions
├── Add Auction
├── Activity Log
├── Transactions   ← NEW

The page will display something like:

IDAuctionListingSellerBuyerWinning BidStatusCreated
131491RajeevRajeev$55,555,609PendingToday

Why This Lesson Matters

Right now:

  • Auctions close automatically ✅
  • Winner is determined ✅
  • Transaction is created ✅

But administrators cannot actually see or manage transactions.

A transaction dashboard is the natural bridge before adding:

  • Escrow integration
  • Payment processing
  • Buyer/Seller confirmation
  • Domain transfer workflow
  • Status updates

Files We’ll Modify

New

admin/class-transactions-table.php

A WordPress list table for transactions.


New

admin/class-admin-transactions.php

Renders the Transactions page.


Modify

admin/class-admin.php

Register the new submenu.


Reuse

includes/class-transaction-manager.php

Read transaction data from the database.


Features

1. Transactions Table

Display:

  • Transaction ID
  • Auction ID
  • Listing ID
  • Seller
  • Buyer
  • Winning Bid
  • Status
  • Created Date

2. Pagination

Support large numbers of transactions.


3. Search

Search by:

  • Auction ID
  • Listing ID
  • Buyer
  • Seller

4. Status Filter

Dropdown:

All
Pending
Escrow
Completed
Cancelled
Refunded

5. Sorting

Allow sorting by:

  • Date
  • Winning Bid
  • Status

6. Future Ready

We’ll design the table so adding action buttons later is easy:

View
Mark Escrow Received
Mark Completed
Cancel

Those buttons won’t do anything yet—they’ll be implemented in later lessons.


What We’ll Learn

During this lesson you’ll practice:

  • Creating another WP_List_Table
  • Reading custom database tables
  • Pagination
  • Searching
  • Sorting
  • Filtering
  • Secure admin pages
  • Preparing for escrow workflows

Expected Result

The admin will have a professional Transactions dashboard similar to WordPress Posts or Users.

Example:

-------------------------------------------------------------
 Transactions

 ID   Auction  Buyer      Seller     Winning Bid     Status
-------------------------------------------------------------
 1      31     Rajeev     Rajeev      $55,555,609    Pending
 2      32     Alice      Bob         $7,500         Completed
 3      33     John       Mary        $2,300         Escrow
-------------------------------------------------------------

Why This Is the Right Next Step

This lesson doesn’t just add another admin screen—it creates the control center for everything that happens after an auction ends. Once this dashboard exists, integrating an escrow provider becomes much simpler because every transaction will have a visible lifecycle (Pending → Escrow → Completed).

After Lesson 64, we’ll be in an excellent position to begin the escrow integration itself, keeping your focus on making Flipnzee.com ready to host real auctions.

Lesson 63: Automatically Create Transactions When an Auction Ends Using WordPress Action Hooks

Overview

In the previous lesson, we built the Transaction Manager and created the wp_flipnzee_transactions table. However, transactions are still created manually. The next logical step is to connect the Auction Manager with the Transaction Manager.

Rather than calling the Transaction Manager directly from the Auction Manager, we’ll use one of WordPress’ most powerful features—Action Hooks. This creates a loosely coupled, event-driven architecture where different components communicate through events instead of depending on each other directly.

By the end of this lesson, whenever an auction winner is determined, the plugin will automatically create a pending transaction without modifying the core auction logic.


What You Will Learn

In this lesson you will learn how to:

  • Understand event-driven programming in WordPress.
  • Create a custom WordPress action hook.
  • Pass auction data through an action hook.
  • Listen for custom actions.
  • Automatically create transactions after an auction closes.
  • Reduce coupling between plugin components.
  • Build an extensible architecture for future escrow integrations.

Why This Improvement Matters

Suppose the Auction Manager directly inserts a transaction into the database.

Today that may seem fine.

Tomorrow you may also want to:

  • Send buyer emails.
  • Send seller emails.
  • Start escrow.
  • Notify administrators.
  • Trigger webhooks.
  • Generate invoices.
  • Award badges.
  • Push data to an external CRM.

If every feature is added inside the Auction Manager, the class quickly becomes difficult to maintain.

Using WordPress hooks solves this problem elegantly.

Instead of saying:

“Create a transaction.”

the Auction Manager simply says:

“An auction has ended.”

Any other class can decide whether it wants to respond.


Architecture Before Lesson 63

Auction Manager
      │
      ▼
Determine Winner

Architecture After Lesson 63

Auction Manager
      │
      ▼
do_action()

      │
      ▼

Transaction Manager

      │
      ▼

Create Transaction

Later we can attach even more listeners:

Auction Manager

      │

do_action()

      │
      ├────────► Transaction Manager
      ├────────► Email Manager
      ├────────► Escrow Manager
      ├────────► Notification Manager
      └────────► REST API

This is exactly how many mature WordPress plugins are designed.


What Will Be Implemented

During this lesson we will:

Step 1

Fire a custom action when a winner is determined.


Step 2

Create a listener inside the Transaction Manager.


Step 3

Automatically insert a new transaction.


Step 4

Log transaction creation in the Activity Log.


Step 5

Test the complete workflow.


Expected Result

Before Lesson 63:

Auction Ends

↓

Winner Selected

↓

Nothing Else Happens

After Lesson 63:

Auction Ends

↓

Winner Selected

↓

WordPress Action Fired

↓

Transaction Created

↓

Activity Logged

Files That Will Be Modified

  • includes/class-auction-manager.php
  • includes/class-transaction-manager.php
  • includes/class-activity-log.php

No database changes are required.


Skills You’ll Practice

  • WordPress Action Hooks
  • Custom Events
  • Loose Coupling
  • Event-Driven Programming
  • Clean Plugin Architecture
  • Object-Oriented WordPress Development

Difficulty Level

Intermediate

This lesson introduces one of the most important architectural concepts in WordPress development. Understanding custom action hooks will help you build plugins that are easier to extend, maintain, and integrate with future features such as escrow services, payment gateways, and notification systems.


Final Thoughts

Lesson 63 represents a significant shift in the design of the Flipnzee Auctions plugin. Instead of tightly connecting the Auction Manager with every future component, we will use WordPress’ hook system to broadcast auction events and allow independent classes to respond as needed.

This event-driven approach provides a solid foundation for the remaining roadmap, including escrow integration, payment workflows, buyer and seller notifications, and third-party integrations, while keeping the codebase clean and modular.

Lesson 62: Building the Transaction Manager Foundation for Flipnzee Auctions

With automatic winner determination now complete, the Flipnzee Auctions plugin has reached an important milestone. Every completed auction now has a confirmed winner and a final bid amount.

The next logical step is not to integrate directly with an escrow service. Instead, we first need to build a solid transaction management layer that will act as the bridge between completed auctions and future payment or escrow workflows.

In this lesson, we will create the Transaction Manager Foundation, providing the architecture that will support escrow providers, payment gateways, notifications, and transaction tracking in future lessons.


Why Not Integrate Escrow Immediately?

When developing marketplace software, it is tempting to connect directly to an escrow provider as soon as a winner has been selected.

However, this creates tight coupling between auction logic and payment processing.

Instead, professional marketplace platforms introduce a separate transaction layer.

The workflow becomes:

Auction
      ↓
Winner Determined
      ↓
Transaction Created
      ↓
Escrow
      ↓
Ownership Transfer
      ↓
Transaction Completed

This separation makes the system easier to maintain, extend, and test.


Why Introduce a Transaction Manager?

The Auction Manager should remain responsible only for auction-related operations such as:

  • creating auctions,
  • activating auctions,
  • closing auctions,
  • determining winners.

It should not become responsible for:

  • escrow,
  • payment processing,
  • notifications,
  • transaction history.

Those responsibilities belong to a dedicated Transaction Manager.

Following the Single Responsibility Principle (SRP) keeps each class focused on one area of responsibility.


What We Will Build

During this lesson we will create a brand-new class:

includes/class-transaction-manager.php

This class will become responsible for managing every transaction that occurs after an auction has completed.

Initially, it will provide methods such as:

  • Create Transaction
  • Retrieve Transaction
  • Update Transaction Status

Additional capabilities will be added in later lessons.


Creating a Transactions Table

To support transaction management, a new database table will be introduced:

wp_flipnzee_transactions

Each completed auction will eventually create a corresponding transaction record.

The table is designed to store information such as:

  • Transaction ID
  • Auction ID
  • Listing ID
  • Seller ID
  • Buyer ID
  • Winning Bid
  • Transaction Status
  • Creation Date
  • Last Updated Date

Having a dedicated table keeps transaction information separate from auction data while allowing both systems to remain connected.


Benefits of a Separate Transaction Layer

This design offers several important advantages.

Clean Architecture

Each manager class performs one job.

Auction Manager manages auctions.

Bid Manager manages bids.

Transaction Manager manages transactions.

Future managers can handle:

  • Escrow
  • Notifications
  • Payments
  • Emails

without modifying the auction engine.


Easier Escrow Integration

Whether Flipnzee eventually integrates with:

  • Escrow.com,
  • another escrow provider,
  • manual escrow,
  • or an in-house payment system,

all of them can simply interact with the Transaction Manager rather than modifying auction logic.


Improved Maintainability

As new features are added, developers will know exactly where transaction-related code belongs.

Instead of one extremely large manager class, the plugin grows through focused, modular components.


Preparing for Future Lessons

This architectural foundation prepares the plugin for several major features.

Upcoming lessons will build on the Transaction Manager by adding:

  • Automatic transaction creation
  • Winner notifications
  • Seller notifications
  • Transaction status updates
  • Escrow integration
  • Payment tracking
  • Ownership transfer workflow

Each feature will plug into the Transaction Manager without requiring major changes to the existing auction system.


What You’ll Learn

In this lesson, you will learn how to:

  • Design a scalable WordPress plugin architecture.
  • Apply the Single Responsibility Principle.
  • Create a dedicated database table for transactions.
  • Build a reusable Transaction Manager.
  • Prepare a plugin for future integrations.
  • Separate business logic into modular components.

Why the Roadmap Was Revised

Originally, the plan was to create transactions directly inside the Auction Manager.

During implementation, it became clear that this would gradually turn the Auction Manager into a very large class responsible for multiple unrelated tasks.

The architecture was therefore improved before the feature was completed.

Instead of tightly coupling auctions with transactions, the project now introduces a dedicated Transaction Manager that communicates with the rest of the plugin through well-defined methods and WordPress actions.

This approach closely follows the modular architecture used throughout WordPress itself.


Final Thoughts

As software projects grow, architecture becomes just as important as functionality.

Introducing a Transaction Manager may not produce an immediately visible feature for users, but it establishes a clean, scalable foundation that will support every post-auction process in the future.

By investing in a well-structured architecture now, the Flipnzee Auctions plugin is better prepared for secure escrow integration, transaction tracking, and the complete marketplace workflow that will power Flipnzee.com.


Next Lesson

In Lesson 63, we will connect the Auction Manager and the Transaction Manager using WordPress action hooks, allowing transactions to be created automatically whenever a winner is determined—without tightly coupling the two classes.

Lesson 61: Automatically Determine the Winning Bidder When an Auction Ends

One of the most important milestones in the Flipnzee Auctions plugin is moving from simply accepting bids to automatically determining the winner once an auction expires.

Until now, the plugin has allowed visitors to place bids, displayed the highest bidder, tracked activity, and automatically closed expired auctions. However, once an auction ended, there was no definitive step that officially declared a winner.

In this lesson, we will build the logic that identifies the highest valid bidder and records them as the auction winner.


Why This Feature Matters

An auction is only complete when a winner has been determined.

Without this feature:

  • administrators must manually inspect bid history,
  • mistakes can occur,
  • notifications cannot be automated,
  • escrow cannot begin,
  • ownership transfer cannot proceed.

Automatically determining the winner removes manual work while increasing trust in the auction platform.


What We Will Build

By the end of this lesson, the plugin will:

  • detect when an auction closes,
  • retrieve all valid bids,
  • determine the highest bidder,
  • resolve ties fairly,
  • save the winning bidder,
  • save the winning bid amount,
  • prepare the auction for the escrow workflow.

Planned Database Changes

The auction record will be enhanced with dedicated winner information.

Examples include:

  • Winner User ID
  • Winning Bid
  • Winning Time
  • Auction Result Status

This allows the plugin to remember the winning bidder even after additional administrative actions are taken.


Winner Selection Rules

The plugin should follow a clear and transparent process.

For example:

  1. Auction expires.
  2. Retrieve all bids.
  3. Ignore invalid bids.
  4. Sort by highest bid.
  5. If multiple bids have the same amount, choose the earliest one.
  6. Store the winner.
  7. Mark the auction as completed.

This ensures every auction follows the same rules.


Preparing for Escrow Integration

Determining the winner is the foundation for the next major milestone.

Once a winner exists, the plugin can automatically:

  • notify the buyer,
  • notify the seller,
  • initiate an escrow transaction,
  • display payment instructions,
  • begin ownership transfer.

Without a confirmed winner, none of these workflows can begin.


Administrator Benefits

Instead of manually checking bid history, administrators will immediately know:

  • who won,
  • the winning amount,
  • when the winning bid was placed,
  • whether the auction completed successfully.

This reduces administration time and minimizes disputes.


Future Enhancements

The winner information introduced in this lesson will later support features such as:

  • Winner email notifications
  • Seller notifications
  • Escrow integration
  • Transaction tracking
  • Buyer dashboard
  • Seller dashboard
  • Completed auction history
  • Marketplace reputation system

What You’ll Learn

In this lesson, you will learn how to:

  • query auction bids efficiently,
  • determine the highest valid bid,
  • handle tie-breaking rules,
  • update auction records,
  • prepare auctions for post-auction workflows,
  • design software that supports future business processes.

Final Thoughts

Automatically determining the winning bidder marks the transition from a bidding system to a complete auction platform. It establishes a trusted and repeatable process for ending auctions fairly and creates the foundation for escrow, notifications, and secure ownership transfer.

In Lesson 62, we will build the Auction Completion Workflow, automatically transitioning completed auctions into the next stage of the transaction lifecycle.