Retiring a FiveM Store Package Without Losing Track of Existing Buyers

Retiring a FiveM Store Package Without Losing Track of Existing Buyers

A package can stop making sense long before its last customer stops using it. Perhaps your server no longer offers the associated roleplay feature, a membership has been replaced, or an asset bundle needs a different structure. Removing the sales tile is the easy part. Existing access, renewals and support records require their own decisions.

Treat package retirement as a small migration with a named owner and a completion check. The following workflow concerns stores using Tebex, but it does not assume that every package has the same deliverables. A game-server command, a Discord role and a FiveM asset entitlement need different verification.

Define exactly what is ending

Write a sentence that separates new sales from existing service. For example: this package will stop accepting new purchases on a specified date, while existing buyers retain the stated benefits under the published arrangement. If the benefits themselves are changing, document that separately and review the actual commitments you made to customers.

Do not use the word retired to stand for several unspecified actions. Staff need to know whether you mean hidden from browsing, unavailable to new buyers, no longer renewed, or no longer delivered. Buyers need the same clarity without learning the details of your control panel.

Keep a copy of the original package description, pricing options and delivery configuration for reference. Record the package identifier as well as its display name. Renaming a package during the transition should not make past orders difficult to understand.

Disabling sales does not settle subscriptions

Tebex’s package documentation explicitly says disabling a package prevents new subscriptions but does not affect existing ones. That distinction belongs at the top of the retirement checklist. A disabled storefront listing is not evidence that recurring charges have stopped.

Inspect the package in the actual store and identify whether it supports one-time purchases, subscriptions or both. Then inspect associated recurring records. Do not infer subscriber status from whether a player currently has a Discord role or can enter an in-game area. Those systems can be out of sync.

Assign one person to verify future billing and another, where practical, to verify delivered access. On a small team the same person can perform both checks, but keep two separate results. A single tick beside package removed hides too much.

Make a small transition register

Create a private record containing the old package identifier, proposed replacement if any, sales stop date, existing delivery mechanism and responsible staff member. Add unresolved questions rather than guessing the answers. The register should explain the transition without becoming a duplicate customer database.

For affected subscriptions, use the payment system’s records as the starting point. The Tebex recurring payments guide describes an Ending subscription as still active but no longer due to renew, distinct from Active and Cancelled. It also explains where creators can inspect the next billing date and where customers can manage subscriptions.

Record the status relevant to each planned action, with the time it was checked. A screenshot taken a week earlier may no longer describe the account. Limit access to this working record to staff who need it, and avoid posting customer names or payment details in a public retirement announcement.

Trace each benefit to its removal path

Consider an illustrative supporter package that grants a Discord role and an in-game cosmetic entitlement. Ask how each benefit arrives, where it is stored and what removes it. A successful Discord change does not prove the game database changed, and deleting a database row does not prove the billing state changed.

Review the configured actions for purchases, renewals and removals rather than assuming one action covers all lifecycle events. Do not delete the resource or integration that handles a required removal while subscriptions still depend on it. Equally, do not leave an outdated renewal action granting a benefit that the new package also grants.

FiveM asset delivery has specific limitations. Tebex’s package guidance says the Remove After setting does not work for FiveM or RedM assets, and describes asset revocation in connection with refunds on paid transactions or subscription expiry. Do not promise that hiding a listing will revoke an asset or that it transfers ownership to a replacement package.

Keep replacement decisions explicit

A replacement package is not automatically an upgrade path. Write down whether existing buyers need to do anything, whether they can keep their current arrangement, and how staff will handle a buyer who purchases the new package before the old one ends. Confirm that your actual tools support the plan before announcing it.

Be especially careful with a change in recurring price. Tebex’s recurring payments documentation says price edits do not automatically change existing subscriptions; customers must cancel and resubscribe to receive updated pricing. Do not describe an ordinary package edit as a completed subscriber migration.

A useful customer notice names the affected package, gives dates with a time zone, explains the effect on current access and points to the appropriate account or support route. Avoid a compulsory resubscribe message unless that is the verified arrangement. Customers should be able to tell what happens if they take no action.

Rehearse the transition using a suitable test

Choose a test method for the delivery type. Tebex’s testing guide distinguishes checkout Test Mode from Manual Payments and warns that FiveM assets granted through either cannot simply be revoked. It provides a subscription-based testing approach for those assets. Read that current guidance before issuing a test entitlement.

For your own game-server integration, rehearse the relevant sequence in a controlled environment: old benefit present, transition action applied, intended benefit present afterwards. Also test repeating the action. A support retry should not create an extra allowance or remove a replacement benefit by mistake.

Check an offline buyer as well as a connected one when the delivery method depends on player presence. Our guide to store behavior during server downtime explains why billing and delivery cannot be treated as one simultaneous event. Keep retirement checks open until the relevant delivery state is verified.

Remove stale invitations to buy

Once the intended sales restriction is in place, check direct links, category listings, old announcements, navigation and any package recommendations you control. A package can disappear from a category while an old post still tells people to buy it. Test the direct URL as a visitor and read the resulting message.

Keep support staff supplied with the old name and the replacement explanation. A buyer returning after several weeks should not be told the package never existed. Preserve the records needed to explain what they purchased through the store’s supported recordkeeping tools.

Close the migration only when new sales behave as intended, recurring records match the agreed plan, delivery has been checked and customers have a usable explanation. Archive the transition notes with a date. The catalogue may now look simpler, and the people who already paid should still be able to understand their purchase.