Skip to main content
Build a gaming-key reseller with your own branded storefront on top of Shoppex. Shoppex runs the catalog, serial pools, license keys, HWID binding, and PSP routing (including crypto). You own the UI, customer acquisition, and community.

Why Shoppex fits this segment

Built-in serial pools

Upload keys once, Shoppex issues the next available one on each sale and marks it consumed.

HWID binding and reset flow

/dev/v1/licenses/validate and HWID reset endpoints come ready β€” no need to build piracy controls yourself.

Multi-PSP + crypto without MoR

Connect your own PSP accounts (Stripe, PayPal, crypto gateways). Shoppex routes, but money lands on your accounts.

Fraud shield + blacklist

IP and email signals, shared blacklists, optional Turnstile β€” the friction that kills digital-key fraud.

Flow

  1. The buyer starts checkout on your storefront.
  2. Your backend creates the payment and passes fraud signals.
  3. The buyer pays in hosted checkout.
  4. Shoppex marks the order paid and consumes the next serial.
  5. Your webhook or dashboard shows the delivered key to the buyer.

Catalog setup

Configure products as SERIALS type and upload your key pool once:
const { data: product } = await shoppex.products.create({
  title: 'Game Key β€” Region EU',
  type: 'SERIALS',
  price: 29.99,
  currency: 'USD',
  serials: ['KEY-AAAA-BBBB', 'KEY-CCCC-DDDD'],
});
Stock decrements automatically on each paid order. To append more keys later, use POST /dev/v1/products/{id}/serials. Subscribe to product:stock to get a webhook when a product is running low.

Payment creation with fraud signals

Pass IP, user-agent, and language on POST /dev/v1/payments so Shoppex’s fraud shield can score the session. These are the fields that meaningfully reduce chargeback rates on digital-key sales:
const { data: payment } = await shoppex.payments.create({
  title: 'Game Key β€” Region EU',
  email: buyer.email,
  value: 29.99,
  currency: 'USD',
  return_url: 'https://your-site.com/orders/thanks',
  fraud_shield: {
    ip: request.headers.get('x-forwarded-for'),
    user_agent: request.headers.get('user-agent'),
    user_language: request.headers.get('accept-language'),
  },
});

License validation in a client tool

If you ship keys that validate against a server, expose a thin endpoint on your side that proxies to Shoppex:
// Your endpoint
export async function POST(req: Request) {
  const { key, hwid } = await req.json();
  const response = await shoppex.raw.POST<{ data: { status: string; expires_at: number | null } }>(
    '/dev/v1/licenses/validate',
    {
      body: {
        key,
        product_id: process.env.SHOPPEX_PRODUCT_ID!,
        hardware_id: hwid,
      },
    }
  );

  return Response.json({
    status: response.data.status,
    expires_at: response.data.expires_at,
  });
}
HWID reset (for legitimate hardware changes) is PATCH /dev/v1/licenses/keys/{key}/hwid. Surface it in your customer portal with rate limits you control.

Pitfalls

  • Out-of-stock during checkout β€” Shoppex won’t oversell a SERIALS pool, but a long-running checkout can fail at capture if stock hits zero. Watch product:stock and disable buy buttons below a threshold.
  • Region flags β€” gaming keys have regional restrictions. Model region as a variant so buyers pick one explicitly before payment, rather than handling it post-sale.
  • Chargeback tooling β€” use disputes.read scope and order:disputed webhooks to flag repeat-offender emails into the shared blacklist.

Architecture Reference

Any setup works β€” gaming resellers typically pick Setup B (Next.js SSR).

Dev API β€” Licenses

Validation, HWID binding, pool management.