DEV Community: Jonas Hämmerle

ISO 4217 currency codes: the edge cases that break naive multi-currency forms

Jonas Hämmerle — Sat, 26 Sep 2026 13:48:04 +0000

Most currency handling code assumes every currency has 2 decimal places and a straightforward numeric amount. Neither assumption holds universally, and both break in ways that are easy to miss until a real transaction hits the edge case.

Not every currency has 2 minor units. JPY has zero — ¥100 is a whole number, there's no ¥100.00. KWD (Kuwaiti Dinar) has three. If your form/database column hardcodes 2 decimal places "because that's how currency works," you'll either round JPY amounts into nonsense or truncate KWD precision.

const MINOR_UNITS = { JPY: 0, KWD: 3 /* ... */ }; // default 2 for anything not listed
function formatAmount(amount, code) {
  const digits = MINOR_UNITS[code] ?? 2;
  return amount.toFixed(digits);
}

Currency codes aren't a stable, closed set forever — they get added, and in rare cases retired (old Eurozone currencies like DEM, FRF were withdrawn when the Euro launched). A hardcoded currency list baked into your app years ago can silently drift from reality. Pull the supported-currency list from a source that's actually kept current, rather than a list you typed once.

Symbol collisions are a UI bug waiting to happen. $ alone is ambiguous across USD, CAD, AUD, and several others — showing just the symbol without the ISO code next to it (or as a tooltip) is a real source of "wait, is that dollars or my dollars" confusion in any multi-currency UI.

Currency API's /v1/currencies endpoint always reflects the actual current supported set (ECB scope, ~30 major currencies) rather than a list that can go stale — check it instead of hardcoding one, especially if you're validating currency-code input from a form. Sibling API QR API is useful if that same form flow ever needs a QR code for a payment link, and Validate covers the rest of the form's IBAN/email/phone checks.

Batch-generating QR codes for events, inventory, or ticketing without hammering an API

Jonas Hämmerle — Thu, 24 Sep 2026 14:15:10 +0000

Generating one QR code per attendee badge, warehouse bin, or ticket sounds like a simple loop until you're doing it for a few thousand items and either your own rate limiter or the API's kicks in halfway through a batch job.

A few things that make batch QR generation less painful:

Concurrency, not sequential loops. A single QR code generation call is fast (no external network dependency if the service computes the matrix in-process rather than calling out to render it), so the bottleneck is almost always your own request-issuing pattern, not the API. A small worker pool (5-10 concurrent requests) clears a few thousand codes in well under a minute instead of one-at-a-time sequential awaiting.

async function generateBatch(items, concurrency = 8) {
  const results = [];
  for (let i = 0; i < items.length; i += concurrency) {
    const batch = items.slice(i, i + concurrency);
    const responses = await Promise.all(
      batch.map((item) =>
        fetch(`https://qr-api.p.rapidapi.com/v1/qr?data=${encodeURIComponent(item.url)}`, {
          headers: { "X-RapidAPI-Key": process.env.RAPIDAPI_KEY, "X-RapidAPI-Host": "qr-api.p.rapidapi.com" },
        }).then((r) => r.text())
      )
    );
    results.push(...responses);
  }
  return results;
}

Respect the tier's rate limit rather than discovering it via 429s. If you know you're generating a few thousand codes in one job, check your plan's requests-per-month ceiling ahead of time rather than mid-batch — free tiers are usually sized for "generate codes as users request them," not "bulk-generate an entire event's worth in one run."

Cache the output if the input doesn't change. A QR code for a fixed URL/payload is deterministic — regenerating the same code repeatedly across job re-runs (a common failure mode when a batch job is re-triggered after a partial failure) wastes calls for zero benefit. Key your cache on the exact data+ecc+size params.

Stateless generation (no per-request server state, no database) is what makes this kind of batch job cheap to run in the first place — that's the whole design of QR API: every call is a pure function of its query params, nothing persisted, nothing logged beyond the request path. Same account also runs Validate (IBAN/email/phone/etc. format checks) and Currency API (exchange rates) if useful for the rest of an onboarding/checkout pipeline.

How to validate email addresses properly in 2026

Jonas Hämmerle — Tue, 22 Sep 2026 14:01:11 +0000

"Just use a regex" is the most common wrong answer to email validation. Here's what actually matters, in the order it actually matters.

1. Syntax — but a permissive one. The RFC 5322 spec technically allows things like quoted strings and comments in the local part, which almost no real mail provider uses. Don't implement the full spec; use a pragmatic check instead:

function looksLikeEmail(input) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(input);
}

This deliberately under-validates. A regex that's too strict will reject real addresses (plus-addressing, unusual-but-valid TLDs) more often than it catches typos — false rejections cost you signups, false acceptances just mean you fall through to the next check.

2. MX record lookup. Syntax passing doesn't mean the domain can receive mail:

import { resolveMx } from "node:dns/promises";

async function canReceiveMail(domain) {
  try {
    return (await resolveMx(domain)).length > 0;
  } catch {
    return false;
  }
}

Catches typo'd domains (gmial.com) and abandoned/fake domains for basically zero added latency.

3. Disposable/temp-mail detection. Syntax-valid, MX-valid, and still worthless for your product: throwaway addresses from 10minutemail, guerrillamail, mailinator, and hundreds of similar services that spin up new domains constantly. There's no algorithmic tell — you need a maintained domain blocklist (the community-run disposable-email-domains list is a solid free start, just budget time to keep it synced).

4. What you're deliberately not doing: an SMTP handshake to check if the specific mailbox exists. It's slow, unreliable, and most mail servers now treat probing behavior as spam reconnaissance and silently no-op it. Don't build on a foundation that stopped being reliable.

Put together, that's syntax (fast, always run) → MX (cheap, catches typos) → disposable-domain check (catches throwaway signups) — each step only worth running if the previous one passed. I built exactly this pipeline as endpoints on Validate if you'd rather not maintain the MX/disposable-list plumbing yourself. Same account also runs QR API and Currency API.

Caching exchange rates correctly: per-day TTL, not per-request memoization

Jonas Hämmerle — Sat, 19 Sep 2026 13:16:30 +0000

If you're converting to several currencies at once — a pricing page showing a product in 8 currencies, say — the naive approach is one /convert call per currency pair. That works, but it's leaving an easy optimization on the table: ECB-sourced rates update once per business day, so there's no reason to be making fresh network calls more often than that.

The right cache key isn't "this specific conversion," it's "the rate table for this base currency, as of today's date":

const rateCache = new Map(); // key: `${base}:${isoDate}`

async function getRatesForDay(base) {
  const today = new Date().toISOString().slice(0, 10);
  const key = `${base}:${today}`;
  if (rateCache.has(key)) return rateCache.get(key);

  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/rates?base=${base}`, {
    headers: { "X-RapidAPI-Key": key_env, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  const data = await res.json();
  rateCache.set(key, data);
  return data;
}

One call per base currency per day gets you every target currency's rate in that response — /v1/rates returns the full table, not just one pair — so converting to 8 currencies from a cached table is 8 in-memory lookups, not 8 network round-trips.

Two things worth being careful about: cache the date the rate was published, not the date you fetched it (a request right after midnight UTC might still be serving yesterday's ECB publish if today's hasn't landed yet), and don't cache across a process restart without also persisting the date key — a stale in-memory cache that outlives its day is exactly the silent-wrong-number problem you're trying to avoid.

Currency API's /v1/rates endpoint is built for this pattern — pull the whole table once, cache it client-side for the day, and reserve /v1/convert for one-off single conversions where pulling the whole table would be overkill. Sibling APIs on the same account: Validate and QR API.

The QR code capacity cliff: why a shortened URL scans more reliably than a long one

Jonas Hämmerle — Thu, 17 Sep 2026 14:19:51 +0000

QR codes don't degrade gracefully as you stuff more data into them — they hit a capacity ceiling per version/error-correction combination, and the module grid gets denser and denser as you approach it. Past a certain point you're not looking at a QR code you can scan from arm's length anymore, you're looking at one that needs to nearly touch the camera lens to resolve.

The numbers, roughly: at the lowest error correction level (L), a QR code tops out around 2,900 alphanumeric characters or ~4,300 numeric-only characters. That sounds like a lot until you remember two things:

Every character costs more space than you'd think, because the encoding also has to carry the error-correction payload alongside your data — that's not overhead you can opt out of, it's the whole point of the format being scannable at all.
Real-world scanning distance matters more than theoretical capacity. A QR code sized for a business card that's encoding near the character ceiling will produce a module grid so fine-grained that a phone camera needs to be uncomfortably close to resolve individual modules.

The fix is almost always: don't encode raw data, encode a short pointer to it. A URL-shortened link, a UUID that looks up a record server-side, a short numeric ID — anything that keeps the encoded payload well under a hundred characters keeps the module grid coarse enough to scan reliably from a normal distance, at a normal print size.

# fine — short, scans easily even printed small
curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://short.link/x7f2" ...

# avoid — encoding a full JSON payload directly makes the grid dense
# and print-size-sensitive for no real benefit over a lookup pointer

If you're building this into a product, cap the accepted input length and fail with a clear error before hitting the encoder's own hard limit — silently truncating someone's data is worse than telling them up front. QR API caps data at 2000 characters for exactly this reason: comfortably under the spec's own ~2900-character ceiling at the lowest ECC level, with a clear 4xx instead of an encoder crash past it. Same account also runs Validate and Currency API.

MX record checks: the cheap email validation step everyone skips

Jonas Hämmerle — Tue, 15 Sep 2026 14:19:14 +0000

Regex-validating an email address only tells you the syntax is plausible. It says nothing about whether user@totallyfakedomain12345.com can receive mail. An MX record lookup closes that gap for basically zero extra latency.

import { resolveMx } from "node:dns/promises";

async function domainCanReceiveMail(domain) {
  try {
    const records = await resolveMx(domain);
    return records.length > 0;
  } catch {
    return false;
  }
}

This won't catch every typo (an MX record existing doesn't mean the specific mailbox exists — that needs an actual SMTP handshake, which is slow, unreliable, and often blocked by mail servers as spam-probing behavior). But it's a strong, cheap signal that catches a meaningful chunk of junk signups before you send a verification email into the void.

I run this as an optional flag on the email endpoint of Validate — syntax check always runs, MX check is opt-in since it adds a DNS round-trip. Sibling APIs on the same account: QR API and Currency API.

Why a currency API should return 502, not a stale rate, when the upstream is down

Jonas Hämmerle — Sat, 12 Sep 2026 12:59:36 +0000

A tempting shortcut when your rate source is unreachable: serve the last cached rate and let the request succeed. For most APIs that's a reasonable degradation strategy. For anything touching money, it's the wrong default.

The problem isn't that a stale rate is wrong — it's that a stale rate looks identical to a correct one from the caller's side. A 200 response with a slightly-off number is far more dangerous than an honest failure, because nothing downstream knows to treat the value with suspicion. A checkout flow that silently converts at yesterday's rate doesn't fail loudly; it just quietly overcharges or undercharges, and nobody notices until a reconciliation problem shows up much later.

async function getRateOrFail(base, target) {
  try {
    const res = await fetch(upstreamUrl(base, target));
    if (!res.ok) throw new Error(`upstream returned ${res.status}`);
    return await res.json();
  } catch (err) {
    // Explicit failure, not a stale fallback — the caller needs to know
    // "we don't have a trustworthy number right now," not get a wrong one.
    throw new UpstreamError(err);
  }
}

The tradeoff this makes explicit: you're accepting worse availability (a 502 during an upstream outage) in exchange for a hard guarantee that every successful response is a real, current-as-of-its-timestamp rate — never a guess dressed up as data.

This is the one place Currency API's "no fabricated data" principle gets tested in practice: if Frankfurter (the ECB rate proxy it uses) is unreachable, the API returns a clean 502 upstream_error instead of quietly serving whatever it last had cached. Same principle sibling API Validate applies to its VIES/MX lookups — fail honestly rather than silently degrade on anything where the caller can't tell the difference between fresh and stale. Third sibling API on the same account: QR API.

SVG output for QR codes: why vector beats raster once anyone screenshots or resizes it

Jonas Hämmerle — Thu, 10 Sep 2026 13:40:11 +0000

Raster QR codes (PNG/JPEG) look fine at the size they were generated for and fall apart the moment someone resizes, screenshots, or prints them larger — the module edges blur, and blurred module edges are exactly what breaks a decoder's ability to read the grid.

SVG sidesteps this completely because a QR code is fundamentally vector data already — it's a grid of black/white squares, not a photograph. Rendering it as <rect> elements instead of a pixel bitmap means it stays crisp at any zoom level, print size, or screen density:

<img src="qr.svg" alt="Scan to open" width="600" />

That's a 600px display of a code that could've been generated at any size — no upscaling artifacts, because there was never a fixed pixel grid to begin with.

A couple of practical notes if you're embedding these in a product:

Inline the SVG (rather than referencing it as an <img src>) if you need to style fill colors with CSS at render time instead of baking colors in server-side.
Strict hex validation on any color params matters more than it looks — if a QR generation endpoint lets you pass custom foreground/background colors and embeds them directly into SVG attributes, that's an injection surface if the values aren't validated as actual hex colors first.
Raw matrix output is still useful — for canvas rendering, terminal output, or anything that isn't "embed an image," getting the boolean module grid directly beats parsing an SVG back into pixels.

QR API returns image/svg+xml by default from GET /v1/qr, with a /v1/qr/matrix variant returning the raw grid for exactly that second use case. Sibling APIs on the same account: Validate and Currency API.

Why I put input validation behind an API instead of a shared npm package

Jonas Hämmerle — Tue, 08 Sep 2026 13:36:28 +0000

Most validation logic (IBAN, VAT, phone, email, credit card format) is language-agnostic — it's just string parsing and checksums. So why did I build it as an HTTP API instead of a JS library?

A few reasons that mattered to me:

Polyglot by default. An HTTP API works from Python, Go, Ruby, whatever — a JS package only works in JS projects.
No dependency upgrades to babysit. libphonenumber's metadata changes as countries update numbering plans; that's my problem to keep current, not every consumer's.
The VIES/MX-record/breach-check lookups need a server anyway. Those aren't pure functions — they're network calls. Once you need a server for those, you may as well put the offline checks behind the same API for consistency.

The tradeoff is obviously latency — a network round-trip beats a local function call every time. For anything on a hot path doing thousands of validations per second, a local library is the right call. For "validate this form submission once," the API overhead is noise.

If you want to see the actual shape of it: Validate on RapidAPI — free tier, no card required. Source structure is public too: https://github.com/Jay-Ecommerce/validate-api. Same account also runs QR API and Currency API.

ECB reference rates vs live FX feeds: what 'updated once a day' actually costs you

Jonas Hämmerle — Sat, 05 Sep 2026 12:54:28 +0000

Most currency-conversion needs in a typical web app — pricing pages, invoicing, displaying a rough converted total — don't need a tick-by-tick FX feed, but it's worth being explicit about what you're trading away when you use ECB reference rates (published once per business day) instead.

What ECB rates are good for: pricing display, invoicing, order totals shown to a customer, anything where "the rate as of this morning" is an acceptable, disclosed approximation. They're free, stable, and don't require an account.

What they're not good for: FX execution, arbitrage, anything where being a few hours stale has real financial consequences. If you're actually trading currency, not just displaying a converted number, you need a feed that updates far more often than once a day — and probably isn't free.

The practical pattern that works for the first category:

async function getRate(base, target) {
  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/convert?from=${base}&to=${target}`, {
    headers: { "X-RapidAPI-Key": key, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  return res.json(); // { rate, result, date } — "date" tells you exactly how fresh this is
}

The date field matters more than people give it credit for — surfacing "rate as of {date}" next to a converted price, rather than presenting it as live, sets the right expectation and avoids a support ticket when someone notices the number doesn't match what their bank showed them an hour later.

Currency API is built on exactly this tradeoff: ECB reference rates via Frankfurter, free and keyless, explicit about being once-a-day data rather than pretending to be a live feed. Same account also runs Validate (IBAN/email/phone/etc. format checks) and QR API (QR code generation) if useful for the rest of a checkout/invoicing flow.

QR code error correction levels: L vs M vs Q vs H, and when the tradeoff is actually worth it

Jonas Hämmerle — Thu, 03 Sep 2026 13:39:01 +0000

Every QR code has a Reed-Solomon error-correction level baked in — L (~7% recovery), M (~15%), Q (~25%), H (~30%) — and picking the wrong one either wastes visual density or leaves you with a code that stops scanning the moment it gets a little damaged.

Here's the actual decision, not just the percentages:

L — clean digital display only (a code shown on a screen, never printed, never overlaid with anything). Smallest, least dense module grid for a given payload.
M — the safe default for most printed material. Handles minor print smudging or a slightly low-quality printer.
Q — printed material that gets handled a lot (product packaging, shipping labels) or is at moderate risk of scuffing.
H — anything with a logo or graphic overlaid on top of the code, since that overlay is itself "damage" the decoder has to recover from. Also the right call for outdoor/weather-exposed prints.

The mistake I see most often: defaulting to H everywhere "to be safe." Higher error correction means more modules for the same data, which means a denser, harder-to-scan-from-a-distance code with zero benefit if nothing's ever going to obscure it. Match the level to the actual damage risk, not to the theoretical maximum.

curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://example.com&ecc=Q" \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: qr-api.p.rapidapi.com" \
  --output qr.svg

QR API exposes ecc as a plain query param (defaults to M) so you can set it per use case instead of hardcoding one level everywhere. Same account also runs Validate (IBAN/email/phone/etc. format checks) and Currency API (exchange rates).

Luhn's algorithm: the 70-year-old checksum still validating every card you own

Jonas Hämmerle — Tue, 01 Sep 2026 14:07:54 +0000

Every credit card number has a built-in checksum digit, and the algorithm that checks it (Luhn's algorithm) predates modern computing — it was patented in 1954, before credit cards as we know them existed.

function luhnValid(number) {
  const digits = number.replace(/\D/g, "").split("").reverse().map(Number);
  const sum = digits.reduce((acc, digit, i) => {
    if (i % 2 === 1) {
      digit *= 2;
      if (digit > 9) digit -= 9;
    }
    return acc + digit;
  }, 0);
  return sum % 10 === 0;
}

This only checks that the number is structurally valid — it says nothing about whether the card exists, is active, or has funds. That's a completely separate (and much more sensitive) concern that needs a real payment processor, not a format checker.

Brand detection (Visa vs Mastercard vs Amex) is a second, separate step based on the IIN/BIN prefix ranges. I bundled both into one endpoint on Validate since they're almost always needed together. Same account also runs QR API and Currency API.