WB Listora 1.3.0: We Audited Every Credit Charge and Refund End to End

If you run a directory site, you already know that the parts customers never see are the parts that decide whether they trust you with a card number.

WB Listora 1.3.0 is built around exactly that: not a new feature list, but a line-by-line audit of every place money, credits, and account status move through the plugin. This is the release where the team went looking for the failure modes nobody had reported yet, found several real ones, and closed them before a support ticket had to teach them a lesson.

This article is organized around what changed for you, not around a changelog. The question is simpler: what can you now do, and what can you now trust that you couldn’t before?

What WB Listora is, in one pass

WB Listora is a block-based WordPress directory plugin. You can build a business directory, a restaurant guide, a hotel listing site, a real estate portal, a job board, or an events calendar on the same core, because the listing types and custom fields are configurable rather than hardcoded to one vertical.

The free plugin is not a trial. It’s a complete, usable directory engine on its own:

• Custom listing types with a flexible custom-field system, plus services attached to a listing
• Faceted search with geo/radius filtering, full-text search, and a “search this area” map control
• Interactive maps with Leaflet built in and marker clustering for dense areas
• A multi-step frontend submission wizard with media uploads, for logged-in users
• Reviews and ratings with helpful votes and owner replies
• Business claims with admin approval and ownership transfer
• A frontend user dashboard for managing listings, reviews, claims, and profile
• CSV, JSON, and GeoJSON import/export, plus migrators for competing plugins
• Schema.org markup, anti-spam (reCAPTCHA v3, Cloudflare Turnstile, Akismet), and RTL support
• Action Scheduler and denormalized indexes for scale, plus WP-CLI commands and a REST API for headless use

Pro sits on top of that free core, requires it to be active, and ships in version lockstep with it. Pro never runs standalone.

It adds the monetization layer, Google’s mapping stack, and the discovery and trust features that directories need once they have real volume: advanced search alerts, multi-criteria and photo reviews, lead capture, verification badges, white-labeling, analytics, an audit log, webhooks, and a reverse-listing marketplace (“needs”) where buyers post what they want and vendors respond.

Free vs Pro: what belongs where

The table below answers the question we hear most from people evaluating the pair: “wait, is that free or paid?”

Nothing in this table is new in 1.3.0. The credit economy, coupons, plans, needs, analytics, and lead forms have always been Pro-only. 1.3.0 is precisely the release that made sure those Pro-only surfaces behave correctly under load.

Capability	Free	Pro
Custom listing types, custom fields, services	Yes	Yes
Faceted search, geo/radius, full-text, “search this area”	Yes	Yes
Leaflet maps with clustering	Yes	Yes
Google Maps and Places (autocomplete, custom map styles)	No	Yes
Frontend submission wizard, media uploads (account required)	Yes	Yes
Reviews, ratings, helpful votes, owner replies	Yes	Yes
Multi-criteria and photo reviews	No	Yes
Business claims and ownership transfer	Yes	Yes
Frontend user dashboard	Yes	Yes
CSV / JSON / GeoJSON import-export, competitor migrators	Yes	Yes
Credit-based economy, pricing plans, coupons, webhooks	No	Yes
Payment gateways (WooCommerce, WooCommerce Subscriptions, MemberPress, PMPro, WooMemberships)	No	Yes
Advanced and saved search, email alerts, infinite scroll	No	Yes
Lead forms, verification badges, white-label, coming-soon mode	No	Yes
Analytics, audit log, reverse-listing marketplace (“needs”)	No	Yes
Schema.org markup, anti-spam, RTL	Yes	Yes
WP-CLI, REST API, Action Scheduler-backed scale	Yes	Yes

If you’re running a free directory with no monetization, most of 1.3.0’s headline work doesn’t touch you directly, though the surface-honesty and hardening fixes below still do. If you’re running Pro with a credit economy, this release is the one you install without waiting.

The credit economy now behaves under failure, not just under a demo

Pro’s monetization model runs on credits. Buyers purchase credit packs or subscribe to a plan, and credits get spent on listing fees, featured placement, or lead access.

Anyone who has run this kind of system knows the actual risk was never “does a normal purchase work.” It’s what happens when the webhook is slow, the gateway retries, two refund requests land at once, or a coupon gets hammered by concurrent checkouts. Those are exactly the paths 1.3.0 went after.

Here is what the audit found and fixed, described plainly rather than softened:

• Payment webhook ordering was backwards. The webhook previously marked a payment as completed before the credits had actually landed on the account. If the credit step then failed, the customer had a charge on their card and a zero balance. Now a failed credit release puts the row back to pending, and the gateway’s own retry heals it, so a charged member is never left empty-handed.
• Refunds used the wrong credit rate. If you changed your credit rate after a purchase, refunding that older purchase could credit or debit the wrong amount. Refunds now use the rate that was snapshotted on the original payment, not whatever rate is configured today.
• Duplicate refunds were possible. Two concurrent refund requests against the same purchase could both succeed, refunding credits twice. This is now rejected atomically at the database level, not just checked in application code that a race condition can slip past.
• Single-use and limited coupons could be over-redeemed. Under concurrent submissions, a coupon capped at one use, or a fixed number of uses, could be claimed more times than allowed. Fixed.
• A missing transaction ID could trigger re-crediting. If a payment webhook fired without a transaction ID and the gateway retried the call later, the account could be credited a second time for the same purchase. Closed.
• Paused listings could be reactivated twice from one webhook. A single top-up event was capable of reactivating the same paused listing more than once. Now it activates exactly once per top-up.
• Failed activations could reverse an already-committed charge. If plan activation or a need response failed partway through, it could roll back a charge that had already gone through, leaving the vendor with a plan or a lead they didn’t pay for. Fixed.

Two more items round out the money-accuracy work. These are not failure-path bugs, they are everyday-arithmetic bugs:

• Per-listing credit fees could be charged at a fraction of the configured amount, because of a mismatch between the money unit the fee was configured in and the unit the charge logic expected. The fee charged now matches the fee set in Settings.
• Credit receipts were displaying the raw internal storage units instead of the actual credit amount, which meant a receipt could show a number that had nothing to do with what the member actually spent. Receipts now show the real credit amount.

Direct Stripe partial refunds also got a specific fix: they could over-revoke credits relative to the actual refunded amount, taking back more than the refund justified.

And publishing a saved draft listing on a monetized site now correctly runs through the plan and credit path, so a plan-gated listing can no longer go live without the credit hold that’s supposed to guard it. That gap let drafts skip the paywall entirely.

The table below is the blunt version, the one you’d want if you were deciding whether to update tonight or wait for a maintenance window.

What could go wrong before	What it meant in practice	Status in 1.3.0
Payment marked complete before credits landed	A charged member could end up with a zero balance	Fixed: failed credit release returns to pending, gateway retry heals it
Refunds used the current credit rate, not the purchase-time rate	Changing your rate later could mis-credit old refunds	Fixed: refund uses the rate snapshotted on the original payment
Concurrent duplicate refunds on the same purchase	Credits could be refunded twice	Fixed: rejected atomically at the database level
Single-use / limited coupons under concurrent checkout	A coupon could be redeemed more times than its cap allowed	Fixed
Webhook retry with no transaction ID	A delayed gateway retry could re-credit the same purchase	Fixed
One top-up webhook, paused listing reactivated twice	Plan cost charged once, reactivation applied twice	Fixed: activates exactly once per top-up
Failed plan activation or need response	Could reverse an already-completed, separate charge	Fixed: a failed follow-on step can no longer undo a committed charge
Per-listing credit fee unit mismatch	Fee charged could be a fraction of the configured amount	Fixed
Credit receipts showed raw storage units	Receipt amount didn’t match what was actually spent	Fixed
Direct Stripe partial refunds	Could over-revoke credits relative to the refund amount	Fixed
Publishing a saved draft on a monetized site	Could bypass the plan/credit hold entirely	Fixed: draft publish now runs the plan and credit path

One new setting rides along with this work: a Credit Rate field under Listora > Settings > Credits. If your credit economy isn’t a flat one-to-one exchange, you can now set that rate from the admin screen instead of editing a database value directly.

Guest submission is gone, and that’s a deliberate call

This is the part of the release that will surprise anyone who was relying on it. Anonymous, no-account listing submission, including its email-verification step, has been removed. Submitting a listing now requires a logged-in account.

The reason is not cosmetic. Guest submitters were never able to upload media through that flow. The wizard is built around media uploads as a core step, and a guest session couldn’t complete it.

Every guest submission either dead-ended before publishing or had to skip the images entirely. That is not a real submission path for a directory where photos are often the whole point of a listing: a restaurant, a rental, a storefront.

Rather than leave a “feature” in the UI that looked functional but silently failed for a chunk of the people who tried it, the team removed it. Two things came out with it:

• The “Require Login” block control, which no longer has anything to toggle, was removed to match.
• The enable_guest_submission flag, which had become inert, no longer appears in the app-config REST response, so headless clients and mobile apps built against that config won’t see a setting that does nothing.

If you configured your directory expecting guests to submit without an account, this is a breaking change for you, and it’s worth being direct about that rather than burying it in a changelog line. Two practical points:

1. Anyone who wants to submit a listing now needs to register first. If your growth depends on low-friction submission, plan a lightweight signup step ahead of the wizard rather than assuming the old flow still works.
2. The upside is a submission path that actually completes. A guest flow that let people start a listing and then hit a wall at the media step was arguably worse for conversion than requiring an account up front, because an account holder can finish, save a draft, and come back to it from their dashboard.

If your site genuinely needs frictionless anonymous intake, that’s a product decision to make deliberately, with your own account-creation UX around it, rather than something to expect from a plugin path that was quietly broken.

The dashboard and forms stop showing things that aren’t true

Several fixes in 1.3.0 are less about money moving incorrectly and more about the interface telling the visitor something false. These matter because a directory’s credibility depends on what’s on screen matching what’s actually configured.

• The submission form and the frontend dashboard no longer show credit pricing or a “Buy Credits” link on installs that have no configured way to actually buy credits. Previously a site without a payment method wired up could still show a pricing prompt that led nowhere.
• If you’ve set a custom Buy Credits URL, it is now honored everywhere a credit call-to-action appears, including inside paused-listing notification emails, not just on the main dashboard.
• Listings sitting in email-verification limbo now carry a proper, visible status label and valid status transitions, instead of appearing in the admin list unlabeled.
• Programmatic SEO pages and BuddyPress profile listing views now display the actual star rating and review count, and SEO pages sort higher-rated listings first.
• The Compare page link updates immediately when you repoint it in Settings. Before this fix, visitors could be served a stale URL for up to an hour.

None of these are dramatic on their own. Together they’re the difference between a directory that looks maintained and one where an attentive visitor starts noticing small inconsistencies and loses confidence in the listings.

Uninstall, headless access, and hardening

If you’re deciding whether to trial WB Listora Pro on a live or staging site, uninstall behavior is exactly the detail that determines whether that trial is safe. 1.3.0 tightens this in both directions.

• Deleting the plugin only removes your data if the “Delete data on uninstall” option is enabled, matching how the free plugin already behaves. Previously, Pro could wipe plans, coupons, badges, needs, and webhooks on uninstall regardless of that setting.
• When you do opt in to a clean uninstall, it now actually is clean: every Pro table is dropped, including search-terms and rate-limit tables previously left behind, and reverse-listing capabilities are removed from every role.

A handful of API and infrastructure fixes matter specifically if you’re running a headless frontend, a mobile app, or a shared host without Redis or Memcached:

• The public REST rate limiter is now atomic even with no object cache configured. It uses a MySQL counter instead, so per-IP request caps actually hold under concurrent traffic on ordinary shared hosting.
• Updating settings through the REST API now runs the same validation the admin screen uses, so a headless client sending a malformed payload can no longer corrupt list-limit or notification settings.
• Creating a “need” is now gated behind a proper capability check, need responses are rate limited, and API errors return their real HTTP status codes instead of a generic response.
• The coupon list REST endpoint is now paginated instead of returning your entire coupon table in a single response.

Taken together, this is what a “we audited it” release should look like on the infrastructure side. Nothing flashy, but the kind of hardening that only shows up when someone actually tries to break the thing under real conditions.

What this means if you’re choosing a directory plugin right now

The honest framing is this: the free plugin covers a genuinely complete directory, from custom listing types through reviews, claims, import/export, and a real REST API, without needing Pro at all.

Pro is specifically for the moments a free directory outgrows itself: charging for listings, running lead capture, offering saved search alerts, or opening a reverse marketplace where buyers post requests instead of only browsing.

A monetization system that silently under-charges, over-refunds, or double-credits doesn’t usually announce itself. It shows up months later as a support queue full of confused vendors and a reconciliation headache for the site owner.

Fixing eleven distinct money-flow issues in one pass, several of them concurrency bugs that only appear under real traffic, is the kind of work that happens when a team goes looking for problems instead of waiting for a ticket to describe one.

Frequently asked questions

Do I need Pro to run a directory?

No. The free plugin includes custom listing types and fields, faceted and geo search, Leaflet maps with clustering, the frontend submission wizard, reviews with owner replies, business claims, a frontend dashboard, import/export, schema markup, anti-spam, and a REST API. Pro is specifically for monetization (credits, plans, coupons, payment gateways), Google Maps, advanced saved search, lead forms, verification badges, analytics, and the reverse-listing marketplace.

Can visitors submit a listing without an account?

No, as of 1.3.0. Guest submission and its email-verification step were removed because guest sessions could never complete the media-upload step in the wizard, so the flow always dead-ended before publishing. Submission now requires a registered account. That is a breaking change if your site relied on anonymous submission, but it replaces a path that looked functional and wasn’t with one that actually completes.

Do I need a Google Maps API key?

Only if you want Google Maps and Places, including address autocomplete and custom map styles, which are Pro features. The free plugin ships with Leaflet maps and clustering built in, and Leaflet does not require a Google API key.

Will updating delete my data?

No, not on update. Data removal only happens on uninstall, and only if you’ve enabled “Delete data on uninstall” in settings, matching how the free plugin has always worked. Prior Pro versions could wipe plans, coupons, badges, needs, and webhooks on uninstall regardless of that setting. 1.3.0 fixes that so uninstall respects your choice both ways.

Do free and Pro have to be updated together?

Pro requires the free plugin to be active, ships in version lockstep with it, and never runs standalone. Update both together rather than leaving one behind, so the credit-flow and validation fixes are in effect across both plugins rather than only one side of the pair.

Where to go next

If you’re running WB Listora Pro with any credit economy live, treat 1.3.0 as a priority update rather than a routine one, given the number of payment-path issues it closes.

You can get the current release from the Listora download page, and the full technical changelogs are on the free release notes and Pro release notes pages if you want the line-by-line version.

If you’re still deciding whether a dedicated directory engine is the right architecture at all, the case for a standalone, high-performance directory engine is worth reading before you commit to a generic custom-post-type approach. And if Directorist is the plugin you’re weighing Listora against, the Directorist review lays out that comparison directly.