Odigix

Role

The whole platform, front end and back end

Since

Late 2023, full-time since January 2026

Users

30,000+ registered

Stack today

Next.js, Laravel, custom admin, Laravel MCP

The problem

International gift cards (PlayStation, Steam, Apple, Netflix) aren't sold in Algerian shops, and Algerian bank and postal cards don't work on the platforms that sell them. For years, the alternative was Instagram DMs and WhatsApp groups: pay by hand, get the code as a screenshot, hope it's real.

Odigix set out to replace that with a proper store: search, pay with SlickPay or OneClick, and get the code in seconds. That means integrating local payment providers and building the layer around them, because no international gateway fills that gap.

How it evolved

1. Late 2023

   A Laravel API and pre-loaded codes

   A Quasar (Vue.js) storefront, a Laravel API and Laravel Nova for the admin. Every order was delivered from a stock of codes the admin had bought and entered beforehand.

   • Quasar
   • Laravel API
   • Laravel Nova

2. Then

   Direct ordering from providers

   Provider APIs plugged into the delivery pipeline, so a code can be bought the moment it's ordered. Local stock is still used first.

   • Provider APIs
   • Queues
   • Idempotency

3. Now

   A Next.js storefront and a custom admin

   Next.js for search traffic, a custom admin with SEO controls in place of Nova, and Laravel MCP so an AI assistant can work with the admin's data and actions.

   • Next.js
   • Inertia + React
   • Laravel MCP

From dead stock to direct ordering

In the first version, the only way to sell a code was to have bought it first. The admin bought codes in bulk and entered them into the stock, and orders were delivered from there. It worked, but it tied the business's cash up in codes, limited the catalog to what had been bought, and left whatever didn't sell sitting in stock.

Integrating providers changed the business more than the code. The stock no longer had to be large, and new products could join the catalog without being bought first.

How an order gets delivered

Once a payment is confirmed, delivery is a background job, not part of the checkout. The job looks for the code in local stock, buys it from a provider if there isn't one, and sends it to the customer. The demo below runs that job; pick a situation and place the order.

Code in local stockProvider times out onceIdempotency key

1. Payment
2. Queue
3. Local stock
4. Provider API
5. Delivery

Pick a situation, then place the order.

Place order

Four rules carry most of the weight:

• Local stock first. Codes already bought are used before new ones are ordered, so existing stock sells instead of ageing.
• Delivery runs on queues. Jobs run on Laravel Horizon. A slow provider delays one order without holding up the checkout, and a failed job is retried.
• Every provider purchase carries an idempotency key, one per order item. A provider can charge and then fail to answer in time. The retry carries the same key, so it can't become a second purchase. Gift card codes are as good as cash, so buying one twice loses real money.
• Several provider APIs, each with its own formats and failure modes. The delivery job has to be correct when a provider is slow or down, not only fast when it's up.

The code is then shown on screen and sent by email and by WhatsApp, through an Evolution API integration. If the customer closes the page, it stays in their order history.

Payments

SlickPay and OneClick confirm payments differently, on different timings. A payment only counts once Odigix has checked it with the provider, and the same payment arriving twice must change nothing.

1. 01

   The customer pays

   On SlickPay or OneClick, on the provider's own payment page.

2. 02

   Two signals come back

   The customer returns to Odigix and the provider sends a notification. Neither one is trusted on its own.

3. 03

   The status is checked with the provider

   Odigix asks the provider directly whether the payment went through, whichever signal arrived first.

4. 04

   The payment is recorded once

   Idempotent

   Each payment is keyed by provider and reference. A notification sent twice, or a double click, finds the payment already recorded and changes nothing.

5. 05

   It's matched to exactly one order

   No guessing

   By the reference Odigix sent to the provider. If it doesn't match exactly one order, it goes to a person, never to the closest candidate: gift cards come in fixed amounts, so identical totals are common.

6. 06

   The order is paid, delivery starts

   The order is marked as paid and the delivery job described above is queued.

Today: Next.js, a custom admin and MCP

• The storefront moved to Next.js for search. Every product and category now has a server-rendered page that search engines can crawl, which the single-page Quasar app didn't give.
• A custom admin replaced Laravel Nova. It's built with Laravel, Inertia and React, and it lets the team manage the site's SEO from the dashboard.
• Laravel MCP in the admin. Admin operations are exposed as MCP tools, so an AI assistant can work with the same data and actions as the admin team.

Results

• A leading digital gift card provider in Algeria, with 30,000+ registered users
• Orders delivered automatically, from local stock or straight from a provider
• A catalog that grows without buying stock up front
• A storefront built for search, and an admin that AI assistants can work with through MCP