GeoDirectory Booking - WordPress Plugin

A Setup Guide to GeoDirectory Booking for a Booking Directory

In this guide, GeoDirectory Booking is treated as the Booking Marketplace add-on for GeoDirectory: it brings date-based property bookings, marketplace commissions, GetPaid payments, an owner wallet, and booking form blocks to a WordPress directory listing page. It is not a standalone all-purpose calendar for any website. It is part of the GeoDirectory ecosystem, so the key is to connect the directory, post type, listing fields, listing template, and payment model correctly.

Below, we cover more than just installing and activating the plugin. We will walk through the full path from preparing the directory to validating a real-world flow: the owner publishes a property, enables bookings, sets pricing and rules, the guest selects dates, the system holds the unpaid order, and the administrator can see both the booking and the commission. We will also look at rooms, parameter-based search, the GetPaid wallet, common issues, and cases where a different solution may be the better fit.

This guide is written for a site owner, webmaster, or developer who already understands the directory use case: hotels, apartments, vacation rentals, venues, rooms, small B&Bs, and local rentals. If your listings are time-based services such as consultations or hourly sessions, proceed carefully: GeoDirectory has a separate Appointments track for those scenarios, while GeoDirectory Booking is better suited to day-based and overnight property bookings.

What Problem the Plugin Solves in the GeoDirectory Ecosystem

GeoDirectory itself builds the directory: post types, property cards, maps, search, and add/edit listing pages. GeoDirectory Booking adds a booking layer on top of that directory. The property owner gets the ability to sell dates, and the site can retain a commission or service fee. That is why it is best understood as a rental marketplace module inside a directory, not as a simple availability calendar.

The key difference from a typical booking plugin is that the reservation is tied directly to a GeoDirectory listing. The user does not create a separate WooCommerce product and manually connect it to a directory entry. They work with the listing itself, while the administrator adds the required blocks to the listing template: the booking form, availability calendar, owner settings button, and order-view widgets.

The official documentation describes the typical use case as a marketplace for properties where owners can sell full-day bookings and the platform can charge a commission or an additional service fee. In practice, this works well for sites that list vacation rentals, guesthouses, rooms, units in a small hotel, leisure properties, campgrounds, and similar stays where the guest selects a date range rather than a specific hourly slot.

At the same time, you need to understand the product boundaries. GeoDirectory Booking does not replace a full hotel management system with channel management, complex synchronization with external platforms, and deep accounting features. Its strength is the combination of directory listings + bookings + commissions + listing owner. If the project is centered on a directory and geosearch, the product fits its niche well.

Where the Plugin Makes the Most Sense

GeoDirectory Booking is worth considering when the site is already built around GeoDirectory, or when you need a directory with search by location, category, and custom fields. In that case, booking becomes an extension of the property card rather than a separate store. Typical examples include:

• An apartment or small home rental directory where owners manage their own available dates.
• A guesthouse marketplace with rooms, where a single listing can include multiple accommodation units.
• A niche local directory where the map, neighborhood, filters, and the ability to place a reservation directly on the property page all matter.
• A project where the administrator wants to charge a booking commission or add a service fee.
• A directory where listing owners need to see their bookings and balances without entering the main WordPress admin area.

When Not to Start with GeoDirectory Booking

If you only need a single property without a directory, such as one apartment with a booking calendar, a specialized hotel or rental plugin is often the simpler choice. If your main use case is time-based services such as medical appointments, lessons, consultations, service providers, or classes, you should compare Booking Marketplace carefully against GeoDirectory's separate Appointments line. And if the project is already fully built around WooCommerce products, it may be more logical to look at WooCommerce-focused solutions.

Practical takeaway: GeoDirectory Booking shines where the listing, location, filters, and property owner matter just as much as the booking form itself.

What to Check Before Installation and Why It Matters

Before installing, it is not enough to ask whether WordPress is supported. GeoDirectory Booking has several dependencies and architectural requirements: GeoDirectory must already be installed, the core version must be compatible, the post type must be configured correctly, listing templates must be in place, GetPaid handles payments, a wallet is needed for payouts, and additional extensions may be required depending on the setup. If you skip this step, the plugin may install successfully, but users may never see the booking form, or owners may be unable to access booking settings.

The official Booking Marketplace page lists WordPress, GeoDirectory core, and PHP requirements. The GeoDirectory installation documentation also recommends choosing the theme first and then activating GeoDirectory, because changing themes later may require you to rework menus, widgets, or rerun the setup wizard. On a booking site, this matters even more: the form and calendar blocks must be placed in the correct listing template, or the guest simply will not see a path to book.

Minimum Product Preparation

Before installation, prepare not only the technical environment but also the booking model. For a simple directory, a category and address may be enough to start, but bookings require you to define in advance which fields guests and owners will need. For example, in an accommodation use case this may include guests, check-in rules, nightly price, availability, cancellation policy, and whether children or pets are allowed. The Booking Marketplace documentation explicitly mentions fields for price, guests, infants, pets, and cancellation policy.

• Make sure GeoDirectory core is installed and the main directory pages are working.
• Check the post type that will be used for bookable properties, most often Places or a separate CPT for accommodations.
• Prepare a test listing with an address, images, category, and owner.
• Decide whether payments will be required, deposit-based, or whether bookings will initially be accepted without payment.
• Determine whether you need a marketplace commission, a service fee, and owner payouts.
• Confirm which listing template you are editing: a block template, Elementor, a GeoDirectory theme, or another compatible builder.

Technical Dependencies You Cannot Ignore

Booking Marketplace uses GetPaid for payments and GetPaid Wallet for owner balances. The documentation clearly states that if the required components are missing, the site will prompt you to install or activate those plugins. That means you should not design booking as an isolated form: the order, invoice, payment hold, commission, and wallet are all connected to GetPaid.

If you plan to offer filters based on booking parameters, Advanced Search will be useful. The Booking Marketplace documentation notes that additional booking fields can be used with Advanced Search so users can filter suitable listings. But those fields do not appear in search automatically: you need to add them to the search settings for the specific CPT and verify how they appear in the form.

If the site monetizes owners not only through booking commissions but also through listing packages, take a close look at Pricing Manager. The setup guide includes an important note: when Pricing Manager is installed, commissions can be set at the price package level. This is useful if, for example, basic owners pay one commission rate and premium owners pay another. But that logic should be tested on a separate draft package first so you do not break existing published listings.

Prepare a Test Environment

Before going live, create a test property and a test owner account. This helps you view the product as a normal user, not only as an administrator. The owner should be able to access their listing, booking management buttons, and, if payments are enabled, wallet information. The guest should see the booking form, availability calendar, and final total. The administrator should see the booking entry under Bookings > Bookings.

Do not test settings only inside the admin panel. For a booking marketplace, you need to validate the flow across three roles: administrator, property owner, and guest.

Installing GeoDirectory Booking and Running the First Check

Installation starts with the basic GeoDirectory logic: the directory must work first, and only then should the booking extension be added. If GeoDirectory is being installed for the first time, start with the core plugin, the setup wizard, and a test post type. If the directory already exists, do not immediately change templates on the live listing page. Add the blocks to a draft template or a test property page first.

From a WordPress perspective, the sequence looks familiar: upload and activate the extension, install the required dependencies, open the settings, and save the basic options. But there is an important difference with this product: after activation, nothing useful will appear on the public page until you add the fields and blocks to the specific CPT and listing template.

Basic Installation Sequence

1. Confirm that GeoDirectory core is active, the directory pages open correctly, and the test listing is visible on the public site.
2. Install GeoDirectory Booking using the GeoDirectory add-on installer or by uploading the ZIP archive via Plugins > Add New > Upload Plugin.
3. Activate the extension and accept the installation or activation of GetPaid and GetPaid Wallet if the site prompts you to do so.
4. Open the booking settings in the admin panel and save a minimal configuration for payments, commissions, and cancellation policies.
5. Go to the CPT settings, add the booking fields to the listing form, and verify that the owner can enable booking for a specific property.
6. Add the GD > Booking Form, GD > Booking Availability, and owner management block to the property listing template.
7. Create a test booking as a guest and verify that it appears in the admin area.

The First Sign That Installation Was Done Correctly

A proper first check is not simply seeing the plugin activated in the extensions list. You need to see three outcomes: the listing now has a booking enable field, the property card shows the form or calendar, and the admin area includes a place to manage bookings. If even one of those elements is missing, the installation is not complete yet.

At this stage, do not immediately enable advanced discounts, multiple rooms, search filters, or custom commission schemes. First, get a simple scenario working: one property, one nightly price, one date range, one test booking. Only then should you add extra layers.

Key Settings After Installation: Payments, Commissions, and Booking Holds

The booking settings section defines the site's financial and operational logic. The official documentation lists parameters such as Booking Payments, Deposit %, Booking Sales Commission %, Additional Service Fee %, Payment Form, Hold booking (minutes), and Cancellation policies. Each of them affects not only the admin panel, but also the expectations of both the guest and the property owner.

The biggest mistake at this stage is to treat the settings as a checklist of toggles. They are really marketplace rules. If you collect full payment, the guest expects a confirmed reservation after payment. If you collect a deposit, you need to explain clearly what is paid now and what remains due later. If a booking can be created without payment, you need to decide how long the property will be held and who confirms the request.

How to Choose a Payment Mode

Booking Payments determines whether the site collects full payment, a deposit, or no money at the time of booking. For most marketplace scenarios, it is best to start with a simple mode that is easy to explain to users. Full payment reduces the risk of unpaid reservations, but requires careful payment setup. A deposit is useful for higher-value stays, but it introduces questions about the remaining balance. Booking without payment works for an MVP or a manual approval workflow, but it requires discipline around request confirmation.

After changing any financial setting, make a test booking and verify the final amount, status, entry in Bookings > Bookings, the GetPaid invoice, and the owner balance. This is not a formality: different payment modes change the user path and may alter how totals, commissions, and date holds are handled.

Commission and Service Fee

The marketplace commission and the additional service fee may sound similar, but they serve different purposes. The commission is deducted from the booking price, so it affects how much the owner receives. The service fee is added on top and can be used as a separate charge to the guest for using the platform. Do not blur these two settings when explaining them to owners, or you will end up with disputes over why the guest total and the owner payout do not match.

If you have Pricing Manager installed, the Booking Marketplace documentation notes that commissions can be set by price package. This is a powerful feature, but it requires a clean package structure. For example, you might offer a lower commission rate to owners on a higher-tier listing package. But first test one package, one booking, and one payout flow.

Cancellation Policies

Cancellation policies are created by the administrator and can then be selected by owners through the corresponding listing field. A good cancellation policy should be clear before payment: the guest needs to know what happens if they cancel, and the owner needs to understand which rules they are committing to. In the developer guide, this setting is tied to adding the cancellation policy field to the listing form, so setup is not complete until the owner can choose a policy for their property.

Holding an Unpaid Booking

Hold booking (minutes) protects the site from stalled unpaid orders. When the limit expires, the pending invoice is canceled and the dates are released back to inventory for other guests. Do not set the interval too high without a reason: if a guest never completes payment, the property may stay unavailable for everyone else. But a value that is too short can also frustrate users if the payment gateway requires an extra confirmation step.

Result check: create a test booking, do not complete payment, and make sure the dates become available again after the selected hold period. If you are not prepared to test that scenario, do not enable strict hold logic on the live site.

Listing Fields and the Property Template: Where Booking Becomes Visible

The most important part of configuring GeoDirectory Booking is not limited to the global settings. Booking has to be wired into a specific post type and a specific listing template. The documentation describes adding fields through Places > Settings > Custom Fields and adding blocks through the listing details template. This is the point where the product stops being an installed extension and becomes a working user interface.

In the standard flow, the listing owner must enable booking for the property. That is done through the Booking field, which the documentation identifies as required for booking to work. Additional fields expand the scenario: nightly price, cancellation policy, maximum guests, infant suitability, and pet suitability. These fields are useful not only in the listing form, but also in search if Advanced Search is enabled.

Fields Worth Adding First

Do not add every possible field without a structure. Start by defining the minimum form that the owner can realistically fill out. For a standard rental property, a sensible starting point is the booking enable field, a base price, a cancellation policy, and guest capacity. Fields for infants, pets, and additional restrictions can be added after the core booking flow is working.

• Booking enables booking for a specific listing.
• Nightly Price sets the base nightly rate if pricing is not managed elsewhere in the owner's settings.
• Cancellation Policy links the listing to a predefined cancellation rule.
• Property Max Guests adds guest capacity to the form and booking details.
• Property Suitable for Infants and Property Suitable for Pets help guests filter suitable properties.

Blocks for the Owner

The owner management block is needed so the person responsible for the property can configure booking, review current orders, and manage availability. The documentation describes the GD > Booking Button block for the details page template: if the owner has enabled booking, they will see controls for booking setup and current reservations. Without this block, the administrator may think everything is configured while the owner has no clear way to manage anything.

Place the owner block where it does not interfere with the guest experience. In most cases, it can be shown only to the listing author or inside the account area, depending on the template and user permissions. If you use UsersWP, the documentation suggests adding a bookings tab to the profile through the form builder. That is more convenient than forcing the owner to find each request from the page of an individual property.

Blocks for the Guest

For the guest, you need GD > Booking Form and, optionally, GD > Booking Availability. The booking form handles date selection, guest count, and the move to confirmation. The availability block shows the calendar and can change the dates and pricing in the form when the user selects a period. That is why those two elements are best placed next to each other: if the calendar is far away from the form, users will not understand why the price changed.

Inside the listing template, booking should be prominent without overwhelming the main listing content. A good layout is: property title and key details, gallery or description, then the pricing, calendar, and booking form block. If the page includes many widgets, make sure the booking form does not end up pushed below related properties, reviews, or promotional content.

The Rooms Scenario and Multiple Accommodation Units

One of the most product-specific capabilities in GeoDirectory Booking is the rooms feature. It is designed for cases where a single listing represents a property with multiple accommodation units: a B&B, a small hotel, a guesthouse, or multiple rooms in one building. The documentation explicitly states that rooms can be named, priced, and booked separately. This is not a cosmetic feature, but a way to avoid creating a large number of nearly identical listings.

Imagine a guesthouse with a "Standard Room," "Family Room," and "Studio." If you create three separate listings, the owner has to manage descriptions, the address, the map, and reviews in three places. If you use the rooms feature instead, the property stays as a single listing while the rooms get their own names, prices, and availability. For a small business, that is usually much more practical.

What You Need to Enable for Rooms

First, add the Multiple Units and Number of Rooms fields to the listing form. They enable the multiple-unit mode and let the owner specify the number of rooms. After that, the owner can go into the booking settings interface, choose a specific room, edit the price data, set the room name, and configure individual options. Once that is done, the guest sees room selection in the form or calendar.

It is important not to enable the rooms feature for every property unless it is actually needed. If most listings are standalone apartments or houses, the room field can confuse owners. It is better to add it only to the CPT or package where multiple units inside one listing are a real use case.

How to Explain the Room Logic to the Owner

The owner needs to understand the difference between a property and a room. The property is the public listing with the address, description, map, and shared rules. The room is a separate bookable unit inside that property. It can have its own price and availability, but it inherits the context of the main listing. If the owner tries to use rooms for different addresses, it is better to create separate listings instead, or the map, search, and reviews will mislead guests.

Result Check for the Rooms Feature

1. Add the Multiple Units and Number of Rooms fields to the form for the required CPT.
2. Open the test listing as the owner and enable multiple accommodation units.
3. Enter the number of rooms and go to the booking settings.
4. Give each room a clear name and a base price.
5. Open the property page as a guest and verify that room selection appears in the form or calendar.
6. Create two test reservations for different rooms and confirm that they do not conflict with each other.

Main risk: the rooms feature should not replace the directory structure itself. If the rooms are in different locations, those should be separate listings, not different units inside the same listing.

Guest Search and Filters: How Not to Hide the Right Properties

Booking inside a directory is useless if users cannot quickly find an available property. In GeoDirectory Booking, some booking-related fields can be tied to Advanced Search so guests can filter listings by criteria such as price, guest capacity, property features, and other fields. But this requires separate setup: the fields must be added to the listing form and then enabled in search for the specific CPT.

The Advanced Search documentation describes adding fields in CPT > Settings > Search: available fields on the left, active form fields on the right. It is also important that this configuration is done separately for each CPT. If you have multiple post types, such as "Hotels" and "Apartments," a filter configured for one type does not automatically work for the other.

Which Filters Are Actually Useful

Do not turn the search form into a questionnaire. For a rental site, a few strong filters are usually enough to influence the guest's decision. Price, maximum guests, suitable dates, area or distance, pet-friendly options, and property category are useful criteria. Internal owner-only fields, on the other hand, should not be exposed in search.

If a field is supposed to help with search, verify data quality first. A pet filter is useless if half the owners left the field blank. A price filter is misleading if some properties are configured through custom price data and others through a base rate. Before publishing filters, go through several test listings and populate them with consistent logic.

Connecting It to Advanced Search

1. Open the settings for the required CPT and make sure the booking fields have been added to the listing form.
2. Go to that CPT's search tab and add only the fields guests will genuinely use to choose a property.
3. Save each field after adding it, then configure the order and labels.
4. Check the public search form on the directory page and the results page.
5. Create test listings with different values and make sure the filter does not return empty results simply because the data is incomplete.

If a filter does not appear, first check that the field was not sent to the main search bar instead of the advanced form, that it was added to the current CPT, and that it was saved after being moved to the active column. In GeoDirectory user discussions, confusion often comes from mixing up listing form fields and search fields: a field may exist in the CPT but still not be enabled in the search tab.

Practical Example: A Guesthouse Directory with a Marketplace Commission

Let us walk through a realistic scenario. You have a local guesthouse directory. The site owner wants property hosts to accept date-based bookings, show availability on the listing page, charge a marketplace commission, and allow owners to see their bookings and balances. Our goal is to assemble a minimally working setup that can be validated without launching the entire site.

Goal

Create a guesthouse listing where the guest selects dates and number of guests, sees the final amount, submits a reservation through the form, and the administrator sees the entry under Bookings > Bookings. The property owner should have access to booking settings and the GetPaid wallet.

Preparation

Before you begin, GeoDirectory, GeoDirectory Booking, GetPaid, and GetPaid Wallet should already be installed. The directory should have a CPT for accommodation properties, such as the standard Places or a separate type like "Guesthouses." You need a test entry with an owner, address, category, and at least one photo. Also prepare a page or template where the booking blocks can be placed safely.

Setup Steps

1. In the booking settings, choose a payment mode. For the first test, use the option that is easiest to validate in your environment: full payment, deposit, or no payment.
2. Set the marketplace commission and, if needed, enter a separate service fee in the appropriate field.
3. Create one simple cancellation policy, such as "Flexible" or "Standard," without complex wording.
4. In the CPT settings, add the Booking, Nightly Price, Cancellation Policy, and Property Max Guests fields.
5. Open the test listing as the owner, enable booking, set the nightly price, and choose the cancellation policy.
6. Add GD > Booking Form and GD > Booking Availability side by side in the listing template.
7. Give the owner access to booking management through a block on the listing page or through the account area.
8. If UsersWP is used, add a bookings tab to the profile or use the corresponding GeoDirectory widget for customer bookings.
9. Place the GetPaid > Wallet block where the owner can see the balance if you are testing payouts.

Validation

Open the property as a guest in a different browser or a private window. Select dates, confirm that the price changes when you interact with the calendar, submit the form, and move the request to the status that matches the selected payment mode. Then return to the admin area and check Bookings > Bookings. The owner should see their booking in the owner interface, and the administrator should see the order details and commission.

The Detail That Often Breaks the First Test

If the guest cannot see the form, do not rush to reinstall the plugin. Most often, the problem is that the Booking field is not enabled for the specific listing, the form block was not added to the current CPT template, or you are viewing a different property page than the one you edited. In GeoDirectory, many settings are tied to the post type, so always check the full path: CPT, listing form, details page template, and public listing page.

How to Validate the Result After Setup

GeoDirectory Booking should be validated as a complete scenario. It is not enough to open the page and see a calendar. You need to confirm that data flows through the entire path: the listing allows booking, the form accepts dates, GetPaid creates the payment layer, the order appears in the admin area, the owner sees the reservation, and the wallet reflects the outcome. This is especially important if the site charges commissions and allows owners to withdraw funds.

Validation from the Administrator Side

The administrator checks the structure: settings, fields, templates, statuses, and financial logic. After a test booking, open the bookings section and make sure the record contains the property, owner, guest, dates, amount, and status. If commissions are enabled, compare the booking amount with the amount that should reach the owner. If unpaid order hold is enabled, verify that the dates are released after the timeout expires.

Validation from the Property Owner Side

The owner should be able to repeat the basic actions without the administrator. They open their listing, see the management button, configure booking settings, check the calendar, and review incoming orders. If the owner has to enter the main WordPress admin panel and hunt for unclear menu items, the user flow is not ready yet.

Validation from the Guest Side

The guest does not know that CPTs, blocks, and GetPaid exist behind the page. They see the property, price, available dates, cancellation rules, and the form. Check that all important elements appear together: calendar, form, final amount, guest information, and the cancellation policy. If the user selects dates in one place but the price changes far lower on the page, the interface feels broken even if the technical logic is correct.

Mini Checklist Before Launch

• The test listing can be booked by a guest without administrator privileges.
• The booking form is visible only where the property is actually bookable.
• The availability calendar updates the selected dates and does not conflict with the form.
• An unpaid booking releases the dates after the configured timeout, if the timeout is enabled.
• The owner can see their own bookings and cannot see anyone else's.
• The GetPaid wallet shows the expected amount after commission is applied.
• Emails and notifications do not contain empty internal fields.
• Search filters return properties with completed booking-related fields.

Safe Improvements Without Editing the Plugin

With GeoDirectory Booking, it is better not to start with PHP snippets unless the developer has documented a specific hook for your use case. Public sources provide enough information about blocks, settings, fields, and GetPaid, and there is no reason to invent internal plugin functions. Safe improvements should therefore happen through settings, the listing template, block structure, CSS around your own containers, and interface text.

Improving Form Readability with a Custom Block Class

If the booking form visually gets lost in a long property page, you can wrap the booking blocks inside a WordPress group and assign that group a custom CSS class, for example gd-booking-panel. This does not edit the plugin and does not depend on the developer's internal classes. You style your own container, while the official blocks remain inside it.

.gd-booking-panel {
  border: 1px solid #d9e2ef;
  border-radius: 10px;
  padding: 20px;
  background: #ffffff;
  box-shadow: 0 8px 24px rgba(28, 45, 70, 0.08);
}

.gd-booking-panel .wp-block-heading {
  margin-top: 0;
}

.gd-booking-panel + .gd-booking-panel {
  margin-top: 18px;
}

It is best to add this CSS through a child theme or the theme's built-in additional styles field. After inserting it, check the property page on desktop and mobile. If the style conflicts with the theme, remove the class from the group or remove the CSS. The booking data itself will not be affected.

Use Text and Hints Instead of Hidden Logic

If guests often make mistakes when selecting dates, do not rush to change the form logic. First, add a short explanatory paragraph next to the calendar: how the period is selected, when the price is recalculated, and where the cancellation policy is shown. This simple improvement often solves more problems than custom code.

Cache Compatibility

Be careful with aggressive caching on booking pages. The booking form, availability calendar, and user areas may contain data that depends on the selected dates, the user status, or the current property. If, after enabling caching, the calendar shows outdated dates, exclude bookable property pages, the GetPaid checkout, and account pages from full static caching. The exact rules depend on the cache plugin, so first reproduce the issue on a single test page.

Common GeoDirectory Booking Issues and Troubleshooting

It is best to troubleshoot in sequence: the dependency is installed, the field has been added, the listing is enabled, the block is placed in the correct template, the user has the right role, GetPaid payments are configured, and caching is not serving an outdated version of the page. This order saves time and prevents unnecessary plugin reinstalls when the real issue is the template or the listing data.

The Booking Form Does Not Appear on the Property Page

Symptom: the plugin is active, but the guest cannot see the date selection form. Possible cause: the Booking field was not added to the CPT, was not enabled for the specific listing, or the GD > Booking Form block was not inserted into the details template. Check the exact CPT the property belongs to. Then open the listing and confirm that booking is enabled. After that, review the listing template.

Fix: add the required field to the listing form, save the property with booking enabled, and insert the form into the template. If the form appears after that, do not change other settings until the test booking is fully completed.

The Calendar Is Visible, but Pricing or Dates Do Not Update

Symptom: the user selects dates, but the form does not update the amount or selected period. Possible cause: the availability block is placed separately from the form, the selected dates are not being passed as expected, the pricing data is incomplete, or the page is being served from cache. Make sure GD > Booking Availability and GD > Booking Form are placed next to each other on the same property page, and that the owner has set a base price or price data.

Fix: first save the pricing settings in the owner interface, then temporarily disable caching for the test property page and try selecting dates again. If the issue disappears, set up cache exclusions for booking-related pages.

The Owner Cannot See Booking Management

Symptom: the administrator can see everything, but the property owner cannot open booking settings or the order list. Possible cause: the owner block was not added, the owner is not the author of the listing, the account area does not contain the required widget, or the UsersWP profile is not configured. The documentation suggests using blocks and widgets for owner setup and customer bookings, and with UsersWP, adding a bookings tab to the profile.

Fix: verify the listing author, add the management block to the property page or account area, and then test with a separate owner account. Do not validate this flow from an administrator account because it hides real access restrictions.

The Booking Is Created, but the Owner Does Not See Money in the Wallet

Symptom: the order exists, but the owner balance does not match expectations. Possible cause: GetPaid Wallet is not activated, the payment is not confirmed, the commission is configured differently, withdrawals are disabled, or you are viewing the wrong user account. The Booking Marketplace documentation explains that the owner's amount is sent to the wallet after booking minus commissions, and that withdrawals may be disabled by default.

Fix: check the payment status, commission settings, the GetPaid > Wallet block, and GetPaid > Settings > General > Wallet. If withdrawals are not needed yet, do not enable them until the payment flow has been fully tested.

Search Filters Do Not Find Properties by Booking Fields

Symptom: the field was added to the listing, but it does not work in search or does not appear in filters. Possible cause: the field was not added to the search tab for the specific CPT, was added to the wrong form, or was not saved after being moved. Advanced Search must be configured separately for each CPT.

Fix: open CPT > Settings > Search, add the required field to the active fields, save it, and test across several listings with different values. If the results are empty, check data completeness first, not just the filter interface.

Rooms Are Being Used Like Separate Properties

Symptom: the owner adds different addresses as rooms inside one listing. Possible cause: the rooms feature model was explained incorrectly. Rooms should be units inside one property, not separate locations.

Fix: use the rooms feature for B&Bs, guesthouses, and small hotels. For properties at different addresses, create separate listings so the map, search, and reviews remain accurate.

When GeoDirectory Booking Is the Right Choice

GeoDirectory Booking is worth using if you are building more than just a rental page and need a directory of properties with owners, search, filters, a map, and booking directly from the listing page. The product is especially useful when the platform needs marketplace commissions, owners need control over their own properties, and guests need a clear date selection form. In that architecture, GeoDirectory Booking does not feel like an unnecessary add-on. It covers the exact chain of listing - availability - order - commission - wallet.

Before launch, do not rush to enable every feature. First, assemble the minimum path: one CPT, one test listing, a base price, a booking form, a calendar, GetPaid, the owner wallet, and a visible record in Bookings > Bookings. Then add rooms, cancellation policies, Advanced Search filters, package-based commissions, and interface improvements. That order reduces the risk that an issue in one layer is masked by another setting.

If, after testing, you can see that your use case is truly built around GeoDirectory and a booking marketplace, you can download the latest version of GeoDirectory Booking and test it on a site copy or a separate staging environment. Do not start with a live directory. First confirm the form, dates, payments, owner roles, and booking visibility.

If your project really comes down to a single hotel, a single property, a separate service schedule, or an existing WooCommerce-based structure, compare alternatives before implementation. The right choice is not determined by the word "booking," but by where the center of the site actually is: the directory, the hotel system, the marketplace theme, or store products.