HikaSerial - Joomla Extension

Guide to Setting Up HikaSerial for Serial Codes, Coupons, and E-Tickets

HikaSerial is not meant for a standard product description. It is built for cases where a customer should receive unique data after purchase: a serial number, license key, gift certificate, e-ticket, access code, or another individual identifier. In this guide, we will walk through how to build that workflow in a Joomla store powered by HikaShop, from preparation and installation to generators, packs, product assignment, order verification, and troubleshooting.

This article is written as a practical HikaSerial how-to, so it focuses less on repeating the product listing and more on working solutions. We will break down the logic of "product - pack - serial code - order," show when it makes more sense to import ready-made codes and when to generate them automatically, explain why order status affects code delivery, and show how to verify that the buyer will actually see the result.

Special attention is given to the scenarios that usually raise questions: gift certificates through the coupon generator, dynamic ticket images through Attach Serial, one-time serial code consumption, linking product inventory to the number of available codes, language overrides, and safe testing with a test order.

How HikaSerial Fits Into a HikaShop Store

HikaSerial works as an add-on component around HikaShop. After installation, its menu is merged with the HikaShop menu, so the administrator manages products, orders, discounts, and serial packs from one workspace. This is an important detail: the extension does not replace the store or create a separate checkout process. Instead, it adds a layer of unique data to a standard order flow.

The basic chain looks like this: you create or import serial data, group it into a pack, assign that pack to a product, and then HikaSerial delivers the required number of codes when the order reaches the right status. If the customer places the order but it is still in an intermediate status, the code may not appear. Once the order moves to a confirmed status, the extension links the serial number to the order and the customer.

That is why HikaSerial is useful when a product is more than a description and a downloadable file. It is built for cases where the result of a purchase must be unique for each customer: one ticket for a specific seat, one coupon tied to the order amount, one key for an external system, one event entry code, or a separate code that can later be verified and redeemed.

The extension should not be viewed as a simple random string generator. It includes several layers of logic:

• Serial data - the actual codes, numbers, links, strings, or values the customer receives.
• Pack - a group of serial data or a generation rule linked to one or more products.
• Generator - a plugin that creates new values when you are not using a preloaded code database.
• Consumption - separate logic where the code is not just delivered, but later used, validated, and moved to a different state.
• Output - displaying the code in the order, email, customer panel, or a dynamic image.

This architecture makes HikaSerial flexible, but it also requires careful setup. If even one layer is missed, the order may complete successfully while no code is delivered. That is why the rest of this guide will keep tying configuration back to verification: what should appear in the admin panel, what the customer will see, which symptom points to an incorrect status, and how to safely roll back a questionable change.

Key idea: HikaSerial does not deliver a "product." It delivers a unique value tied to the order, product, pack, and status. First design the real workflow, then choose the generator and settings.

Who This Extension Is For and When It Is Overkill

HikaSerial is a strong fit for stores where HikaShop already handles the main sales workflow. If your catalog, cart, checkout, and order statuses all run through HikaShop, adding serial logic usually feels natural. You are not moving the store to another platform. You are extending existing products with unique codes.

The clearest use cases are software licenses, e-tickets, gift certificates, SIM numbers, coupons, protected text, or codes for an external service. In each of these cases, the buyer needs more than a file. They need a unique value. Sometimes that value should appear in the order. Sometimes it needs to be sent by email. Sometimes it needs to be validated by a staff member at the entrance or by another user who is not the purchaser.

When HikaSerial Makes the Most Sense

Choose this extension if you need tight integration with HikaShop orders and want to control code delivery based on order status. For example, a store sells gift cards. The customer pays, the order becomes confirmed, HikaSerial creates a HikaShop coupon from a template, and attaches a dynamic image with the code to the email. In that scenario, the extension covers several jobs at once: code generation, order linkage, delivery formatting, and later coupon usage inside the store.

Another strong use case is e-tickets. The buyer receives a code, and a staff member later consumes it at the entrance. In that case, the No user assign setting matters because the ticket may be used by someone other than the purchaser. If you do not think through that detail in advance, validation at the entrance may fail for a user who received the ticket as a gift.

When Another Approach Is Better

HikaSerial may be unnecessary if you sell only standard physical goods and do not deliver unique codes. For a simple catalog, standard file downloads, or a regular coupon without an individual image, HikaShop itself or a dedicated extension for that specific task is often enough. The extension also does not replace a full participant management system if your core use case is subscriptions, access tiers, recurring payments, and a complex membership area without serial numbers.

You should also assess whether your team is ready to maintain status-based logic. In HikaSerial, the result depends on how HikaShop moves an order from Created to a confirmed status, which statuses are assignable, what happens on refund, and whether a code should be reusable. For a small store this is manageable, but for a project with multiple payment methods, manual moderation, and custom statuses, that process should be mapped out before launch.

What to Check Before Installation and the First Test

Before installation, it helps to define the future delivery model instead of jumping straight into the extension archive. HikaSerial depends on HikaShop, order statuses, and the generation scenario, so preparation usually saves more time than trying to configure everything on the fly by following screen labels.

First, make sure your HikaShop store can already complete a test order through the status you need. If payment on the test site does not move the order into a confirmed state, HikaSerial may be configured correctly and still never deliver a serial code. The developer documentation explicitly points this out: a created order by itself does not deliver a code to the customer, so for testing you need to confirm the order manually in the HikaShop admin panel.

Quick Prep Checklist

• Confirm that HikaShop is installed and the store opens without errors in the Joomla admin panel.
• Define which product needs a code: ticket, license, certificate, coupon, external code, or protected value.
• Decide whether codes will be preloaded into a database or generated by a plugin at order time.
• Agree on which order statuses should make the code available to the customer.
• Decide whether the code is for the buyer only or can be redeemed by someone else.
• Prepare a low-cost test product or an internal test payment method so you do not validate the setup on real customers.

Do not combine every feature in the very first test. If you need a gift certificate, a QR ticket, and imported external numbers, start with one product and one pack. After that works, add the next scenario. This makes it much easier to tell whether the issue is in the generator, the pack, the email, the order status, or the display in the customer account.

How to Choose Between Importing and Generating

The main early decision is the source of your serial data. If you already have a ready-made list of external codes such as SIM numbers, keys for another service, or pre-issued licenses, use a serial value database. In that setup, HikaSerial pulls an available code from the pack instead of inventing a new one.

If the code should be created inside the store, use a generator. For standard random strings, the random generator is fine. For gift certificates, you need the coupon generator because it creates an actual HikaShop coupon rather than just a string. For sequential numbers, the series generator may be a better fit. For scenarios where the code will be redeemed later, look at temporary or consumable codes if your version and plugin set support that behavior.

Practical check: before installation, write down one sentence: "After buying product X, the customer should receive Y, see it in Z, and use the code in way N." If that sentence is hard to write, pack configuration will probably become chaotic.

Installing in Joomla and Checking the Menu

HikaSerial is installed as a standard Joomla extension through the Extensions Manager. After installation, the extension menu appears alongside the HikaShop menu, which helps keep everything in one place instead of switching between unrelated panels. But this is also the point where many users get a false sense that everything is already ready: the menu is there, the component opens, so it must be ready to sell. In practice, after installation you need to verify not just that the menu exists, but that the integration with HikaShop actually works.

1. Open the Joomla admin panel and go to extension installation.
2. Upload the HikaSerial installation package using the standard Joomla process.
3. After installation, open the HikaShop menu and make sure the HikaSerial items are available next to the store options.
4. Go into the HikaSerial configuration and do not change every setting at once. Start by checking order statuses and serial number display.
5. Open the HikaSerial plugin list and make sure the required generators and integration plugins are available.

If the menu does not appear, do not start creating products and packs blindly. Check whether HikaShop is installed, whether there were any package installation errors, whether your HikaShop version matches the requirements listed in the changelog, and whether Joomla sees the component in the installed extensions list. If HikaShop has not been updated in a long time, check the HikaSerial changelog first. The developer uses it to specify which HikaShop version is required for each HikaSerial release.

What Counts as a Successful Installation

A successful installation is more than a Joomla message saying the package was uploaded. A solid first check has four signs: the component opens, the HikaSerial menu is visible from the HikaShop area, the plugin list loads, and a test order in HikaShop can be moved into a confirmed status. That last point matters because the entire serial delivery workflow depends on order status.

At this stage, you do not need to test the email layout, QR code, certificate image, or code consumption. It is enough to confirm that the extension is installed, does not conflict with the basic admin panel, and can see HikaShop. The fewer variables in the first test, the easier it is to find an issue.

The First Test Without Real Payment

For the first check, it is best to create a dedicated test product that is hidden from regular visitors or placed in a private category. Its job is not to sell. Its job is to confirm that HikaSerial reacts to an order exactly the way you intended. Give the product a name that cannot be confused with a live certificate, such as TEST HikaSerial Gift Card, and link only one test pack to it.

After placing the order, do not judge the result by the "thank you for your order" page. In most real-world setups, the code does not appear the moment the order is created. It appears after confirmation. Open the order in the admin panel, move it to a status that is included in the assignable list, save it, and only then check the serial numbers. This test shows how HikaSerial behaves without payment gateway side effects.

If the code is assigned after a manual status change, move on to checking the payment method. If the code is still not assigned, stay inside HikaSerial. The pack, generator, available records, and product assignment matter more at that stage than the customer email or product page layout.

The Core Logic: Pack, Generator, Product, and Order Status

The most important part of any HikaSerial setup guide is not the installation screen but the underlying mechanism. The extension does not deliver a serial code because the product is named "certificate." It delivers a code because a pack is linked to the product, that pack knows where the codes come from, and the order has moved to a status that allows assignment.

It helps to think of the logic as this chain:

1. The pack stores or retrieves serial data.
2. The generator creates new values if the pack is not using a preloaded database.
3. The HikaShop product is linked to the pack and defines how many codes are issued per purchase.
4. The order moves into an assignable status.
5. HikaSerial links the code to the order and user, or immediately marks it as used, depending on the pack type.
6. The customer sees the code in the order, email, customer panel, or receives it as a dynamic image.

If no code is delivered, walk through that chain from top to bottom. Do not start by editing the email template until you have confirmed that the pack is published, has a generator or available codes, the product is actually linked to the pack, and the order has the correct status.

The Pack as the Center of Configuration

The pack determines where the code comes from and what happens to it after delivery. The pack documentation includes several important fields: data source Sql or None, generator, refund status, access level, low stock notification, unlimited mode, consumable mode, user check on consumption, web service access, No user assign, random selection, and description.

For the first working scenario, three decisions matter most. First, the data source. Sql means HikaSerial can use pre-created or available codes. None means the code is always created through the configured generator. Second, whether the pack is published. An unpublished pack does not deliver codes to products. Third, whether the code is consumable. A non-consumable code is often treated as used right away, while a consumable code is assigned first and can be redeemed later.

The Generator as the Code Creation Rule

The generator defines both the format and the meaning of the new value. The random generator creates simple random codes. The coupon generator creates HikaShop coupons from a template. The EAN generator is tied to barcodes. The series generator is suited for sequential numbers. Your generator choice should follow the business case, not habit. A gift certificate created with a random generator will give you a string, but it will not create a HikaShop coupon. For a certificate, you specifically need the coupon generator.

Order Status as the Trigger

HikaSerial configuration includes the Assignable order statuses setting. The official documentation describes the standard logic: serial numbers are assigned when a HikaShop order reaches an allowed status. If the order later moves to a status that is not in the assignable list, HikaSerial may detach the serial number. This is critical for a store. A bad status map can make the code appear, disappear, or never become visible to the customer.

Safe rule: first enable assignment only for statuses that genuinely mean payment or manual approval, then decide separately what should happen on refund. Do not add every status just because "that way the code will definitely appear." That can deliver a code before payment or leave it available after cancellation.

How to Document the Internal Workflow

For a store with multiple managers, it helps to keep a short internal reference for serial packs. Five columns are enough: HikaShop product, HikaSerial pack, code source, assignment status, and where the customer sees the result. This table does not have to live in the admin panel. It can simply be part of the project documentation, and it makes it much easier to understand which pack is responsible for which product.

This becomes especially important when you have multiple product types. For example, one product sells a certificate where the code is a HikaShop coupon. Another sells a ticket that must be redeemed by staff. A third sells an external key that must never be issued twice. All three scenarios use HikaSerial, but the pack, generator, and refund settings will be different. If you give the packs similar names and never document what they are for, the issue may not show up until a refund or a bulk product update.

A good practice is to use the pack description field for an internal note: why the pack exists, which products use it, whether codes can be reused, what to do on refund, and who is responsible for verification. The documentation marks the description field as private information, so it is a good place for internal notes like that.

Detailed Configuration After Installation

It is best to approach the configuration section not as a list of fields, but as a series of decisions. A typical store needs settings for statuses, customer visibility, serial availability, refund behavior, product inventory linkage, history, and output in the customer panel.

Statuses That Assign the Code

Start with Assignable order statuses. For most stores, that list should include statuses that mean payment was confirmed or the order was manually approved. The configuration documentation gives confirmed and shipped as typical examples, but your final list should match your actual order flow. If your payment plugin moves paid orders into a different status, use that one. If a status is used before payment, do not include it without a clear reason.

After saving, place a test order and manually move it into an assignable status. Check whether the code appears in the order details. Then move the order into a status that should not deliver a code and see how HikaSerial handles the assignment. That test shows whether the unassignment logic matches what your store expects.

Displaying Codes to the Customer

The display setting determines which serial statuses the customer can see. The documentation notes that the default may be Used, while a more practical option for actual delivery is often Assigned,Used. The logic is simple: if a code has been assigned to the customer but not yet redeemed, it should still be visible wherever your workflow expects it to appear.

If a customer says, "the code is not showing," while the admin panel already shows the serial number linked to the order, check this setting first. Very often the issue is not the generator, but that the current serial status is not included in the statuses visible to the customer.

Available Assignment Statuses and Code Reuse

For preloaded codes, the available-status setting matters a lot. HikaSerial needs to know which records it is allowed to pull from the database. By default, that usually includes statuses such as Free to use and Reserved. If you want to reassign codes in special scenarios, you need to think through the status after unassignment and whether previous assignment data should be deleted.

The Unassigned serial status field controls what happens to a code when the order leaves an assignable status. Unassigned preserves history. Free to use may put the code back into circulation. But if assignment data is not removed, even a code marked as free may still be filtered as already linked to an order. That is why true reuse should also be tested together with Remove data on unassigned.

Do not enable reuse automatically. For licenses and tickets, it is often more important to preserve the record of a previous assignment. For test coupons or internal codes, reuse may be acceptable, but only if you understand the consequences.

Linking Product Inventory to the Number of Serial Codes

The Link product quantity setting is useful when a product should not be sold more times than there are available codes. If the pack does not use a generator, HikaSerial can count available serial entries and update the product quantity in HikaShop. If the pack uses a generator, the stock is effectively unlimited because new codes are created on demand.

This logic is especially important for external codes and event seats. If you have 100 pre-issued numbers, the product should not sell 101 times. If the code is generated dynamically, you do not need inventory limits based on code stock, but you may run into other limits instead: format, uniqueness, length, barcode compatibility, or rules from an external system.

Change History and Two-Step Deletion

For production stores, it is useful to enable change history if the volume of activity allows it. HikaSerial can save events related to serial number creation, assignment, usage, and updates. This helps when there is a customer dispute. You can see whether the code was created, when it was assigned, and whether it was moved to another status.

The Use deleted status setting turns deletion into a two-step process: first the code gets a deleted status, then it can be removed from the database. For serial data, that is safer than immediate deletion because the code is often tied to an order, email, certificate, or external validation flow.

Settings You Should Change Only After Testing

Some settings look harmless but affect store behavior more broadly than you might expect. For example, linking product quantity to the number of serial codes can unexpectedly make a product unavailable if the pack runs out of available records or the wrong data source is selected. That is useful for limited inventory, but risky to enable on a live-selling product without testing.

The same goes for reusing codes. In internal testing, it may be convenient to return a code to the available pool, but in a live store, reissuing an old license key can create a customer dispute. For tickets, reuse after a refund may be acceptable if the ticket was never presented. For a gift certificate, you also need to verify that the linked HikaShop coupon behaves correctly.

Change these settings one at a time. After each change, create a new order, move it into the required status, and record the result. If the result is wrong, roll back only the last setting. Bulk-editing statuses, generator, pack, and customer visibility all at once almost always makes troubleshooting harder.

What to Do With Emails and the Customer Account

Once the code is being assigned consistently, you can move on to customer-facing output. HikaShop and HikaSerial support several display points: order details, the customer panel, email notification, attachment, or downloadable file. You do not need all of them at once. For a license, plain text in the order and email is often enough. For a ticket, an image or QR code is usually more convenient. For a certificate, it often makes sense to combine the code with a styled file the buyer can forward to the recipient.

Always test output using a normal customer account, not just as an administrator. Administrators often see more data than customers do. If the code appears in the admin panel but not for the customer, that does not prove the generator is broken. First check the serial status, the customer display settings, and the email template.

Generators: What Kind of Code to Create and Why Format Matters

The generator should be selected based on the intended result. A common mistake at this stage looks like this: the administrator gets a nice-looking random string, but it does not work as a coupon, does not fit the barcode format, or does not contain the data required by an external system. HikaSerial provides several generator types, and each is built for a different job.

Random Codes and Sequential Numbers

The random generator works well for simple licenses, promo codes for an external system, or internal identifiers. It is a good choice when uniqueness matters and there is no connection to the HikaShop coupon system. A sequential generator is better for tickets, seat numbers, passes, or situations where an operator needs an easy-to-check number series.

Before launch, check not only the code length but also its readability. Characters that look too similar, extremely long strings, and a lack of separators all increase the chance of manual entry errors. If a person will need to type the code, it is usually better to group characters and exclude ambiguous letters if the generator allows that.

The Coupon Generator for Gift Certificates

A gift certificate needs more than a serial number. It needs a real HikaShop coupon. The coupon generator creates a code based on a template coupon. The documentation explains that the template coupon should be unpublished, while each coupon created from it is automatically published and gets its own usage counter. That is a key difference from a basic random generator.

If the certificate amount should be tied to the purchased product, check the variable-discount setting. The official documentation describes the ability to override a fixed coupon amount with a percentage of the linked product price. This is convenient for a store because one generator can serve several certificate denominations as long as the pricing logic is confirmed and properly tested.

Serial String Format

The coupon generator uses a serial number format syntax. The documentation examples show templates with character ranges and repetition: [a-zA-Z0-9]{size}, digit groups, letter groups, fixed separators, and variables. There is no reason to make the format more complex just for appearance. The more complex the code, the higher the risk of input errors, especially if the certificate is printed or shared as an image.

A good format check is to generate several samples, open them in an email, copy one into the coupon field, and test it on a mobile screen. If the code is hard to read, change the format before launch, not after the first complaints.

How to Avoid Format Problems

The serial code format should match how the code will be used. If a person needs to enter it, keep it shorter and easier to read. If the code will be scanned by a device, compatibility with the selected QR or barcode format matters more. If the code goes into an external system, check that system's requirements first: allowed characters, length, letter case, separators, and uniqueness.

Do not automatically add special characters for "complexity." In gift certificates, characters like @ or # can create confusion when the code is read out over the phone or typed on a mobile keyboard. For license keys, uppercase letters and digits with separators are often a better choice. For internal codes, a longer format may be fine if the customer never has to type it manually.

If the generator shows examples after saving, use them as a quick sanity check. But the final test should still go through a full test order. Some issues only appear after the coupon, attachment, QR code, or email is actually created.

Serial Code Packs and Product Assignment

A pack is where an abstract generator turns into a practical policy for a specific product. One generator can be used in several packs, and one pack can be linked to products with different numbers of issued codes. That is why pack names should be clear to the administrator: not Pack 1, but something like gift-card-coupon-pack, event-ticket-entry-pack, or software-license-imported-pack.

Configuring a Pack for a Ready-Made Code Database

If you received codes from an external system, the pack should work with a serial data database. In that scenario, it is important to import or create available values in advance, configure which statuses are eligible for assignment, and define what should happen if the order is refunded. If there are not enough available codes, the product may stop selling correctly or delivery may fail entirely. For that kind of workflow, low-stock notifications are useful.

Enable random code selection only when you have a clear reason. By default, HikaSerial uses older available records before newer ones, but random selection changes that logic. For external codes, it may be important to issue them in sequence so it is easier to reconcile them with the supplier. For gift-related or neutral-use codes, random assignment may be fine.

Configuring a Pack for a Generator

If the pack relies on a generator, make sure the generator is published, selected inside the pack, and that the pack itself is published and linked to the product. With this approach, the serial code supply may be virtually unlimited, but that does not remove the need to test uniqueness and format. Barcode and QR workflows should be tested especially carefully. If the content does not fit the selected format, the resulting image may be empty or useless.

Linking the Pack to a HikaShop Product

After creating the pack, open the HikaShop product. The product editor includes a serial pack area. Use the add button to select the pack and specify how many serial numbers the buyer should receive with the purchase. For a license, this is usually one code per product unit. For a ticket bundle or package product, the number may be different.

Do not check only whether the product is linked to the pack. Check the quantity as well. If the customer buys two units of a product and the setup issues one code per order line, the outcome should still match the business logic. For tickets, that may mean two codes. For a family certificate, it may mean one code per order or one code per line item, depending on how the product is built.

How to Manage Multiple Packs Without Chaos

The more scenarios you support, the more naming discipline matters. A useful naming scheme makes both the output type and the data source obvious: coupon-generated-gift-card, ticket-consumable-event, license-imported-external. Even months later, the administrator can tell at a glance that one pack creates coupons, another is built for code consumption, and a third uses preloaded values.

Do not use one pack for different business scenarios just to save time. A certificate and a ticket may share the same code format, but that does not mean they should share refund, consumption, and display settings. A separate pack is easier to test, disable, and explain to support staff.

If a product should no longer issue codes, it is safer to first remove the product-pack link or disable the test product than to delete the pack and serial data. Deletion can make old-order investigation much harder. For historical orders, it is useful to preserve which pack was used and which code was assigned.

Gift Certificates Through the Coupon Generator

A gift certificate is one of the clearest HikaSerial use cases because it shows the difference between a serial number and a working coupon. The buyer purchases a certificate product, HikaSerial creates a unique code, and HikaShop receives a coupon that can be applied to a future purchase. If you also add Attach Serial, the customer can receive not only a text code but a certificate image as well.

The Goal of This Scenario

Suppose the store sells gift certificates in different amounts. After the order is confirmed, the buyer should receive a unique code, and that code should work as a HikaShop coupon. For this workflow, use the coupon generator, not a standard random generator.

Preparation

• HikaShop should already contain a template coupon with the required base rules.
• The template coupon should be configured so HikaSerial can generate working coupons from it.
• HikaSerial should have a coupon generator configured with a clear serial string format.
• A separate pack should be created for certificates and linked to that generator.
• The certificate product in HikaShop should be linked to the HikaSerial pack.

Setup Steps

1. Create or verify the template coupon in HikaShop. Do not use a real public coupon as a test template.
2. Open the HikaSerial plugin list and create a coupon generator configuration.
3. Enter the template coupon ID in the Discount coupon id field.
4. Configure the validity period, serial string format, and code length if your scenario requires them.
5. Save the generator and check the sample serial numbers if the screen shows them.
6. Create a pack, select the coupon generator, and publish the pack.
7. Link the pack to the certificate product in HikaShop.
8. Create a test order, manually move it to a confirmed status, and check whether the code appears.
9. Try applying the generated code as a coupon in a separate test cart.

How to Verify the Result

A successful test has two parts. The order should display a serial number, and HikaShop should contain a working coupon. If the serial number appears but the coupon does not work, review the template coupon and generator settings. If the coupon is created but the customer cannot see the code, check the customer-visible serial statuses and the email templates.

What to Check in the Template Coupon

The template coupon defines the limits for all future coupons: where it can be applied, which products or categories are eligible, whether there is a minimum amount, how many times the code can be used, and whether it works with other discounts. HikaSerial creates individual coupons from this template, so any mistake in the template will be duplicated across every new certificate.

For the first test, keep the template as simple as possible. Limit it to only the conditions you actually need. After the initial setup works, add extra rules one by one: category restrictions, minimum amount, expiration date, or no-combine rules. Test each new restriction in a separate cart. If the coupon stops applying, HikaShop may not explain the reason very clearly, so it helps to know exactly which condition you added last.

Do not use an active public coupon as the test template. Create a separate one, do not show it to customers, and do not apply it manually. That makes it much easier to distinguish the sample coupon from the customer-specific coupons generated by HikaSerial.

Important nuance: do not test a certificate only in the admin panel. The customer experience matters more: the email, customer account, certificate appearance, and coupon redemption should all be tested as one complete flow.

Dynamic Tickets and Certificates Through Attach Serial

Attach Serial is a HikaSerial integration plugin that creates dynamic images using serial data. It is useful for vouchers, giveaways, gift cards, e-tickets, and seat passes. In practice, it is more than a decorative email element. A dynamic image turns a code into a document that can be forwarded, printed, or shown at the entrance.

The plugin works with a template image and places data onto it: the serial code, order fields, product details, customer details, address data, custom text, translations, a QR code, or a barcode. Its settings let you define coordinates, area size, color, font, and output format. That is powerful, but it requires careful layout planning.

Which Settings to Check

The Attach Serial configuration includes the name, published state, email attachment behavior, pack list, download mode, template image path, and font. You can add fonts through the media/com_hikaserial/ttf/ folder if the standard set is not enough. This is especially important for Russian-language content: if the font does not support Cyrillic, the certificate may render incorrectly.

The image content is configured line by line: data type, format, X/Y coordinates, width and height limits, font size, color, and font override. For QR codes, you also choose the error correction level. For barcodes, you need to make sure the content matches the selected format. The documentation warns that if the data does not fit the barcode format, the image may come out empty.

How to Design the Template

Do not start with coordinates. First build the certificate or ticket layout as a regular image: background, title, code area, QR code area, a short instruction, and space for the customer name or order number. Then measure the coordinates and area sizes. That will help you avoid a layout where text overlaps the background, the QR code covers decorative elements, or the code becomes unreadable in print.

For the first test, use a simple composition: the code in large text, the QR code set apart, and a short instruction without long paragraphs. If you need to add the customer name, product, and date, do it step by step. After each change, download or regenerate the dynamic image from the admin panel if Attach as Download is enabled.

Language Overrides Without Editing Core Files

The Attach Serial documentation examples use translation strings such as HI_CUSTOMER_SERIAL and COUPON_INSTRUCTION_1. In Joomla, that is the right approach. Certificate text should be changed through language strings or overrides, not by editing extension files. That way, your changes are much more update-safe.

The safe workflow looks like this: create a translation key, use it in a Translation content line, add the desired text through Joomla language overrides or the HikaSerial language interface, and then test the image with a real test order. If the translation does not appear, do not edit PHP files. Check the key, site language, selected font, and cache first.

Practical Notes on Coordinates and Readability

Coordinates in Attach Serial should be treated like a print-layout task. If the code will be printed on a certificate, leave more breathing room around it. If a QR code needs to be scanned from a phone screen, do not place it on a busy background or make it too small. If the text includes the customer's name, allow for long names and double last names.

For Russian-language certificates, check the font separately. Even if the admin interface displays Russian text correctly, the dynamic image may use a different rendering method. Upload a TTF font with Cyrillic support, select it in the settings, and verify the result in the real output file. If the letters do not render, go back to the font and encoding, not the serial format.

The best test is to open the finished image on a phone, forward it by email, and print it on a basic printer. If the code is readable in all three cases, the layout is robust enough to launch. If it works only on the administrator's large monitor, support requests are almost guaranteed.

Consumable Codes: Tickets, Entry, Activation, and Transfer to Another Person

Not every serial code should simply sit in the order. Sometimes it needs to be used once: shown at entry, activated for a service, exchanged for access, converted into points, or processed elsewhere in the store. In HikaSerial, that logic is called code consumption. When a code is consumed, the serial number changes state, and related plugins can trigger additional actions.

The important distinction here is between the buyer and the person who actually uses the code. If the code is purchased as a gift, it may be used by someone other than the account that placed the order. That is what the No user assign pack setting is for. The documentation explains that if a serial number should be consumed by someone other than the buyer, you need to enable the no-user-assignment mode.

When to Enable Consumption

Enable consumption when the code should follow the lifecycle "issued - presented - used." For an e-ticket, this is almost always necessary. For a HikaShop gift coupon, it is often unnecessary because the coupon itself is already handled by HikaShop. For an external license key, consumption depends on where activation happens: inside Joomla, in a third-party system, or manually by an operator.

User Validation During Consumption

The Consume will check/assign user setting means that a serial number already assigned to a user can only be consumed by that same user. If the serial number does not yet have a user, it will be linked to whoever performs the consumption, and guest access may be rejected. That is good for personal licenses, but bad for a gift ticket that should be used by someone else.

Before launch, answer one question: "Who will be standing at the code-check screen?" If it is the buyer in their own account, user assignment makes sense. If it is an administrator, entry staff member, or gift recipient, the setting should match the real workflow.

Roles and Access for Code Validation

For consumable codes, decide in advance who is allowed to validate and redeem them. If a staff member handles the check, they need a clear path in the admin area or public site, but not necessarily full store access. If the check happens at an event entrance, the interface should be as simple as possible: a code field, the validation result, and an obvious status like "already used" or "allow entry."

Do not give unnecessary permissions just because it makes one ticket easier to test. In Joomla, access should be limited through user groups and built-in permissions rather than through a shared administrator account. This is especially important with HikaSerial. A person who redeems tickets should not be able to accidentally change generators, packs, or orders.

After configuring the role, run two tests: one as the buyer and one as the validation staff member. The buyer should be able to see their code but not manage packs. The staff member should be able to validate the code without getting access to orders and financial data unless their job actually requires it.

What to Check After Configuring Consumption

1. The code appears after order confirmation and has a status that can be consumed.
2. The user or staff member sees the consumption form in the correct place on the site.
3. The code changes status after successful use.
4. Repeated use of the same code is blocked if the scenario is one-time only.
5. A gift code works for the recipient if the mode without hard buyer assignment is enabled.

Practical Scenario: Selling a Gift Card With a Code and an Image

Below is a full example that ties together the settings from the previous sections. It does not replace the official documentation, but it helps illustrate the correct order of actions and the key checkpoints. Scenario: a HikaShop store sells a gift card, and after order confirmation the customer receives a unique coupon plus a certificate image by email or as a downloadable file.

Goal

Create a product called "Gift Card" that, after order confirmation, generates an individual HikaShop coupon, shows the code to the buyer, and creates a dynamic certificate image through Attach Serial.

Preparation

• HikaShop is installed, and a test order can be manually moved to a confirmed status.
• A HikaShop template coupon exists and will be used by the coupon generator.
• You have a certificate image with empty space for the code, QR code, and a short instruction.
• You know which order statuses represent a confirmed purchase.

Steps

1. In HikaSerial configuration, check Assignable order statuses and the customer display settings for serial numbers.
2. Create a Coupon generator configuration, set the template coupon Discount coupon id, and define the serial number format.
3. Create a new pack, select the coupon generator, and keep the pack published.
4. Create or open the "Gift Card" product in HikaShop and add the HikaSerial pack to it.
5. Create an Attach Serial configuration, select the packs, set the image path, choose the font, and define the content lines.
6. Add the serial data in large text and a QR code containing the URL or data your scenario actually needs.
7. Place a test order and manually move it to a confirmed status.
8. Check the order in the admin panel, the customer email, the customer account, and coupon redemption in a new cart.

Expected Result

The order details should display a serial code. HikaShop should create an individual coupon from the template. The buyer should receive the code in the intended place, and the dynamic image should contain a readable code and a valid QR code or barcode. If download mode is enabled, the file should be available from the order details.

A Common Blocking Detail

A test order in Created status does not prove the setup is broken. If the code does not appear, first move the order into a status included in Assignable order statuses. If the code appears only after manual confirmation, then the issue was not the generator, but the payment or order-status workflow.

How to Verify the Result Before Publishing the Product

HikaSerial testing should mimic the path of a real customer. It is not enough to see that a pack was saved. You need to go from product to order, from order to serial code, from code to email or customer account, and then to actual code usage. For a gift certificate, that means separate coupon testing. For a ticket, it means consumption testing. For an external code, it means validating it against the external system or required format.

Test Order Checklist

• The product is published and visible on the front end.
• The correct HikaSerial pack is linked to the product.
• The pack is published and contains either a generator or available serial data.
• The test order is created without HikaShop errors.
• The order is moved into a status that allows serial number assignment.
• The serial number appears in the order details in the admin panel.
• The customer can see the code in the intended location.
• The email does not show an empty area where the code should be or a broken attachment.
• The coupon, ticket, or external code does what it is supposed to do.
• Order cancellation or refund leads to the expected serial number status.

Testing After Configuration Changes

After changing the generator, pack, or statuses, do not test only the old order. Older orders may already have their codes, while new ones will follow different logic. Create a new test order and repeat the key checks. If you changed Attach Serial, regenerate or re-download the dynamic image through the available mechanism, because an old attachment may not reflect the updated coordinates or font.

If you changed refund logic, test the cancellation path separately. Move the test order from a confirmed status into a refund or cancellation status, then check what happened to the serial number. For licenses, you may want to keep the assignment. For test codes, it may make sense to return the code to the available pool.

Testing the Support Burden

After the technical test, it is useful to run a "support test." Ask someone who did not configure HikaSerial to open the email, find the code, understand the instruction, and complete the action: apply the coupon, present the ticket, or download the image. If they still have questions, the issue may not be the extension at all. It may be the wording in the email, the certificate caption, or the structure of the customer account.

For a gift certificate, add a short instruction next to the code: where to enter it, whether it can be partially used, and what to do if there is an error. For a ticket, explain whether the image must be printed or whether showing it on a screen is enough. For a license, specify where to activate the key. These explanations can live in language strings and templates so you do not need to edit extension files.

A good test result is when the customer path is clear without contacting support. HikaSerial provides the technical foundation, but the quality of the user experience depends on how clearly you explain the code to the buyer.

Safe Improvements Without Editing Extension Files

With HikaSerial, you should not invent hooks that do not exist or edit the component files directly. Safe improvements are usually made through settings, Joomla language overrides, HikaShop email templates, image preparation for Attach Serial, font selection, and a small CSS adjustment for front-end output if your theme supports custom styles.

Localizing Certificate Text

If the dynamic image should contain Russian instructions, use translatable strings instead of hard-coded text in extension files. The safe workflow is straightforward: create a key, add it through language overrides, use the Translation type in Attach Serial, and then test the result with a real order. Those overrides are much easier to preserve through HikaSerial updates.

Preparing CSS for the Serial Number Block

If the serial code is shown on the front end and your theme renders it too small, you can add a small CSS snippet to a custom Joomla template file. The example below is only a safe reference point. The classes on your site may differ, so inspect the actual output HTML in the browser first.

.hikaserial_serial_value,
.hikashop_order_serial {
  font-family: inherit;
  font-size: 1.05rem;
  font-weight: 600;
  letter-spacing: 0.04em;
  word-break: break-word;
}

.hikaserial_serial_value code,
.hikashop_order_serial code {
  padding: 0.2rem 0.35rem;
  border-radius: 4px;
  background: #f4f6f8;
}

The check is simple: open the order in the customer account, make sure the code is readable on desktop and mobile widths, then temporarily disable the CSS and confirm that HikaSerial logic does not depend on the styling. Rollback is easy: delete or comment out the added rules in the template's custom CSS.

When It Is Better Not to Add Code

Do not add PHP snippets for generating, assigning, or consuming serial numbers unless they are based on official developer documentation. A mistake in that logic can issue a code before payment, break assignment history, or make a coupon reusable again. For most stores, the built-in generators, packs, language overrides, and careful status testing are enough.

Why the Serial Code Does Not Appear and How to Find the Cause

HikaSerial troubleshooting is best done as a chain. Start with the order and its status, then the product and pack, then the code source, then customer visibility, and only after that move on to emails, templates, and dynamic images. That order saves time. Many problems look like "the email is broken" when in fact the code was never assigned because of the order status.

The Code Is Not Assigned After Purchase

Symptom: the order is created, the product is purchased, but there is no serial number in the order details. A likely cause is that the order never moved into a status listed in Assignable order statuses. This is especially common with test orders where payment is not completed all the way through.

Check the order status in HikaShop, manually move it into a confirmed status, and see whether the code appears. If it does, fix the status map or the payment workflow. If it still does not, move on to checking the pack and product.

The Pack Exists, but the Product Does Not Deliver a Code

Symptom: the generator and pack are configured, but a specific product still does not issue anything. A likely cause is that the pack is not linked to the product, the pack is unpublished, or the number of serial numbers per product line is set incorrectly.

Open the HikaShop product editor and check the serial packs section. Make sure the correct pack is selected and not an old test pack with a similar name. Verify that the pack is published and that it contains a generator or available codes.

The Serial Number Appears in the Admin Panel, but the Customer Cannot See It

Symptom: the administrator sees the code in the order, but the buyer does not see it in the customer account or email. A likely cause is that the current serial status is not included in the statuses visible to the customer. Check Display serials for customer and make sure it matches the Assigned and Used states if those are required in your workflow.

The Gift Certificate Creates a Code, but the Coupon Does Not Work

Symptom: the code is issued, but it does not apply as a cart discount. A likely cause is that the coupon generator was not used, the template coupon is incorrect, the template coupon restrictions do not fit, or the validity settings are wrong. Check Discount coupon id, the template coupon state, and the HikaShop discount rules.

The Dynamic Image Is Empty or Hard to Read

Symptom: the attachment exists, but the code, QR code, or barcode does not render correctly. Check the image path, file permissions, coordinates, area size, selected font, and data format. For barcodes, make sure the content is compatible with the selected type. For Russian text, use a font with Cyrillic support and test the result on a real order.

The Gift Recipient Cannot Redeem the Code

Symptom: the buyer received the code and passed it to someone else, but consumption fails. A likely cause is that the code is tied to the buyer while the scenario requires a different user to redeem it. Check the consumption settings, especially No user assign and user validation during consumption. If the code has already been issued, test the change with a new order so old assignments do not confuse the result.

After a Refund, the Code Unexpectedly Disappears or Becomes Available Again

Symptom: the serial number changes state in a way the administrator did not expect. Check whether the new order status is still in the assignable list, what value is selected for Unassigned serial status, whether removal of assignment data is enabled, and whether code reuse is actually required. For licenses, preserving history is usually safer. For test codes, a more permissive workflow may be acceptable.

Questions to Resolve Before Launching HikaSerial

Can You Use HikaSerial Without HikaShop?

In practice, the extension is built around HikaShop: products, orders, statuses, coupons, and serial number delivery all depend on the store layer. So before configuring HikaSerial, HikaShop should already be installed and verified.

Why Does the Code Appear Only After Manual Order Confirmation?

Because serial numbers are assigned only for statuses listed in Assignable order statuses. If a test order stays in the created state instead of a confirmed one, the code may never be issued. Configure the statuses to match your real payment workflow.

What Is Better: Importing Ready-Made Codes or Using a Generator?

If the codes already exist in an external system, import them or create them in the serial data database. If the code should be created at order time, use a generator. For HikaShop coupons, choose the coupon generator because it creates a working coupon, not just a string.

Can You Create a Gift Certificate as an Image?

Yes. That is exactly what Attach Serial is for. It takes a template image and places serial data, order elements, text, a QR code, or a barcode on top of it. The layout, coordinates, font, and format should all be tested with a real test order.

What Should You Do if the Barcode or QR Code Does Not Appear?

Check the data format, code type, coordinates, area size, and whether the content is compatible with the selected barcode. For QR codes, also verify error correction level and readability after printing or forwarding.

Can a Ticket Be Passed to Another Person?

Yes, if the scenario and pack settings allow it. For a ticket that will be used by someone other than the buyer, it is especially important to review No user assign and the consumption rules. Otherwise, the code may stay tied to the buyer's account.

Should You Enable Code Reuse After a Refund?

Not always. For licenses and tickets, preserving assignment history is often more important. For internal testing or certain external codes, reuse may be acceptable. The decision depends on Unassigned serial status and Remove data on unassigned.

Does HikaSerial Affect Product Page SEO?

The extension itself primarily works with orders and serial data, not with product SEO markup. But clear product pages, accurate emails, and an error-free checkout still matter indirectly. Do not promise an SEO benefit from HikaSerial itself. Focus on the user path and technical stability.

When HikaSerial Is the Right Choice

HikaSerial is worth using if your Joomla store already runs on HikaShop and you need to deliver unique data after purchase. The extension is especially effective for gift certificates, licenses, e-tickets, external codes, and consumable serial numbers. Its strength is not a single generate button, but the combination of packs, generators, order statuses, customer delivery, and result verification.

Before launch, do not try to configure everything at once. Build one test product, one pack, one generator, and one control order. Then test the email, customer account, dynamic image, coupon redemption, or code consumption. If that path works, you can scale the setup to other products and scenarios.

If, after reading this guide, you understand what type of serial data your store needs, which statuses should deliver the code, and how to verify the result with a test order, you can move on to installation and download HikaSerial for safe testing on a site copy or staging environment.