DEV Community: Clarence Yu

Removing the vig: the math behind a fair sports-betting probability (in plain JS)

Clarence Yu — Fri, 05 Jun 2026 15:18:13 +0000

If you've ever looked at sportsbook odds and wondered "what does the bookmaker actually think the probability is?" — the number you see is not it. It's inflated by the vig (a.k.a. juice / margin), the cut the book bakes into every market. Here's the math to recover the fair number, with drop-in JS you can paste into any project.

1. Odds → implied probability

Decimal odds D map to an implied probability:

const impliedProb = 1 / D;   // D = 2.00 -> 0.50 (50%)

The catch: in a 2-way market the two implied probabilities sum to more than 100%. That overround is the vig.

// 1.91 / 1.91 market
const pa = 1 / 1.91; // 0.5236
const pb = 1 / 1.91; // 0.5236
const overround = pa + pb;   // 1.0471  -> 4.71% margin

2. Stripping the vig (normalisation method)

The simplest devig is proportional normalisation — divide each side by the overround:

const fairA = pa / (pa + pb); // 0.50  -> the "fair" no-vig probability

Now fairA is the market's actual estimate, vig removed. (There are fancier methods — Shin, logarithmic, power — but normalisation is the honest baseline.)

3. Expected Value: is it a value bet?

A bet only makes long-run sense if your probability estimate beats the offered odds:

const EV = yourProb * D - 1;  // > 0 means positive expectation

4. Sizing it with Kelly

The Kelly criterion gives the bankroll fraction that maximises long-run growth:

// b = D - 1, p = win prob, q = 1 - p
const kelly = (b * p - q) / b;
// most people use half- or quarter-Kelly to cut variance

That's the entire toolkit — four formulas. You can wire them into a single form in ~100 lines of vanilla JS with zero dependencies.

The hard part isn't the math

Every formula above takes your estimated win probability as input — and that estimate is the whole game. Turning raw signals (Elo ratings, expected goals, market consensus, recent form) into one calibrated probability is where the real modelling happens.

If you want to see how a multi-signal model documents that process, this write-up of a five-signal fusion approach is a solid reference: OkayAI's methodology. For the expected-goals piece specifically, this xG explainer covers how shot quality becomes a probability — it comes from OddsForge, the analysis platform OkayAI is built on.

Educational only — the vig means the long-run edge is against you unless you consistently find genuine value. Bet responsibly.

The Math Behind Prediction Market Prices: Implied Probability, the Vig, EV and Kelly (in plain JS)

Clarence Yu — Fri, 05 Jun 2026 15:09:47 +0000

If you've looked at Polymarket, Kalshi or Manifold and wondered what a "YES share at $0.40" actually means — or why two opposite outcomes don't add up to 100% — this post walks through the four pieces of math you need, with copy-pasteable JavaScript. I recently built a small zero-dependency calculator for exactly this, and the functions below are the heart of it.

1. The price is the probability

A binary prediction-market contract settles at $1 if the event happens and $0 if it doesn't. So the current YES price, in dollars, is just the market's implied probability:

// price in cents (0–100) → implied probability (0–1)
const impliedProb = (priceCents) => priceCents / 100;

impliedProb(40); // 0.40  → the market says 40%

No separate "odds" object, no vig baked into a moneyline — the number on the screen is the probability. That's what makes prediction markets so readable compared to a sportsbook.

If you do want to cross-check against sportsbook formats:

const toOdds = (p) => ({
  decimal: 1 / p,
  american: p > 0.5 ? -Math.round(100 * p / (1 - p))
                    :  Math.round(100 * (1 - p) / p),
  // fractional: odds-against = (1 - p) / p
});

toOdds(0.40); // { decimal: 2.5, american: 150 }

2. Removing the vig (overround)

Here's the gotcha that trips up newcomers: the YES price and the NO price almost never sum to exactly 100¢. The excess is the vig (a.k.a. overround) — the margin baked into the two-sided market. Before you compare a price across two platforms, you have to strip it out:

function deVig(yesCents, noCents) {
  const y = yesCents / 100, n = noCents / 100;
  const sum = y + n;
  return {
    fairYes: y / sum,          // normalised, vig removed
    fairNo:  n / sum,
    overround: sum - 1,        // the vig itself
  };
}

deVig(56, 47);
// { fairYes: 0.5437, fairNo: 0.4563, overround: 0.03 }
// raw 56% looks like the answer, but the *fair* number is 54.4%

Skip this step and you'll think you found an edge that's really just two different vigs. I go deeper on this on the reference page for implied probability.

3. Expected value and edge

Once you have a fair probability you trust (your own estimate p), buying a YES share at cost c has a dead-simple EV:

function ev(costCents, trueProbPct, stake) {
  const c = costCents / 100, p = trueProbPct / 100;
  const shares = stake / c;        // each share pays $1 on YES
  return {
    edge: p - c,                   // your advantage, per $1 of payout
    evDollars: shares * (p - c),   // expected profit on this stake
    roi: (p - c) / c,
  };
}

ev(40, 50, 100);
// { edge: 0.10, evDollars: 25, roi: 0.25 }

The trap: positive EV is an average over many independent, correctly-estimated bets — never a guarantee on any single market. The number is only as good as your p.

4. Kelly sizing

EV tells you whether to bet; Kelly tells you how much. For a binary contract bought at price c with true probability p, the full-Kelly fraction of bankroll is:

function kelly(costCents, trueProbPct, bankroll, fraction = 0.5) {
  const c = costCents / 100, p = trueProbPct / 100;
  const full = (p - c) / (1 - c);          // full-Kelly fraction
  const applied = Math.max(0, full * fraction);
  return { fullPct: full, stake: applied * bankroll };
}

kelly(40, 50, 1000, 0.5);
// { fullPct: 0.1667, stake: 83.33 }  → half-Kelly on a $1000 bankroll

Real-world probability estimates are noisy, so almost nobody runs full Kelly — quarter-to-half Kelly cuts the variance (and the gut-wrenching drawdowns) dramatically while keeping most of the growth.

Putting it together

Those four functions — impliedProb, deVig, ev, kelly — are basically the whole toolkit. No dependencies, runs anywhere. I wired them into a single-page UI you can play with here: prediction market probability calculator. And if you want live numbers to feed into it, U-Town Market tracks real YES/NO probabilities from Polymarket, Kalshi and Manifold and refreshes every few hours.

A couple of implementation notes if you build your own:

Clamp probabilities to [0.0001, 0.9999] before converting to odds, or you'll hit divide-by-zero at the extremes.
Validate the de-vig inputs — if a user types a YES + NO that sum below 100 you've got an arbitrage (or bad data), worth flagging in the UI.
Keep it dependency-free. This is arithmetic; pulling in a stats library is overkill and bloats your bundle.

Happy to answer questions in the comments — and if you've built something similar for prediction markets, I'd love to see how you handled cross-platform de-vigging.

How We Built a Dual-Fire Meta CAPI Tracking System for iGaming Landing Pages

Clarence Yu — Fri, 05 Jun 2026 15:07:04 +0000

If you run paid acquisition on Meta for landing pages, you already know the problem: iOS 14.5 gutted browser-side tracking. Meta's answer is the Conversions API (CAPI) — server-side event delivery that bypasses ad blockers and browser restrictions. But "just add CAPI" is about 20% of the actual work. The other 80% is deduplication, cookie persistence across sessions, and making sure your Event Match Quality (EMQ) score doesn't tank because your fbc parameter keeps changing.

This article walks through the dual-fire tracking system we built at RedClaw for high-traffic iGaming landing pages. We'll cover the architecture, the GTM setup, the Cloud Function that sends server-side events, and the specific bugs that cost us days of debugging.

Architecture Overview

The system has three layers:

User lands on LP (with ?fbclid=xxx)
        |
        v
  [Browser Layer]
  GTM Web Container --> fbq('track', 'Lead')
  + dataLayer push with eventID, fbc, fbp
        |
        v
  [Server Layer]  
  LP JavaScript --> POST to Cloud Function
  Cloud Function --> Meta Conversions API
  (same eventID for dedup)
        |
        v
  [Meta receives both events, deduplicates by event_id]

Both the browser Pixel and the server CAPI send the same event with the same event_id. Meta deduplicates them. If the browser event gets blocked (ad blocker, ITP, network failure), the server event still lands. If the server event fails (function cold start, timeout), the browser event covers it. That's the dual-fire guarantee.

Step 1: Capturing fbclid and Building Persistent fbc/fbp

This is where most implementations silently fail. The fbc (click ID) and fbp (browser ID) parameters are the backbone of Meta's attribution. If you reconstruct fbc with Date.now() every time you need it, the timestamp changes between the browser event and the server event. Meta sees two different fbc values for the same click and deduplication breaks. Your EMQ score drops from 8 to 5, and your cost per result climbs.

The fix: capture fbc once, freeze the timestamp, and persist it across sessions with dual-write to both cookie and localStorage.

// tracking.js — runs on LP load

function captureFbclid() {
  const params = new URLSearchParams(window.location.search);
  const fbclid = params.get('fbclid');
  if (!fbclid) return;

  localStorage.setItem('fbclid', fbclid);
  const fbc = `fb.1.${Date.now()}.${fbclid}`;
  localStorage.setItem('fbc', fbc);
  document.cookie = `_fbc=${fbc}; max-age=${90 * 86400}; path=/; SameSite=Lax`;
}

function ensureFbc() {
  const cookieFbc = getCookie('_fbc');
  if (cookieFbc) return cookieFbc;

  const storedFbc = localStorage.getItem('fbc');
  if (storedFbc) {
    document.cookie = `_fbc=${storedFbc}; max-age=${90 * 86400}; path=/; SameSite=Lax`;
    return storedFbc;
  }

  const fbclid = localStorage.getItem('fbclid');
  if (fbclid) {
    const fbc = `fb.1.${Date.now()}.${fbclid}`;
    localStorage.setItem('fbc', fbc);
    document.cookie = `_fbc=${fbc}; max-age=${90 * 86400}; path=/; SameSite=Lax`;
    return fbc;
  }
  return '';
}

function ensureFbp() {
  const cookieFbp = getCookie('_fbp');
  if (cookieFbp) return cookieFbp;

  const stored = localStorage.getItem('fbp');
  if (stored) {
    document.cookie = `_fbp=${stored}; max-age=${90 * 86400}; path=/; SameSite=Lax`;
    return stored;
  }

  const rand10 = Math.floor(Math.random() * 9e9) + 1e9;
  const fbp = `fb.1.${Date.now()}.${rand10}`;
  localStorage.setItem('fbp', fbp);
  document.cookie = `_fbp=${fbp}; max-age=${90 * 86400}; path=/; SameSite=Lax`;
  return fbp;
}

Why dual-write cookie + localStorage? Safari ITP and Firefox ETP clear first-party cookies set by JavaScript after 7 days. If a user clicks an ad, leaves, and comes back on day 10, their _fbc cookie is gone. But localStorage survives. The dual-write acts as a fallback chain: cookie first (because Meta's own SDK reads cookies), localStorage as backup (because browsers don't auto-purge it).

Step 2: The Browser-Side Pixel (GTM Web Container)

The GTM web container handles the browser-side fire. We use a Custom HTML tag that pushes a dataLayer event with all the parameters the server side will also need.

When a conversion event fires (e.g., CTA click leading to registration):

// In the LP's click handler
function handleCtaClick(ctaPosition) {
  const eventId = crypto.randomUUID();
  const fbc = ensureFbc();
  const fbp = ensureFbp();

  // 1. Browser-side: fire Pixel
  fbq('track', 'Lead', {
    content_name: ctaPosition,
  }, { eventID: eventId });

  // 2. Push to dataLayer for GTM GA4 tag
  window.dataLayer.push({
    event: 'click_reg',
    eventID: eventId,
    content_name: ctaPosition,
    fbc: fbc,
    fbp: fbp,
  });

  // 3. Server-side: fire CAPI via Cloud Function
  sendCAPIEvent('Lead', {
    event_id: eventId,
    fbc: fbc,
    fbp: fbp,
    content_name: ctaPosition,
    event_source_url: window.location.href,
    user_agent: navigator.userAgent,
  });
}

The critical detail: eventID in the browser fbq() call must exactly match event_id in the CAPI payload. This is how Meta deduplicates. Use crypto.randomUUID() — it's available in all modern browsers and produces collision-free IDs.

Step 3: The Cloud Function (Server-Side CAPI)

The Cloud Function receives the event data from the LP and forwards it to Meta's Conversions API. We deploy this on Google Cloud Functions (Node.js 20, asia-east1 region for low latency to Meta's APAC endpoints).

The function builds the Meta CAPI event payload with event_name, event_time, event_id, user data (fbc, fbp, client_user_agent, client_ip_address), and fires to all configured pixels in parallel using Promise.allSettled.

Why a dedicated Cloud Function instead of sGTM? We've run both. Server-side GTM (sGTM) with community templates like Stape's Meta CAPI tag has a nasty default behavior: unknown events get mapped to Lead. That means every page_view, scroll, and user_engagement event flowing through your server container turns into a phantom Lead. We've seen LPs reporting 350 Leads/day when actual registrations were 7. The inflation ratio was 50:1.

With a dedicated Cloud Function, you control exactly which events get sent and what they're called. There's no "default event name" footgun.

Step 4: The LP-Side Sender

The LP calls the Cloud Function with navigator.sendBeacon for fire-and-forget reliability (the event still sends even if the user navigates away immediately after clicking).

function sendCAPIEvent(eventName, params) {
  const CAPI_ENDPOINT = 'https://your-function-url.a.run.app';
  const payload = JSON.stringify({
    event_name: eventName,
    event_id: params.event_id,
    event_source_url: params.event_source_url || window.location.href,
    user_agent: params.user_agent || navigator.userAgent,
    fbc: params.fbc || ensureFbc(),
    fbp: params.fbp || ensureFbp(),
    content_name: params.content_name,
  });

  const sent = navigator.sendBeacon(CAPI_ENDPOINT, new Blob([payload], {
    type: 'application/json',
  }));

  if (!sent) {
    fetch(CAPI_ENDPOINT, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: payload,
      keepalive: true,
    }).catch(() => {});
  }
}

Warning: Both sendBeacon and fetch with keepalive fail silently. Always verify server-side delivery by checking Meta's Pixel diagnostics or querying the Graph API.

Lessons Learned in Production

After running this system across multiple client LPs, here's what bit us:

1. GTM Lookup Table defaultValue = "Lead" is a disaster. If you use a GTM Lookup Table variable to map dataLayer event names to Meta standard events, never set the default value to Lead. Every GTM built-in event that doesn't match your lookup will fire as a Lead. Set the default to an empty string and add an explicit trigger filter like ^click_reg$.

2. Cloud Function cold starts can delay server events by 2-3 seconds. Meta allows up to a 5-minute delay between event_time and delivery, so this is fine for attribution. Use min_instances: 1 in production to keep the function warm.

3. client_ip_address is required for EMQ but tricky behind CDNs. Cloud Functions give you req.ip, but if the LP is behind Cloudflare or Firebase Hosting with a CDN, you'll get the CDN's IP, not the user's. Pass X-Forwarded-For from the LP request to the Cloud Function.

4. Dual-pixel setups need separate access tokens. Each pixel must be written with a token that has ads_management scope and is asset-assigned to that specific pixel in Business Manager. A token assigned to Pixel A can't write events to Pixel B, even if they're in the same BM.

Wrapping Up

The dual-fire pattern isn't complicated in theory — send the same event from both browser and server, share an event_id, let Meta deduplicate. The complexity lives in the details: freezing fbc timestamps, surviving ITP cookie purges, avoiding phantom Lead inflation from overly broad GTM triggers, and silently validating that the server channel is actually delivering.

If you're running performance campaigns where every conversion matters — especially in verticals like iGaming, crypto, or forex where ad accounts are volatile and tracking breakage directly translates to wasted spend — this kind of infrastructure pays for itself within the first week.

Built by RedClaw

This tracking architecture is part of the growth infrastructure we build at RedClaw, a performance marketing agency specializing in iGaming, crypto, and forex verticals. We handle media buying, landing page development, and the tracking plumbing that connects them.

If you're dealing with Meta tracking issues, ad account instability, or need a CAPI setup that actually holds up in production, reach out.

How We Built a Dual-Fire Meta CAPI Tracking System for iGaming Landing Pages

Clarence Yu — Fri, 05 Jun 2026 14:26:00 +0000

Architecture Overview

The system has three layers:

User lands on LP (with ?fbclid=xxx)
        |
        v
  [Browser Layer]
  GTM Web Container --> fbq('track', 'Lead')
  + dataLayer push with eventID, fbc, fbp
        |
        v
  [Server Layer]
  LP JavaScript --> POST to Cloud Function
  Cloud Function --> Meta Conversions API
  (same eventID for dedup)
        |
        v
  [Meta receives both events, deduplicates by event_id]

Step 1: Capturing fbclid and Building Persistent fbc/fbp

This is where most implementations silently fail. The fbc (click ID) and fbp (browser ID) parameters are the backbone of Meta's attribution. If you reconstruct fbc with Date.now() every time, the timestamp changes between browser and server events. Meta sees two different fbc values and deduplication breaks. Your EMQ score drops from 8 to 5.

The fix: capture fbc once, freeze the timestamp, and persist it across sessions with dual-write to both cookie and localStorage.

function captureFbclid() {
  const params = new URLSearchParams(window.location.search);
  const fbclid = params.get('fbclid');
  if (!fbclid) return;
  localStorage.setItem('fbclid', fbclid);
  const fbc = 'fb.1.' + Date.now() + '.' + fbclid;
  localStorage.setItem('fbc', fbc);
  document.cookie = '_fbc=' + fbc + '; max-age=' + (90*86400) + '; path=/; SameSite=Lax';
}

function ensureFbc() {
  const cookieFbc = getCookie('_fbc');
  if (cookieFbc) return cookieFbc;
  const storedFbc = localStorage.getItem('fbc');
  if (storedFbc) {
    document.cookie = '_fbc=' + storedFbc + '; max-age=' + (90*86400) + '; path=/; SameSite=Lax';
    return storedFbc;
  }
  const fbclid = localStorage.getItem('fbclid');
  if (fbclid) {
    const fbc = 'fb.1.' + Date.now() + '.' + fbclid;
    localStorage.setItem('fbc', fbc);
    document.cookie = '_fbc=' + fbc + '; max-age=' + (90*86400) + '; path=/; SameSite=Lax';
    return fbc;
  }
  return '';
}

Why dual-write cookie + localStorage? Safari ITP clears first-party JS cookies after 7 days. If a user clicks an ad and returns on day 10, _fbc is gone. But localStorage survives.

Step 2: The CTA Click Handler

When a conversion fires, we generate a shared event_id and send it to both browser Pixel and server CAPI:

function handleCtaClick(ctaPosition) {
  const eventId = crypto.randomUUID();
  const fbc = ensureFbc();
  const fbp = ensureFbp();

  // Browser-side Pixel
  fbq('track', 'Lead', {
    content_name: ctaPosition,
  }, { eventID: eventId });

  // Server-side CAPI
  sendCAPIEvent('Lead', {
    event_id: eventId,
    fbc: fbc,
    fbp: fbp,
    content_name: ctaPosition,
    event_source_url: window.location.href,
    user_agent: navigator.userAgent,
  });
}

eventID in the browser fbq() call must exactly match event_id in the CAPI payload. This is how Meta deduplicates.

Step 3: The Server-Side Sender

The LP calls the Cloud Function with navigator.sendBeacon for fire-and-forget reliability:

function sendCAPIEvent(eventName, params) {
  const CAPI_ENDPOINT = 'https://your-function-url.a.run.app';
  const payload = JSON.stringify({
    event_name: eventName,
    event_id: params.event_id,
    event_source_url: params.event_source_url || window.location.href,
    user_agent: params.user_agent || navigator.userAgent,
    fbc: params.fbc || ensureFbc(),
    fbp: params.fbp || ensureFbp(),
    content_name: params.content_name,
  });
  const sent = navigator.sendBeacon(CAPI_ENDPOINT, new Blob([payload], { type: 'application/json' }));
  if (!sent) {
    fetch(CAPI_ENDPOINT, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: payload, keepalive: true }).catch(() => {});
  }
}

Warning: Both sendBeacon and fetch(keepalive) fail silently. Always verify server-side delivery via Meta's Pixel diagnostics or the Graph API.

Why Not sGTM?

Server-side GTM with Stape's Meta CAPI template has a nasty default: unknown events map to Lead. Every page_view, scroll, user_engagement becomes a phantom Lead. We saw LPs reporting 350 Leads/day when actual registrations were 7. With a dedicated Cloud Function, you control exactly which events fire.

Lessons Learned

1. GTM Lookup Table default = "Lead" is a disaster. Set default to empty string, add trigger filter ^click_reg$.

2. Cold starts delay server events 2-3 seconds. Meta allows 5-min delay, so it's fine. Use min_instances: 1 in prod.

3. client_ip_address behind CDNs. Pass X-Forwarded-For from the LP, not req.ip.

4. Dual-pixel = separate tokens. Each pixel needs its own asset-assigned token with ads_management scope.

Wrapping Up

The dual-fire pattern isn't complicated in theory — send the same event from both browser and server, share an event_id, let Meta deduplicate. The complexity is in the details: freezing fbc timestamps, surviving ITP, avoiding phantom Lead inflation, and silently validating server delivery.

If you're running performance campaigns where every conversion matters — especially in iGaming, crypto, or forex where tracking breakage = wasted spend — this infrastructure pays for itself in week one.

Built by RedClaw — performance marketing for iGaming, crypto, and forex. We handle media buying, landing pages, and the tracking plumbing that connects them. Get in touch.

How I Built a Trilingual Astro Site for Indian Card Games (and What I Learned About i18n SEO)

Clarence Yu — Fri, 05 Jun 2026 13:38:18 +0000

When I set out to build a comprehensive guide site for traditional Indian card games, I knew two things: it had to be fast, and it had to serve three languages natively — English, Hindi, and Bengali. What I didn't know was how deep the rabbit hole of multilingual SEO goes.

Here's the full technical breakdown of building DesiTaashGuide.com with Astro 5 on Cloudflare Pages, and every i18n lesson I learned the hard way.

Why Astro 5?

I evaluated Next.js, Nuxt, and SvelteKit before landing on Astro. The deciding factors:

Content-first architecture. My site is 113+ long-form articles. Astro's content collections with MDX support meant I could write articles in .mdx, validate frontmatter with Zod schemas, and get type-safe content at build time. No runtime overhead for what is fundamentally a content site.
Zero JS by default. Each article page ships roughly 0 KB of client-side JavaScript unless I explicitly opt in with client:load or client:visible. For a content-heavy site targeting users across India — including tier-2 and tier-3 cities with inconsistent 4G — this matters enormously.
Built-in i18n routing. Astro 5's i18n config handles locale-prefixed routes out of the box. English lives at /games/teen-patti-hand-rankings, Hindi at /hi/games/teen-patti-hand-rankings-hindi, and Bengali at /bn/games/teen-patti-hand-rankings-bengali.

The i18n Architecture

Here's the simplified routing config:

// astro.config.mjs
export default defineConfig({
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'hi', 'bn'],
    routing: {
      prefixDefaultLocale: false,
    },
  },
});

English pages have no prefix (cleaner URLs, better for the primary audience). Hindi and Bengali get /hi/ and /bn/ prefixes respectively.

Content Collections per Locale

Each locale has its own content directory:

src/content/games/
  teen-patti-hand-rankings.mdx          # English
  teen-patti-hand-rankings-hindi.mdx    # Hindi
  teen-patti-hand-rankings-bengali.mdx  # Bengali

The frontmatter includes a locale field and a translationKey that links the three versions together:

---
title: "Teen Patti Hand Rankings"
locale: "en"
translationKey: "teen-patti-hand-rankings"
---

This translationKey is what powers the hreflang generation.

Hreflang Triangulation — The Hard Part

Getting hreflang right is deceptively difficult. Google's documentation makes it sound simple: add <link rel="alternate" hreflang="x" href="..." /> tags. In practice, it's a directed graph problem.

The rule: Every page in a translation group must reference every other page in that group, including itself. If page A links to page B as its Hindi alternate, page B must link back to page A as its English alternate. Miss one link, and Google may ignore the entire set.

I built a utility that, at build time, resolves the full translation cluster for each page:

function getHreflangLinks(currentPage: CollectionEntry) {
  const key = currentPage.data.translationKey;
  const cluster = allPages.filter(p => p.data.translationKey === key);

  return cluster.map(page => ({
    hreflang: page.data.locale,
    href: getAbsoluteUrl(page),
  }));
}

Each page's <head> then renders the full set:

<link rel="alternate" hreflang="en" href="https://www.desitaashguide.com/games/teen-patti-hand-rankings" />
<link rel="alternate" hreflang="hi" href="https://www.desitaashguide.com/hi/games/teen-patti-hand-rankings-hindi" />
<link rel="alternate" hreflang="bn" href="https://www.desitaashguide.com/bn/games/teen-patti-hand-rankings-bengali" />
<link rel="alternate" hreflang="x-default" href="https://www.desitaashguide.com/games/teen-patti-hand-rankings" />

The x-default tag points to the English version as the fallback for any locale not explicitly served.

Validation

I wrote a build-time check that fails the deploy if any hreflang cluster is incomplete. It catches the most common mistake: adding a Hindi article but forgetting to update the English and Bengali counterparts.

Schema.org for MobileApplication Reviews

Since many articles review specific gaming apps, I implemented MobileApplication and Review schema markup:

{
  "@context": "https://schema.org",
  "@type": "Review",
  "itemReviewed": {
    "@type": "MobileApplication",
    "name": "Teen Patti Gold",
    "operatingSystem": "Android, iOS",
    "applicationCategory": "GameApplication"
  },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "4.2",
    "bestRating": "5"
  }
}

This generates rich snippets in Google search results — star ratings, app names, and platform info appear directly in the SERP.

Performance: The Lighthouse 100 Journey

Getting a perfect Lighthouse score on a content-heavy site requires discipline at every layer.

Images. All images use Astro's <Image /> component, which generates WebP/AVIF variants at build time with proper srcset and sizes attributes.

Fonts. I subset Noto Sans Devanagari and Noto Sans Bengali to only the glyphs actually used. This reduced font payloads from ~180 KB to ~45 KB per script.

Cloudflare Pages. The CDN edge caching means users in Mumbai, Kolkata, and Dhaka hit local PoPs. Time to First Byte is consistently under 50ms.

The result: Lighthouse 100 across all four categories on every page I've tested.

The Open-Source Calculator

I open-sourced a Teen Patti probability calculator as a standalone tool. It computes exact probabilities for all hand types from the C(52,3) = 22,100 possible combinations. Try the live demo.

It's vanilla JS, no frameworks, deployable anywhere. Fork it if you're building anything card-game related.

Lessons Learned

hreflang is fragile. One missing backlink breaks the entire cluster. Automate validation.
MDX 3 is strict. Curly braces, angle brackets, and certain Unicode characters crash the parser.
Build-time validation saves deploys. Zod schemas for frontmatter, hreflang checks, and broken link detection — all run before astro build succeeds.
Subset your Indic fonts. Your users on Jio connections will thank you.
Content collections scale well. At 113 articles across three languages, build times are still under 30 seconds.

Check out the live site at desitaashguide.com. Full probability math guide here.

If you're building multilingual content sites with Astro, happy to answer questions in the comments.

The Hidden PSP Tax on PayID Casino Deposits: 1-3% Spread Nobody Reports

Clarence Yu — Fri, 05 Jun 2026 13:38:05 +0000

_fintech, payments, australia, secur## TL;DR

When Australian players deposit at offshore casinos via PayID, they think the transfer is free. It isn't. A 1-3% spread is applied at the PSP (Payment Service Provider) intermediary layer — Picksellpay, Volt, Nodapay, MiFinity — during the AUD-to-EUR currency conversion. On a A$1,000 deposit, that's A$10-30 of invisible margin.

We tested this across 15 casinos. Nobody else reports it.

What is PayID?

PayID is Australia's real-time payment addressing system built on the New Payments Platform (NPP). Instead of sharing your BSB and account number, you register an email address or phone number as your PayID identifier. Transfers settle in seconds, 24/7/365.

For the 110+ participating banks, PayID is infrastructure — not a product. The NPP rail itself charges no consumer-facing fees.

The Problem: PSP Intermediary Layer

When you send a PayID transfer to an offshore casino, the money doesn't go directly to the operator. It routes through a Payment Service Provider (PSP) that acts as the bridge between your Australian bank and the operator's working balance (typically EUR-denominated).

These PSPs include:

Picksellpay — handles Wild Fortune's primary PayID corridor
Volt (now Volt.io) — bank-to-bank payment infrastructure
Nodapay — AU-region overlay for deposit corridors
MiFinity — e-wallet intermediary with fiat-to-operator bridge

The AUD-to-EUR conversion happens at this PSP layer. And the exchange rate applied is not the mid-market rate. It carries a 1-3% spread that the PSP retains as margin.

Our Testing Methodology

We deposited real AUD at 15 offshore casinos accepting PayID and compared the credited balance against the European Central Bank (ECB) reference rate on the same day.

Casino	Deposit (AUD)	Expected (EUR)	Actual (EUR)	Spread
Wild Fortune	A$200	€121.46	€119.27	1.8%
Goldenbet	A$200	€121.46	€118.11	2.8%
Joe Fortune	A$200 (AUD-native)	A$200	A$200	0%

Joe Fortune is AUD-native — no currency conversion, no PSP spread. The others all apply a hidden margin.

The Bank Blocking Gap

Here's the other finding nobody reports: Australian bank gambling blocks (ANZ, NAB, Westpac, CommBank, Macquarie, ING) operate at the card merchant-category-code (MCC 7993/7995) level. They do not block PayID/NPP transfers.

This is a responsible gambling policy gap. A player who has self-excluded via their bank's gambling block can still deposit via PayID. The NPP does not carry MCC metadata, so the block doesn't fire.

Why This Matters for Developers

If you're building payment integrations for the AU market — whether gambling, fintech, or e-commerce — understanding the PSP intermediary layer matters:

NPP is free at the rail level but not at the PSP level — your users may be paying hidden margin
Bank gambling blocks don't extend to NPP — if you're building responsible-gambling tools, you need to account for this gap
PSP transparency is a competitive advantage — the one operator in our test that names its PSPs (Wild Fortune, disclosing Picksellpay/Volt/Nodapay/MiFinity) had the lowest spread

Full Research

Our complete investigation with 15-casino testing data, bank-by-bank blocking matrix, and PSP identification is published at Payout Verdict's PayID Casinos guide.

The withdrawal speed testing methodology (5 real payouts, stopwatch-timed) is documented at payoutverdict.com/wild-fortune-withdrawal/.

*James Patel is Casino Editor at Payout Verdict, an independent iGaming research publication covering Australian and Canadian markets.*ity_