DEV Community: Koray KÖYLÜ

A payment QR code is just twelve lines of text

Koray KÖYLÜ — Wed, 12 Aug 2026 04:56:12 +0000

If you have paid an invoice in Europe recently, you have probably pointed your banking app at a small square and watched it fill in the payee, the IBAN and the amount by itself. I run ibanchecker.cash and I spent the last few weeks on both sides of those squares: generating them and reading them back. The format turned out to be far simpler than most people expect, and a couple of its rules surprised me even after years around IBANs.

What is actually in there

The standard is EPC069-12, published by the European Payments Council. German banks market the result as a GiroCode. There is no binary framing and no JSON. The payload is plain text, twelve elements separated by line breaks. This is the exact content of the code on the cover image:

BCD
002
1
SCT
COBADEFF
Webajans Bilisim Ltd
DE89370400440532013000
EUR149.00


Invoice 2026-014

Line	Element	In this code
1	Service tag	always `BCD`
2	Version	`002`, which makes the BIC optional
3	Character set	`1` means UTF-8
4	Identification	`SCT`, a SEPA Credit Transfer
5	BIC	`COBADEFF`
6	Beneficiary name	who gets paid
7	IBAN	the account
8	Amount	currency glued to the value
9	Purpose	empty here
10	Structured reference	empty here
11	Unstructured reference	free text
12	Beneficiary to originator	may be absent entirely

A few rules worth knowing before you implement any of this. The whole payload must fit in 331 bytes. The name is capped at 70 characters and the reference at 140. The amount is euro only, from 0.01 to 999,999,999.99; the standard simply has no concept of another currency. Error correction must be level M. And there is no signature anywhere: nothing in the code proves who produced it, which is worth remembering the next time a QR sticker appears on a parking meter.

The field we got wrong

Line 6 is the beneficiary name. The account holder. The person or company the money goes to.

The first version of our generator wrote the detected bank name there. Scan such a code and your banking app politely suggests paying "Commerzbank" instead of the person behind the account. It ran like that for about three weeks before we caught it. If you take one thing from this article: line 6 is the payee, never the bank. It is an easy mistake to make because the bank name is usually the string you have just resolved from the IBAN and it is sitting right there in a variable.

Rebuilding the generator

The old tool had a Generate button. The new one updates the code live as you type, which sounds cosmetic but changes how people use it: you see the code grow as the reference gets longer, and you see the byte counter move toward the 331 limit.

Exports are SVG, high resolution PNG and a vector PDF. The PDF was the fun part: a QR code is nothing but rectangles, so instead of pulling in a PDF library we walk the SVG path data and emit the rectangles into a hand-written PDF. Zero dependencies. Dropping a logo into the center automatically raises error correction to H.

One design decision I want to defend explicitly: if you enter an amount in a currency other than the euro, the tool still generates the code but tells you plainly that banking apps outside SEPA may not read it. The alternative, silently producing something that looks official, felt wrong.

Reading codes back

The newer tool is the reverse: drop in a picture of a payment QR and it lists all twelve elements with their byte counts, measured against the limits the standard sets. Decoding happens entirely in the browser with a dynamically imported jsQR; the image is never uploaded anywhere. The bytes are re-decoded with whatever character set the payload declares, so an ISO 8859 umlaut survives.

The IBAN inside then runs through the same engine as the rest of the site: country, length, national structure, the ISO 13616 check digits, the national account check digit where a country defines one (25 countries so far; for Germany that means the per-bank Prüfziffer methods, for the UK the VocaLink modulus check) and a directory lookup for the bank and its BIC.

Two rules were fixed before the first line of code. The image never leaves the browser. And decoded text is never rendered as a clickable link, because QR phishing works precisely by making that tap convenient.

One honest limitation: Swiss QR-bills are recognized but not parsed. They follow a different standard from SIX, not the EPC one, and mapping their fields onto the EPC layout would be guessing dressed up as decoding.

About the cover image

The QR on the cover is real. I generated it with the first tool and verified it by feeding the finished image back into the second one. The IBAN in it is the well-known documentation example, DE89 3704 0044 0532 0130 00, not a live account.

Both tools are free and need no signup: the generator and the decoder.

We built a free ipify alternative - here's what we learned

Koray KÖYLÜ — Fri, 12 Jun 2026 20:23:26 +0000

If you've ever needed your public IP in a script, you've probably typed this:

curl api.ipify.org

ipify is one of those quiet pieces of internet infrastructure. Launched in 2014, it answers one question — "what is my public IP?" — so simply that it ended up embedded in millions of scripts and apps, serving billions of requests a month. Respect.

But a while ago I noticed something while browsing its GitHub repo: the last code change was January 2018. Community pull requests — CORS headers, Docker support, even one-line README fixes — have been sitting unanswered for years. The hosted service still runs (it's commercially operated by WhoisXML API), but the open-source project that made developers trust it is effectively frozen. And geolocation was never part of the free deal — it's a separate paid product.

That gap looked like an invitation. We run whatsmy.fyi, an IP and network info tool, and we decided to build the thing we wished existed. Here's what we shipped and — more usefully — what we learned along the way.

What we built

A keyless endpoint that's deliberately compatible with ipify's response format:

# Plain text
curl https://whatsmy.fyi/ip
# → 203.0.113.42

# JSON — identical shape to api.ipify.org
curl "https://whatsmy.fyi/ip?format=json"
# → {"ip":"203.0.113.42"}

Swapping it into existing code is a one-URL change. No key, no signup, CORS enabled, IPv4 + IPv6, nothing logged.

When you need more than the bare IP, a free API key (10,000 requests/day) returns city, country, coordinates, timezone, ASN, and ISP — the data ipify sells separately. There's also a TypeScript SDK with a keyless mode:

import { WhatsMyFyi } from '@whatsmyfyi/sdk'

const client = new WhatsMyFyi()           // no key needed
const ip = await client.ip.address()      // "203.0.113.42"

Lesson 1: friction decides everything in this category

Our API originally required a key for everything. Reasonable, right? Usage tracking, rate limits, dashboards.

Wrong — at least for this use case. The entire reason curl api.ipify.org won the internet is that it works before you've decided to care. A developer comparing IP APIs closes the tab the moment they see "sign up first." We realized the keyless endpoint wasn't a nice-to-have; it was the price of admission. The authenticated API now earns its keep as the upgrade path, not the front door.

Lesson 2: the edge changed the economics

ipify's era required choices: serving geolocation means licensing a GeoIP database, updating it, and eating lookup latency. Charging for geo made sense in 2014.

Running on Cloudflare Workers changed that math for us. Every request already arrives with geolocation, ASN, and timezone attached (the request.cf object) — data from the network itself, with no external database call. Serving "rich" IP data now costs us roughly the same as serving the bare IP. That's not cleverness on our part; it's a structural shift that makes the old free-IP/paid-geo split feel dated.

Lesson 3: honesty is a feature you can ship

We published a comparison page covering ipify, icanhazip, ip-api.com, ipapi.co, and ipinfo — and we verified every claim by calling each API ourselves (ip-api.com really does reject HTTPS on the free tier; ipapi.co really did 429 our first request). The page also lists the places where competitors beat us, and recommends icanhazip for shell scripts and ipinfo for enterprise needs, because that's the truth.

This felt risky to write. But developers can smell a rigged comparison table from a mile away; an honest one is rare enough to be memorable — and it gives every claim on the page a "verify it yourself" quality that no marketing copy can match.

Lesson 4: maintenance is the moat

Here's the uncomfortable part: nothing we built is technically hard. A keyless IP endpoint is a weekend project. What ipify's story actually demonstrates is that the hard part is still being there — answering issues, merging PRs, shipping releases — years after the launch excitement fades.

So we wrote the only durable differentiator we could into our CONTRIBUTING.md: every issue and PR gets a human response within a few days. If we ever stop honoring that, someone should build the whatsmy.fyi alternative — and they'd be right to.

IP geolocation with zero external APIs, the Cloudflare Workers cf object

Koray KÖYLÜ — Wed, 10 Jun 2026 12:49:39 +0000

When I built whatsmy.fyi, I assumed I'd need a geolocation provider: MaxMind, ipinfo, ip-api, pick your poison. They all mean the same thing: an external dependency, an API key, a quota, added latency, and someone else's server seeing your users' IPs.

Then I found out Cloudflare Workers makes the whole category unnecessary.

The `cf` object

Every request that hits a Cloudflare Worker carries a request.cf object, populated at the edge before your code even runs. No lookup, no latency, no key. Here's what's inside:

{
  asn: 34984,                    // ISP's autonomous system number
  asOrganization: "Superonline", // ISP name
  city: "Istanbul",
  region: "Istanbul",
  country: "TR",
  continent: "AS",
  isEUCountry: undefined,        // "1" if EU, undefined otherwise
  latitude: "41.01380",          // string, not number!
  longitude: "28.94970",
  postalCode: "34000",
  timezone: "Europe/Istanbul",
  colo: "IST",                   // which CF datacenter handled this
  clientTcpRtt: 12,              // user's RTT to the edge, in ms
  httpProtocol: "HTTP/3",
  tlsVersion: "TLSv1.3",
  tlsCipher: "AEAD-AES128-GCM-SHA256"
}

That last group surprised me most: you get the user's HTTP protocol, TLS version, and actual TCP round-trip time for free. Try getting that from a geo API.

A complete IP endpoint in ~30 lines

export default {
  async fetch(request) {
    const cf = request.cf ?? {};
    const ip = request.headers.get("CF-Connecting-IP");

    return Response.json({
      ip,
      city: cf.city ?? null,
      country: cf.country ?? null,
      isp: cf.asOrganization ?? null,
      asn: cf.asn ?? null,
      timezone: cf.timezone ?? null,
      lat: cf.latitude ? parseFloat(cf.latitude) : null,
      lng: cf.longitude ? parseFloat(cf.longitude) : null,
      protocol: cf.httpProtocol ?? null,
      tls: cf.tlsVersion ?? null,
      rttMs: cf.clientTcpRtt ?? null,
    });
  },
};

That's the entire backend. No database, no GeoIP file to update monthly, no vendor.

The gotchas (learned the hard way)

1. Coordinates are strings. latitude: "41.01380" — parse them or your JSON consumers will suffer.

2. Every field can be missing. Tor exits, some corporate proxies, and brand-new IP ranges come through with sparse data. Null-check everything:

const city = typeof cf.city === "string" ? cf.city : null;

3. isEUCountry is the string "1" or undefined. Not a boolean. You've been warned.

4. Local dev gives you an empty object. wrangler dev (and Next.js dev servers behind adapters) won't populate most fields. Guard for it, and test geo logic in preview deployments.

5. City-level accuracy is "usually right, sometimes hilarious." Same as every IP geolocation source, this data comes from the same underlying registries. Country is reliable; city is best-effort. Don't build anything that requires city precision.

The privacy angle

This architecture has a property I didn't fully appreciate until I wrote the privacy policy: the user's IP never leaves the request path. There's no third-party geo provider receiving your traffic logs as a side effect. Combined with not writing logs yourself, you can honestly say: nothing is stored, nothing is shared. That's the whole privacy section.

For whatsmy.fyi this is the entire data pipeline: the site, the free API, all of it runs on request.cf and nothing else. Sub-50ms TTFB, zero external calls, zero logs.

If you're on Workers and calling a geo API today, check request.cf first. The data was already there before you asked.

I built a "what is my IP" site because I was tired of the ugly ones

Koray KÖYLÜ — Thu, 28 May 2026 15:39:14 +0000

I use "what is my IP" sites maybe once a month. Every time I end up on something covered in ads, calling three different tracking APIs, and showing me results I don't fully understand. So I spent a weekend building whatsmy.fyi.

The thing I didn't expect: you don't need an IP geolocation API at all if you're on Cloudflare Workers. Every request comes with a cf object that already has your city, country, ISP, TLS version, HTTP protocol, and RTT. Free. Zero latency.

The part I enjoyed most was the WebRTC leak test. It checks whether your browser is exposing your real IP through RTCPeerConnection even when you're on a VPN. I ran it on my own setup. It was leaking.

Zero logs. Zero storage. Just your data, shown to you.

https://whatsmy.fyi