Skip to Content
Usage

Usage

This page explains how things behave in the panel and what to configure after Installation. It matches the Vortexus Marketplace and Vortexus Web extensions in Paymenter.

Menu labels can differ slightly by Paymenter version. If you do not see an item, search admin for Vortexus or open Admin → Extensions → Vortexus Marketplace — the settings screen shows quick links to Categories, Templates, and Installations.

Before you start

  1. Storage folders exist and php artisan storage:link has been run.
  2. Vortexus Marketplace and Vortexus Web are enabled (Module packages).
  3. In Vortexus Marketplace settings, Panel server extension ID (VortexusWeb) is set to the same row as your Pterodactyl credentials in Admin → Servers (the number in the URL when you edit that server, e.g. /admin/servers/2/edit → use 2).
  4. For live game servers, Pterodactyl & Wings is configured (including allowed_origins for the console).

Admin sidebar: “Vortexus Marketplace”

When the module is enabled, the admin sidebar includes a group named Vortexus Marketplace (usually toward the bottom). Use it to manage catalog data and to inspect install activity.

Categories

What it is: Groups that organize templates in the public marketplace (like “Minecraft”, “FiveM”).

What you set:

  • Name, slug, description, sort order, active on/off
  • Pterodactyl Nest ID — must match a real nest in your Pterodactyl panel (same ID you see in Pterodactyl admin)

Templates belong to one category so customers can browse by group.

Templates

What it is: Each template is one item in the marketplace: the game/app (egg), text, images, optional files, and install variables.

What you set:

  • Category, nest ID, egg ID (from Pterodactyl)
  • Descriptions, gallery, video, icons
  • Startup / environment fields customers fill at install time (when applicable)

A template is what customers see on /marketplace/{slug} and what they install or deploy.

Regions

What it is: A region is a sellable location: it maps to a Pterodactyl Location ID (datacenter / location in Pterodactyl).

What you set:

  • Name, slug, image, description, sort order, active
  • Pterodactyl Location ID (from Pterodactyl — must exist)
  • Optionally Panel server (extension) — use this if that region talks to a different VortexusWeb / panel row; otherwise the global Panel server extension ID in marketplace settings is used

Customers pick a region so the node and allocations match that location.

Installations

What it is: A read-only log of marketplace install jobs (not your day-to-day editing screen).

Each row links a template, user, service, status (pending / running / completed / failed), and timestamps. Open a row to see details such as error_message when something failed.

Use it to: confirm an install finished, or trace why a customer’s install is stuck or failed.

Default currency: Marketplace billing uses Paymenter’s default currency (Admin → Settings → Other) and formats from Admin → Currencies. Changing default currency can affect existing marketplace services; read the notice in the marketplace extension settings if you change it.


Extension settings: Multi Servers off vs on

Open Admin → Extensions → Vortexus Marketplace (or your version’s equivalent), save after changes.

When Enable Multi Servers is off (default)

This is the classic flow:

  1. The customer has (or buys) a normal game-server service in Paymenter — a service that uses Vortexus Web / your Pterodactyl integration.
  2. On the marketplace, they open a template and use Install on an existing service.
  3. The module runs the install process on that server (egg/variables as configured). Progress and errors show in Installations.

There is no “create a brand-new server from the marketplace with sliders” wizard. If the user has no eligible service, the UI points them to buy a server from the cart first.

Billing: Follows your normal Paymenter products (plans, invoices, renewals). The marketplace Monthly / PAYG choice on the big deploy screen is not used for this path — that screen is part of the multi-server “new server” flow.

When Enable Multi Servers is on

Customers get a mode selector on the install flow:

  1. Existing server — same idea as above: pick a service they already own and install the template onto it.
  2. New server — a deploy wizard: egg variables (if any), then region, resources (sliders within the min/max you set), and billing type (see below). A new Paymenter service and Pterodactyl server are created according to module rules.

Extra settings that matter with Multi Servers:

  • Resource limits — min/max/step for memory, disk, CPU, swap, databases, backups, extra allocations, proxy limit (caps what sliders allow).
  • Per-unit prices — price per GB RAM / month, per GB disk / month, per vCore (100% = 1 core) / month, and optional prices per database, backup, port, proxy unit. These feed the monthly total shown in the deploy UI.

Customers with an active marketplace deployment may also get actions such as adding another server on the same service (when your product/rules allow it) — UI depends on theme and version.


Monthly vs Pay As You Go (PAYG)

This choice appears in the multi-server “new server” deploy step (the Deploy screen with resource summary), not in the simple “install on existing server only” flow.

Monthly (“normal” prepaid)

  • The customer pays on your normal invoice flow for the monthly total calculated from their selected resources (and your per-unit prices).
  • After payment, provisioning continues per the module. When renewal invoices for that service are paid, the marketplace billing period moves forward automatically.

Configure: Set per-unit monthly fields (and limits) in Vortexus Marketplace settings.

PAYG (balance / usage-based)

  • The customer must have account credit (balance). The UI checks a minimum balance before allowing PAYG deploy.
  • While the server is active, the module charges the customer’s balance on a schedule (every N hours), based on the same resource pricing converted to an hourly rate (monthly ÷ 730 in the product logic).

Configure in extension settings:

SettingPurpose
Pay As You Go — Minimum Balance RequiredBalance needed to start PAYG deploy (and reactivation checks use module rules).
Pay As You Go — Billing Interval (hours)Minimum hours between automatic balance deductions for active PAYG servers.
Pay As You Go — Grace Period Before Suspension (hours)After a failed debit (not enough balance), how long before the server is suspended on the panel. 0 means suspend on the next billing attempt after failure (per product behavior).

Cron / scheduler: PAYG uses the scheduled command vortexus:payg-billing. Your server must run Laravel’s scheduler every minute, for example:

* * * * * cd /path-to-your-paymenter && php artisan schedule:run

If cron does not run, PAYG charges and auto-pause will not behave as expected.

If balance runs low: The server can move to a paused / suspended PAYG state; the client area may show Pay As You Go and actions such as try to reactivate after they add credit.


Task: Walk the customer journeys

Journey A — Multi Servers off

  1. Sell a game server product (Vortexus Web) through Paymenter as usual.
  2. Customer opens Marketplace → template → Install.
  3. They choose an existing service and complete variables.
  4. Watch Installations if something fails; fix Pterodactyl / egg / allocation issues first.

Journey B — Multi Servers on, new server

  1. Set limits and per-unit prices.
  2. Set PAYG fields if you offer PAYG; ensure cron runs schedule:run every minute.
  3. Customer selects New server, fills variables, picks region, adjusts resources, chooses Monthly or PAYG, and completes checkout / balance rules.
  4. Verify the new service in Paymenter → Services and the server in Pterodactyl.

Journey C — Manage server in client area

  1. Customer opens Services → service with Vortexus Web.
  2. Console, files, backups, etc. as enabled; if console fails, check Wings allowed_origins (Pterodactyl & Wings).

Task: Check logs

  1. Paymenter: storage/logs/laravel.log (or host log viewer).
  2. Queue: If you use queues for jobs, ensure workers run.
  3. Pterodactyl: API errors in the panel when provisioning fails.

For support, send versions, what you clicked, and a short log excerpt — not the entire file.


Task: Failed deployments

  1. Read the error in Installations or laravel.log.
  2. Check allocations, egg, Docker image, and node health in Pterodactyl.
  3. Fix infra, then retry or align Paymenter + Pterodactyl manually; avoid deleting servers in Pterodactyl without updating Paymenter.

Check your setup

  • Vortexus Marketplace group in admin lists Categories, Templates, Regions, and Installations as needed.
  • Template appears on the public marketplace; install or deploy completes without errors.
  • Multi servers: New-server path shows Monthly and PAYG where configured; PAYG only works with working scheduler + balance.

Next step