Eventonomy 1.3.0: Organizer Payouts, Calendar Sync, and a Mobile Backend

Eventonomy 1.3.0 changes what the plugin is responsible for. Before this release, Eventonomy ran events on your site. Now it also settles what organizers are owed, pulls in events your organizers already run somewhere else, and gives you a backend a mobile app can talk to. None of those are small additions. They are the three things a growing events community eventually needs and usually has to bolt on with a separate tool. This release builds them in.

If you already run Eventonomy, this is what you got. If you are deciding whether it should run your events, this is what it does now, described the way you would actually use it, not as a list of what shipped.

What Eventonomy is, in short

Eventonomy is a community event platform for WordPress, built on its own database tables rather than custom post types or postmeta, so it stays fast as your event count grows. It is 100% REST API and block-native, and it is built frontend-first: your members create events, RSVP, and manage their own event dashboard without ever touching wp-admin.

The free plugin covers the core of running events:

• Frontend event creation and a My Events dashboard
• RSVP with capacity limits and waitlists
• Plus-guests and account-less magic-link RSVP
• Free and donation ticket types
• Calendar, list, and search blocks
• Subscribable ICS calendar feeds
• GDPR export and erase
• One-click importers from The Events Calendar, EventON, Events Manager, WP Event Manager, and Sugar Calendar, with a scan preview, background processing, and typed-confirmation undo so a bad import isn’t a disaster
• Reminder emails and email blasts to registrants
• Events scoped to a community space or group

You can read the full feature list on the Eventonomy download page, see the background in our introduction to Eventonomy, and there’s a walkthrough of the RSVP and community setup in how to add community events and RSVPs to your WordPress site.

Eventonomy Pro extends the free plugin through its public API, no free code is edited, and Pro requires free installed and active. Pro splits into two halves.

• Community and growth tools that every organizer benefits from: calendar sync, door check-in, discovery feed, BuddyPress integration, maps, advanced recurrence, and analytics
• Commerce tools for organizers who sell tickets: paid checkout, gateways, coupons, refunds, an earnings ledger, and multi-organizer and multi-venue support

Eventonomy does not take a cut of ticket sales; whatever fee structure you set is yours.

Here is how the free plugin and Pro line up, using only the capabilities named above:

Capability	Free	Pro
Frontend event creation and My Events dashboard	Yes	Yes
RSVP with capacity limits, waitlists, plus-guests, magic-link RSVP	Yes	Yes
Free and donation ticket types	Yes	Yes
Calendar, list, search blocks and subscribable ICS feeds	Yes	Yes
Importers (The Events Calendar, EventON, Events Manager, WP Event Manager, Sugar Calendar)	Yes	Yes
GDPR export and erase	Yes	Yes
Reminder emails and email blasts to registrants	Yes	Yes
Calendar Sync from external ICS feeds and Eventbrite	-	Yes
Door check-in	-	Yes
Discovery feed	-	Yes
BuddyPress group integration	-	Yes
Maps	-	Yes
Advanced recurrence	-	Yes
Analytics	-	Yes
Paid checkout, gateways, and coupons	-	Yes
Refunds with automatic earnings ledger reversal	-	Yes
Organizer payouts (manual export-and-pay or Stripe Connect)	-	Yes
Multi-organizer and multi-venue support	-	Yes

Paying your organizers without signing up for anything

This is the headline change in 1.3.0, and it is worth explaining in the order it actually matters to a site owner: you can pay organizers with zero payment integrations connected.

Every paid order now writes to an earnings ledger. When a ticket sells, the ledger records what the organizer is owed and what the platform keeps, and if that order is refunded, the ledger reverses the entry automatically. The platform fee itself is configurable as a percentage per order or a flat amount per order, whichever matches how you monetize the marketplace.

Organizers see their side of this on the member dashboard, in a new Earnings section: what they have earned, what has been paid out, what is still outstanding, broken down per event, with payout history underneath. That answers the question every organizer eventually asks you directly, which is “how much do I have coming.”

On your side, a Payouts admin screen lists every organizer carrying an outstanding balance and lets you record a payout against it. And this is the part that matters if you don’t want to deal with a payment processor at all: an Export Owed button downloads a CSV of every outstanding organizer balance, so you can pay people through your own bank transfer or PayPal, mark it paid in the admin screen, and move on.

No Stripe account, no Connect onboarding, no API keys. That’s deliberate. Automation is something you opt into, not something the plugin forces on you before it will let you pay anyone.

If you do want automation, Stripe Connect is the upgrade path. An organizer connects their own Stripe account from their dashboard, and when you record a payout for them, it sends a real Stripe transfer instead of a manual note. Organizers who haven’t connected an account simply stay on the manual record-and-pay path, side by side with organizers who have. You are not forced to pick one model for the whole site.

Either way, organizers get a receipt email when a payout is recorded, and they can pull their own earnings statement as a CSV whenever they want it for their own bookkeeping. That closes a gap that used to leave organizers guessing, or emailing you, about money they’d earned.

Payout method	What you need to set up	Best for
Manual export and mark paid	Nothing to connect. Download the Export Owed CSV, pay organizers by your own bank transfer or PayPal, then mark the payout as paid in the admin screen.	Site owners who don’t want a payment processor in the loop at all, or who are just getting started with paid events.
Stripe Connect	Each organizer connects their own Stripe account from their member dashboard; you still record the payout from the admin screen.	Sites that want payouts to send automatically as real Stripe transfers instead of a manual note, without forcing every organizer onto Stripe at once.

Bringing in events you already run somewhere else

Most organizers running a community calendar didn’t start on your site. They have events on other platforms, or a personal calendar app, or an Eventbrite account they’ve used for years. 1.3.0’s second theme is a Calendar Sync engine that pulls events in from those places instead of asking organizers to recreate everything by hand.

The core of it is straightforward: point Eventonomy at any iCalendar (ICS) feed and it will import from that feed on a recurring schedule, checking for duplicates each time so a re-sync doesn’t clone the same event over and over. Members connect their own feeds from their own dashboard, and they own whatever events come in through them, which matters because it means you don’t have to be the one managing every organizer’s external calendar link.

Eventbrite gets its own path, with two ways to connect it.

• Wire it up site-wide with a single owner’s token, so any organizer’s Eventbrite events flow in centrally
• Let individual members paste their own token and connect their personal Eventbrite account directly

The admin visibility here is the part that actually makes this usable at scale rather than just technically possible. A Sync Sources screen lists every feed connected on the site, showing:

• Who owns it
• How often it runs
• When it last ran
• Its current status

You can trigger a sync on demand, or remove a feed, all from one place.

And when a feed fails, it now tells you why, instead of just quietly returning nothing and leaving you to guess whether the problem is the feed, the token, or Eventonomy. Common reasons include an unreachable host, a rejected token, or a file too large.

Large feeds are handled in bounded batches that resume rather than needing to complete in a single request, so an organizer with a few hundred events on an external calendar doesn’t time out trying to bring them all in at once.

The mobile layer

The third theme in this release is that Eventonomy now has a real backend for a mobile app, not just a website that happens to be responsive. This is infrastructure, not a shipped app, but it is the infrastructure a native app needs:

• An app configuration endpoint
• A member profile route
• An in-app notifications feed
• Self-serve account deletion (which app stores generally require)
• Event reporting
• A data source for My Events

Push notifications work through device registration paired with Expo, so native push delivery doesn’t require you to stand up your own push infrastructure. There’s a new Mobile App settings tab in the admin where you configure and brand the app experience for your site.

One detail that’s easy to undersell but matters a lot in practice: single event API responses now return viewer-relative fields, your own RSVP status, whether you’ve checked in, how much capacity is left, calculated for whoever is asking. That means a mobile screen can show “you’re going, capacity is 12 left” without firing off two or three additional requests to piece that together.

And free RSVPs now mint a check-in token the same way paid tickets do, so an unpaid registration can be scanned and checked in at the door just like a paid one. If you were only planning to support paid events at check-in, that limitation is gone.

The quieter changes that matter

A few changes in 1.3.0 aren’t the headline, but they’re the kind of thing that determines whether the plugin feels finished once you’re actually running it day to day.

• Real customer accounts on paid checkout, not disappearing guest orders
• A per-event registration mode: on-site, off-site, or none
• Event categories and tags with an admin management screen
• A mobile-responsive admin, with tables that collapse to cards below 640px
• A large jump in migration performance for big event calendars

Buyers now get a real account when they check out for a paid event, instead of a guest order that evaporates the moment the tab closes. That means every purchase has an owner, an order history, and a retrievable invoice, which is what a customer expects when they’ve paid money for something.

Billing details are stored on the same fields WooCommerce uses, so if your site also runs WooCommerce for anything else, one saved address serves every purchase across the whole site rather than each plugin asking the customer to type it in again.

Paid orders snapshot the billing details at the moment of purchase and render them on the PDF invoice, so the invoice reflects what was true when the sale happened, not whatever the customer’s profile says today.

Events now have a per-event registration mode:

• Register here on the site
• Register on another website entirely
• No registration at all

That sounds minor until you’ve had to explain to an organizer why their announcement-only post is showing an RSVP form nobody should fill out, or why a session that’s actually ticketed through a partner site is offering a competing signup form. Now the organizer just picks the right mode for what the event actually is.

Event categories and tags arrived with an admin screen to manage both, which is the basic taxonomy tooling a calendar with more than a handful of events needs to stay browsable.

And the admin itself works on a phone now. Admin tables collapse into labelled cards below 640px instead of forcing horizontal scrolling through a table meant for a desktop screen, and forms stack properly on small screens. If you manage your site from your phone between other things, that’s not cosmetic, it’s the difference between being able to do the task and giving up and waiting until you’re at a laptop.

On the scale side, migration performance improved substantially. A migration of 20,000 events used to read 4 million rows and need 96 MB of memory per batch, numbers that get uncomfortable fast on shared or modest hosting. It now reads roughly 20,000 rows and needs almost no memory overhead for the same job.

Metric (20,000-event migration)	Before 1.3.0	After 1.3.0
Rows read	4 million	Roughly 20,000
Memory per batch	96 MB	Almost none

If you’ve been putting off migrating a large existing calendar because you weren’t sure your hosting could survive it, that constraint is largely gone.

Why the correctness fixes are release-blocking, not a footnote

A few of the changes in 1.3.0 are bug fixes, and we’re naming them plainly rather than folding them into vague “improvements” language, because the honest framing matters more than looking clean.

• Money was calculated with the wrong precision on currencies that don’t use two decimal places
• A refunded order voided only the first 100 tickets, so larger orders could keep valid, scannable tickets after a refund
• Private events were readable by anyone with the direct URL
• Attendee-management and event-creation role restrictions could be bypassed

Money was being calculated with the wrong precision on currencies that don’t use two decimal places. Refunds on Japanese yen, which has zero decimal places, were sending amounts 100 times too large. Refunds on Kuwaiti dinar, which has three decimal places, were sending amounts 10 times too small.

Neither of those is a rounding quirk you can shrug off, they’re the kind of bug that either costs you money directly or looks like fraud to whoever’s reconciling the books. It’s fixed in 1.3.0, with the plugin now storing money using real ISO precision per currency.

We’ll say plainly what isn’t finished yet: some earnings figures and CSV exports still display to two decimal places on three-decimal currencies, even though the underlying amount is now correct. That display gap is scheduled to be closed in the next release, and we’re stating it here rather than letting you discover it.

A refunded order used to void only the first 100 tickets in that order. On any order larger than that, attendees past the hundredth ticket kept a valid, scannable ticket even after the whole order was refunded, which means someone who’d gotten their money back could still walk in the door. That’s fixed, refunds now void every ticket in the order regardless of size.

Private events were readable by anyone who had the direct URL, whether or not they had permission to see the event. Fixed. And permissions around who can manage an event’s attendees have been tightened: managing attendees for an event you don’t own now requires site-manager permission, and a site that had restricted event creation to a specific custom role was previously failing open, letting every logged-in member create events regardless of the role restriction. Both are closed now.

We’re listing these directly because a plugin handling other people’s money and other people’s private event data doesn’t get to treat correctness fixes as routine maintenance. They existed, they’re fixed, and the currency display gap that’s still open is stated above rather than left for you to find.

Free versus Pro: who needs which

If you’re running free or donation-based events for a community, and you want organizers to be able to create events from the frontend, RSVP with waitlists and capacity, and never touch wp-admin, the free plugin covers that on its own. The importers alone make it a reasonable replacement for whatever calendar plugin you’re currently on, since they bring your old events across with a preview and an undo path rather than asking you to trust a one-way migration.

Pro is for two different kinds of growth, and you can adopt either half without the other. If your organizers are spread across other platforms and calendars, or you want a discovery feed, BuddyPress group integration, maps, or door check-in for free events, that’s the community-and-growth half of Pro, and it applies whether or not you ever charge for a ticket.

If you’re going to sell tickets, the commerce half is what gets you a real checkout, gateways, coupons, refunds that actually reconcile, and now, as of 1.3.0, a way to actually pay the organizers who are selling through your site, either with zero integration through manual export-and-pay, or fully automated through Stripe Connect.

Pro requires the free plugin installed and active, it extends it rather than replacing any part of it, and nothing in Pro edits free’s code directly. That’s a structural choice, not an incidental one: it’s what keeps free stable as Pro grows, and it’s what makes the free plugin a safe long-term foundation whether or not you ever add Pro at all.

Full release notes are posted for both halves: Eventonomy release notes and Eventonomy Pro release notes.

Frequently asked questions

Do I need Stripe to pay my organizers?

No. The Payouts admin screen and the Export Owed CSV let you record payouts manually and pay organizers through your own bank transfer or PayPal, with no Stripe account, no Connect onboarding, and no API keys. Stripe Connect is available if you want transfers to send automatically, but it’s an upgrade you opt into, not a requirement.

Does Eventonomy take a cut of ticket sales?

No. Eventonomy does not take a cut of ticket sales. Whatever platform fee you configure, a percentage per order or a flat amount per order, is yours to keep; the plugin doesn’t skim anything on top of it.

Can I import my existing events?

Yes. The free plugin includes one-click importers from The Events Calendar, EventON, Events Manager, WP Event Manager, and Sugar Calendar, with a scan preview, background processing, and typed-confirmation undo so a bad import isn’t permanent. If your organizers keep running events on an external calendar or Eventbrite on an ongoing basis, Eventonomy Pro’s Calendar Sync engine can pull those in on a recurring schedule instead of a one-time import.

Do I need Eventonomy Pro to run free community events?

No. If you’re running free or donation-based events for a community and want organizers to create events from the frontend, RSVP with waitlists and capacity limits, and never touch wp-admin, the free plugin covers that on its own.

What happens to my events if I stop paying for Pro?

Based on how the two plugins are built, Pro extends free through its public API without editing any of free’s code, and Pro requires free installed and active just to run at all. That means your events live in the free plugin’s own database tables regardless of Pro’s status. If Pro access lapses, the Pro-only capabilities, calendar sync, paid checkout, payouts, and the rest, stop working, but the free plugin keeps running your events on its own foundation.

Where this is headed

The three things added in this release, getting organizers paid, pulling events in from wherever they already live, and having a real mobile backend, all came from the same place: organizers and site owners running real communities told us what was missing once the basics worked.

The three-decimal currency display gap we mentioned above is already on the list for the next release, not because we found it in a lab, but because it’s the kind of thing that only shows up once real money in real currencies moves through the system.

That’s the pattern we intend to keep: ship what’s asked for, be straightforward about what’s not done yet, and fix the things that touch trust before anything else.