DEV Community: KunStudio

How Korean fintech (Toss / KakaoPay / PortOne) actually works under the hood

KunStudio — Mon, 20 Jul 2026 00:00:07 +0000

The Architecture Behind Korea's Fintech Giants: How Toss, KakaoPay, and PortOne Actually Work

Korean fintech companies like Toss, KakaoPay, and PortOne have become synonymous with financial innovation, but most developers only see the polished UI. I've spent months reverse-engineering their payment flows, API patterns, and infrastructure choices while building payment features for my own products. Here's what actually happens when you tap "send money" in Toss or click "pay" on PortOne.

Understanding the Three-Layer Korean Fintech Model

Korean fintech operates within a regulatory framework that forces a specific architectural pattern: the three-layer stack. Unlike other countries, Korea mandates strict separation between payment service providers (PG), payment intermediaries, and actual banks.

Layer 1: Frontend & User Interface
This is what users see. Toss's interface is famously minimal—a transfer takes maybe 3 taps. But under the hood, the frontend performs several crucial steps: biometric authentication (fingerprint, face recognition via Knox on Samsung devices), device binding validation, and transaction signing. Toss uses a combination of WebAuthn for web and proprietary SDK integration for mobile apps.

Layer 2: Payment Service Provider (PG)
PortOne (formerly I'mport) sits here. They don't actually hold money—they're orchestrators. When you initiate a payment through PortOne's API, you're hitting their unified payment gateway that routes to the actual acquiring banks. PortOne normalizes requests across 50+ Korean payment methods into a single API surface. Their core business is handling the translation layer between merchants and banks.

Layer 3: Banking Infrastructure
The actual money movement happens through Korea's interbank network. Toss itself operates as a "virtual bank" (인터넷 전문은행) licensed by the FSC since 2021. This is critical—they can hold customer deposits directly, which KakaoPay cannot. This explains why Toss launched checking accounts and why KakaoPay had to partner with Kakao Bank.

The Real-Time Clearing System: A-Wait-FTS

The backbone of Korean money movement isn't SWIFT or ACH. It's A-Wait-FTS (Advanced Waiting Financial Telecom System), the interbank settlement platform operated by the Korean Financial Telecommunications and Clearings Institute. Think of it as Korea's version of Fedwire, but with specific requirements for fintech.

When you send ₩10,000 from a Toss account to another bank, here's the actual sequence:

Authentication (~100ms): Multi-factor auth combines something you have (device), something you know (PIN), and something you are (biometrics). Toss uses device binding—your phone is registered with your account. A transaction from an unregistered device triggers additional verification.
Transaction Signing (~50ms): The request is signed using PKI (Public Key Infrastructure). Korean regulations require specific encryption standards—primarily AES-256 for transmission and RSA-2048 for key exchange.
Message Format Conversion (~30ms): PortOne or the direct bank connection formats the request into SWIFT-like messages, but with Korean-specific fields. Bank codes use the 3-digit BIC system (우리은행=020, 국민은행=004, etc.).
Real-Time Settlement (~1-3 seconds): The money moves through A-Wait-FTS. Unlike older batch systems, A-Wait-FTS processes transfers individually and immediately. Most Korean transfers complete in under 10 seconds, often faster than 5 seconds.
Notification (~100ms): Both sides receive settlement confirmations. Apps display "전송 완료" (transfer complete) almost instantly.

The entire flow completes in 5-10 seconds, which is why Korean users expect instant transfers. This is standard, not exceptional.

How KakaoPay Handles Money Without Being a Bank

KakaoPay's architecture reveals how fintech navigates regulatory constraints. They operate as a payment service intermediary (결제중개사), not a bank. This means they cannot legally hold customer money.

Their workaround: custodial banking relationships. When you load ₩100,000 into KakaoPay, it's actually held by partner banks (신한은행, 우리은행, 국민은행). The frontend shows one unified wallet, but the backend maintains separate ledgers per partner bank. Kakao's system determines which partner bank holds which funds based on customer velocity and liquidity forecasts.

When you send money from KakaoPay to another user, two scenarios occur:

If recipient is also on KakaoPay: Internal ledger transfer, instant, no clearing required. Just a database update in Kakao's system.

If recipient is on another platform or bank: Actual clearing through A-Wait-FTS, incurring fees. This is why KakaoPay encourages transfers between KakaoPay users—zero fees.

The fee structure here is telling: ₩0 for in-network, ₩1,000 for cross-network transfers under ₩1,000,000. That difference is literally the cost of A-Wait-FTS clearing.

PortOne's API Abstraction Layer

PortOne's technical value isn't flashy, but it's where the real engineering happens. They normalize payment methods across different banks and PGs.

A merchant integrating PortOne makes one API call:

IMP.request_pay({
  pg: 'danal',
  pay_method: 'card',
  merchant_uid: '20231015-000001',
  name: '상품명',
  amount: 14000,
  buyer_email: 'example@example.com',
  buyer_name: '구매자명',
  buyer_tel: '010-1234-5678'
}, function(rsp) {
  if (rsp.success) {
    // payment success
  }
});

Behind this single call, PortOne:

Routes to the appropriate PG (Danal, KCP, NICE, etc.) based on pg parameter and inventory logic
Handles method-specific quirks (일반결제 vs 정기결제 parameters differ per PG)
Manages token storage for recurring payments
Normalizes response formats (each PG returns different field names)
Handles escrow payments, which are common for marketplace transactions

They process ~₩20 trillion annually (2023 numbers), roughly 40% of Korean online transactions. That volume requires serious infrastructure—they use redundant data centers, real-time failover to backup PGs, and maintain <99.99% uptime SLA.

Security: Beyond HTTPS

Korean fintech security goes beyond standard TLS. It mandates specific practices:

Card Information Never Touches Your Server: All sensitive payment data goes directly to the PG's secure servers via client-side encryption. This is non-negotiable under PCI DSS + Korean regulations.

Token-Based Transactions: After initial payment, merchants receive tokens. Subsequent transactions use tokens, never raw card data. PortOne manages this token lifecycle.

Device Binding: A payment initiated from an unknown device automatically triggers additional verification. Toss stores device fingerprints (hardware identifiers, OS, installed apps) to detect anomalies.

Real-Time Fraud Detection: Most platforms use ML-based scoring (Datamines, SK Infosec, etc.). Transaction flagged as suspicious? SMS 2FA required. This adds 10-30 seconds but is invisible if legitimate.

Encryption Standards: The regulatory default is AES-256-CBC for data transmission, RSA-2048 for key exchange. Older MD5 hashing is explicitly forbidden since 2015.

Why Integration Speed Still Matters

Despite standardization, Korean fintech integration takes 1-2 weeks for a competent engineer, not days. Why?

Certification delays: Your merchant registration can't process payments until the PG's compliance team reviews your business (3-5 days).
Test-mode requirements: Each PG's sandbox has different test card numbers, amounts that trigger specific responses. Test card 4111-1111-1111-1111 works at one PG, fails at another.
Recurring payment setup: If you need subscriptions, the setup flow diverges dramatically between PGs. NICE requires explicit API keys per subscription type, while Danal doesn't.

Building payment infrastructure in Korea is pragmatic engineering. You're not fighting the system—you're working within it. Toss, KakaoPay, and PortOne succeeded not through technical wizardry, but by understanding Korean financial regulations intimately and building systems that respect them while delivering exceptional user experience.

If you're building payment features for Korean users or expanding into Korea, integrating properly from the start saves months later. Understanding these three layers—user interface, PG orchestration, and banking infrastructure—shapes every architectural decision.

I'm currently building Saju, a fintech dashboard for Korean solo founders and small businesses to manage cash flow across multiple payment platforms. We went through this exact integration nightmare, and I'm documenting lessons learned at https://sajuapp.app. If you're navigating Korean payment infrastructure for the first time, that might save you days of debugging.

Two SKUs, One Model: How Prompt Engineering Alone Creates a $19 vs $29 SOP Generator

KunStudio — Sun, 19 Jul 2026 13:23:39 +0000

Two SKUs, One Model: How Prompt Engineering Alone Creates a $19 vs $29 SOP Generator

AI SOP Builder turns a plain-language process description into a finished Standard Operating Procedure. There's no fine-tuned model and no separate "pro" pipeline — it's a single Claude Haiku call, and the entire product differentiation between the $19 and $29 tiers lives in how the prompt is assembled.

One generation function, two tiers

Both SKUs — single ($19, standard) and pro ($29, "audit-ready") — route through the same generateSOP() function and the same model (claude-haiku-4-5, with an optional SOP_MODEL_PRO env override). What changes is a tier string threaded through the prompt builders:

export function buildSystem(brief, tier) {
  return [
    "You are a senior operations and quality-management specialist who writes Standard " +
    "Operating Procedures (SOPs) that pass ISO 9001-style audits...",
    "Never invent fake statistics, regulation numbers, certification IDs, or citations. " +
    "If a step depends on a policy you were not given, refer to it generically (for example " +
    "'per your data-retention policy') and flag it as something the owner must fill in...",
    tier === "pro"
      ? "This is the audit-ready edition: add a compact RACI view ... explicit controls, " +
        "checkpoints, and risk/compliance notes throughout the Procedure, and make the " +
        "Quality Checklist thorough enough to serve as a sign-off sheet."
      : "Keep it practical, complete, and immediately usable by a small team.",
  ].join(" ");
}

Pro doesn't get a different retrieval source or bigger context window — it gets one extra paragraph telling the same model to add a RACI matrix (Responsible/Accountable/Consulted/Informed), inline compliance notes, and a heavier sign-off checklist. The anti-hallucination instruction — never invent a regulation number or certification ID, flag anything unprovided as something "the owner must fill in" — applies to both tiers, since a fabricated ISO clause in an audit file is worse than an SOP that's honestly generic.

The free preview is a capped, separate generation — not a truncated one

Before payment, /api/preview generates only the "Purpose and Scope" section, capped at 240 output tokens:

export async function generateSOP(env, brief, previewOnly, tier) {
  const system = buildSystem(brief, tier);
  const user = buildUser(brief, previewOnly, tier);
  const model = !previewOnly && tier === "pro" ? env.SOP_MODEL_PRO || undefined : undefined;
  return claudeGenerate(env, system, user, previewOnly ? 240 : tier === "pro" ? 5200 : 3600, model);
}

This isn't the full SOP truncated client-side — in previewOnly mode the prompt itself tells the model to write nothing but that section ("write nothing else — no other section, no numbered steps"). The visitor reads something genuinely specific to their process before paying anything, which is the point: a preview obviously tailored to your input converts differently than a generic marketing screenshot.

Fulfillment happens inline with payment capture — deliberately

There's no separate "generate" step after checkout. capture-order.js captures the PayPal order and, in the same request, calls generateSOP() for the full document before responding:

let sop = "";
let processingError = false;
try {
  sop = await generateSOP(env, b.brief, false, priced.tier);
} catch (e) { processingError = true; }

return json({
  status: "COMPLETED", orderID: body.orderID, tier: priced.tier, sop,
  processing_error: processingError,
  support: processingError ? "ghdejr11@gmail.com (auto-refund if unfulfilled)" : undefined,
}, 200);

The important line: status: "COMPLETED" still returns even if generation throws — the payment succeeded, so the response says so, with a processing_error flag and a support contact instead of silently losing the fact that money changed hands. A source comment ties this directly to a lesson from a prior pipe where payments succeeded while fulfillment silently failed with no record of it.

Rendering the result without a Markdown library

The SOP comes back as Markdown, and the front end renders it with a small hand-written parser — line-by-line regex matching for headings (^#{1,4}\s), numbered lists (^\d+[.)]\s), bullets (^[-*]\s), and **bold** spans — built entirely with createElement/textContent, never innerHTML. It's a deliberately small vocabulary because that's the entire output format the system prompt requires — "render-safe Markdown only... no tables, code fences, or HTML" — so the renderer only has to handle exactly what the model is told to produce.

Live: https://ai-sop-builder.pages.dev/

Redesigning a Yard Without Touching the House: Structure-Preserving AI Image Edits With FLUX.2 [pro]

KunStudio — Sun, 19 Jul 2026 13:23:02 +0000

Redesigning a Yard Without Touching the House: Structure-Preserving AI Image Edits With FLUX.2 [pro]

AI Garden Design takes a photo of a front yard, backyard, or facade and re-renders the landscaping in a different style — modern, cottage, Japanese zen, desert xeriscape, tropical — while leaving the house itself alone. That constraint, "leave the house alone," turned out to be the whole engineering problem. Nobody wants a "redesign" that also invents a different roofline or moves the driveway.

The model choice: an edit model, not a fresh generation

This isn't text-to-image, it's image-to-image editing — specifically fal-ai/flux-2-pro/edit, a multi-reference, structure-preserving photoreal edit model. The uploaded photo is the reference image, and image_size: "auto" matches the output aspect ratio to the input instead of forcing a fixed size, which matters when the same house has to stay in the same position in the frame:

async function falRedesign(env, imageUrl, prompt) {
  const res = await falQueue(env, "fal-ai/flux-2-pro/edit", {
    prompt, image_urls: [imageUrl],
    image_size: "auto", output_format: "jpeg",
    safety_tolerance: "5",
  });
  const base = res.images && res.images[0] && res.images[0].url;
  if (!base) throw new Error("no image");
  return falUpscale(env, base);
}

safety_tolerance: "5" (the most permissive setting) exists for a boring reason: default safety filters on image-edit models are tuned for far broader content than "photo of a lawn," and even benign yard photos were tripping false positives without it.

Preserving structure is a prompting problem, not a masking problem

The obvious approach would be an inpainting mask — edit only the ground, leave the house region untouched pixel-for-pixel. This pipe doesn't do that; it relies entirely on prompt instructions. Every style prompt follows the same shape: describe the new landscaping, then explicitly state what not to touch:

modern:
  "Redesign only the outdoor yard and landscaping in a clean modern style: geometric " +
  "planting beds, ornamental grasses, minimalist concrete or corten-steel planters, a tidy " +
  "paved path, low-maintenance evergreen shrubs and a crisp lawn edge. Keep the house, walls, " +
  "windows, roof, driveway, fences and property boundaries exactly unchanged." + REAL

REAL is a shared suffix appended to every style prompt — a push toward "real DSLR architectural photograph" plus an explicit reject list: no illustration, no cartoon, no Unreal-Engine-style 3D render, no plastic CGI sheen. Landscape imagery lives or dies on "does this look like a real photo of my actual house," so the negative instructions do as much work as the positive description.

Same finishing-pass trick as the rest of the fal.ai pipes

After the edit model returns a base render, it runs through fal-ai/clarity-upscaler again — low creativity (0.3), moderate resemblance (0.75) — purely for sharpness, with a try/catch that falls back to the un-upscaled base on any failure so a paid render is never lost to a flaky second call:

async function falUpscale(env, imageUrl) {
  try {
    const res = await falQueue(env, "fal-ai/clarity-upscaler", {
      image_url: imageUrl, upscale_factor: 2, creativity: 0.3, resemblance: 0.75,
      num_inference_steps: 18,
      prompt: "masterpiece, best quality, highres, sharp, photorealistic garden photograph",
    }, 60);
    return (res.image && res.image.url) || imageUrl;
  } catch (e) { return imageUrl; }
}

The submit-then-poll helper (falQueue) is fully generic — the same function submits to flux-2-pro/edit, clarity-upscaler, and backs the text add-on below.

The upsell: an LLM-written landscaping brief, gated by the same grant

The Pro tier ($19.99, 25 renders across all five styles) unlocks /api/brief, which calls Claude (claude-haiku-4-5) to write a plant list, a rough budget, and a contractor-ready scope of work. It reuses the same HMAC grant verification as the image endpoint, plus one extra check — the tier itself has to have brief: true:

const tier = TIERS[grant.sku];
if (!tier) return json({ error: "Unknown tier" }, 400);
if (!tier.brief) return json({ error: "Design brief is included with the Pro pack only" }, 403);

Feature-gating between Starter ($9.99, 2 styles) and Pro ($19.99, 5 styles + brief) is just a boolean flag on a shared TIERS config, checked in-line at request time — not a separate SKU-handling code path.

Live: https://ai-garden-design.pages.dev/

Fusing Two Parents Into One Face: Building an Identity-Preserving AI Baby Generator on Cloudflare Functions

KunStudio — Sun, 19 Jul 2026 13:22:59 +0000

Fusing Two Parents Into One Face: Building an Identity-Preserving AI Baby Generator on Cloudflare Functions

BabyGlimpse takes a photo of each parent and generates AI baby portraits across three age stages (newborn, toddler, child). The interesting problem wasn't "call an image model" — it was fusing two separate faces into one coherent identity, inside the wall-clock limits of a serverless function.

The model: PuLID, not a generic text-to-image call

Describing both faces in a text prompt doesn't work — text can't carry facial identity with any fidelity. This pipe uses fal-ai/pulid, an identity-preserving diffusion model that accepts actual reference images. Both parent photos go in as reference_images, and id_mix tells the model to blend the two identities into one new face instead of copying either one:

const submit = await fetch("https://queue.fal.run/fal-ai/pulid", {
  method: "POST",
  headers: { Authorization: "Key " + env.FAL_API_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({
    reference_images: [{ image_url: refA }, { image_url: refB }],
    prompt, image_size: "square_hd",
    num_inference_steps: 8, guidance_scale: 1.2,
    id_scale: 0.8, id_mix: true, mode: "fidelity",
    negative_prompt: NEG, seed,
  }),
});

fal-ai/pulid runs on SDXL-Lightning, tuned for very few steps (4-8) — more steps don't improve a Lightning checkpoint, they just burn time. id_scale: 0.8 sets how strongly the result must resemble both reference identities versus the text prompt; mode: "fidelity" biases PuLID toward keeping recognizable features from both parents.

The finishing pass: a second model call kills the "AI plastic" look

An 8-step Lightning output is identity-accurate but lacks fine skin texture. Rather than push more steps into a model tuned for few steps, the output goes through fal-ai/clarity-upscaler as a separate pass with a real (non-Lightning) CFG — low creativity, high resemblance, so it enhances texture without drifting from the identity PuLID already locked in:

const submit = await fetch("https://queue.fal.run/fal-ai/clarity-upscaler", {
  method: "POST",
  headers: { Authorization: "Key " + env.FAL_API_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({
    image_url: imageUrl, upscale_factor: 2,
    creativity: 0.3, resemblance: 1.4,
    guidance_scale: 4, num_inference_steps: 18,
    negative_prompt: "cartoon, cgi, 3d render, plastic skin, waxy skin, ...",
  }),
});

If this pass fails or times out, the code falls back to the un-upscaled base image — a paid job should never come back empty because a secondary enhancement step had a bad day.

Why the browser drives the loop, not the server

fal.run is an async queue: submit a job, get a status_url/response_url pair, poll until status === "COMPLETED". A full batch (three age stages, several images each, each with its own upscale pass) can take minutes — too long for one serverless invocation to own.

So the client owns the top-level loop. Each /api/generate call handles exactly one age stage; the browser calls it three times in sequence (newborn → toddler → child), updating a progress bar between calls. Each Cloudflare Pages Function invocation only has to survive polling for one stage's images, keeping every request inside the platform's CPU/time budget instead of babysitting one giant multi-minute request.

Payment: a signed grant instead of a database

There's no database here. After PayPal capture succeeds server-side, capture-order.js issues an HMAC-signed grant — a base64 JSON payload {o, sku, n, exp} plus a SHA-256 signature via the Web Crypto API:

async function sign(secret, payload) {
  const key = await crypto.subtle.importKey("raw", new TextEncoder().encode(secret),
    { name: "HMAC", hash: "SHA-256" }, false, ["sign"]);
  const sig = await crypto.subtle.sign("HMAC", key, new TextEncoder().encode(payload));
  return btoa(String.fromCharCode(...new Uint8Array(sig))).replace(/=+$/, "");
}

/api/generate re-derives the same signature and rejects the request if it doesn't match, or if exp has passed (grants last 6 hours). That's the entire access-control layer for a paid API calling a metered third-party image model — no session store, no order table, just a signed token the browser carries between requests. Pricing itself lives server-side in one TIERS object; the client never gets to influence what PayPal actually charges.

Live: https://ai-baby-generator.pages.dev/

Why a cancellation-script generator is a lookup table and a template matrix, not an LLM call

KunStudio — Sat, 18 Jul 2026 13:22:26 +0000

Why a cancellation-script generator is a lookup table and a template matrix, not an LLM call

The obvious way to build "write me a cancellation message" is to send the service name and a goal to a language model and let it generate the paragraph. I built Cancel Helper the other way — a known-service lookup table plus a fixed template matrix — because the moment the output starts citing consumer-protection law, "usually right" stops being good enough.

A known-service table with fuzzy lookup

Common services (streaming, gyms, software subscriptions) get an entry in a KNOWN table: which channel actually works for that provider (web form vs. a phone line vs. in-person only), a provider-specific gotcha worth knowing before you start, and — for gym contracts especially — the retention tactic to expect. lookupKnown() normalizes whatever the user typed (lowercased, + expanded to "plus", punctuation stripped) and tries an exact slug match first, then falls back to substring/keyword matching, so "Netflix", "netflix premium", and "NETFLIX" all resolve to the same entry without the user having to type the name exactly right. Each known entry also carries a three-tier difficulty rating, shown as a small pip meter, so someone dealing with a gym contract knows upfront it's a harder path than cancelling a streaming subscription in an app.

The template matrix instead of a per-request generation call

buildScript() takes three inputs — goal (cancel / refund / cut short a signup trial / reach a human), channel (phone / email / chat / app-store), and tone (plain / cites-the-law) — and assembles one of a fixed set of reviewed paragraphs by string concatenation. Nothing here is generated per request; every combination is a known, previously-read piece of text. The store channel gets a special case regardless of goal: App Store and Google Play subscriptions have to be cancelled in the store itself, because the merchant on the other end of the message has no ability to stop that billing even if they wanted to — a script politely asking a company to cancel a charge it doesn't control would just waste the user's time.

Why the legal-tone branch is the actual reason not to use a model here

The tone toggle's second option cites specific consumer-protection law: the federal Restore Online Shoppers' Confidence Act, the Fair Credit Billing Act for disputed charges, and the FTC's complaint channel. That's exactly the category of claim a generative model will produce fluently and occasionally wrong — a plausible-sounding statute name, a slightly-off requirement, a citation that doesn't exist. A fixed string gets checked once, by a person, and then reused verbatim for every request instead of being reconstructed (and re-risked) every time. The upside of a small, owned piece of text over a model call isn't just consistency — it's that legal-adjacent copy can be kept current on purpose: the tool's own rights summary explicitly notes that the FTC's broader "click to cancel" rule was vacated by a federal court in mid-2025 and a revival attempt was underway as of early 2026, a detail that would already be stale if it were baked into a model's training data instead of a string that gets reviewed when the law changes.

Disclosing the affiliate step instead of hiding it

Past the script itself, there's a single goal-aware recommendation block — which partner it points to depends on whether the user picked cancel, refund, cut-short-a-trial, or reach-a-human — tagged rel="sponsored" and carrying a plain disclosure line stated in the block itself rather than buried in a footer: that a signup may earn a commission, that it never changes what the user pays, and that the partner isn't affiliated with the tool. Putting the disclosure in the same block as the pitch, instead of a separate terms page, was the easy part; not routing every goal to the same generic pitch was the part actually worth doing.

Live tool: https://cancel-helper.pages.dev/?utm_source=devto&utm_medium=backlink

Happy to go deeper on the fuzzy-lookup normalization or the goal/channel/tone template matrix if useful — drop a comment.

Detecting redundant subscriptions by category instead of matching names (all client-side, localStorage only)

KunStudio — Sat, 18 Jul 2026 13:21:49 +0000

Detecting redundant subscriptions by category instead of matching names (all client-side, localStorage only)

Plenty of subscription trackers will list what you're paying for. The harder, more useful question is which of those tools are doing the same job as each other — and which one to keep. Overlap Audit answers that by grouping entries by category rather than trying to pattern-match service names, and it runs entirely against localStorage, with no backend involved.

Normalizing before comparing

You can't compare a $120/year tool to a $12/month tool directly — one of them has to be converted first. normMonthly(price, billing) divides annual prices by 12 before anything else happens, so every downstream calculation (totals, overlap waste, cost-per-use) works off one consistent monthly figure regardless of how the user actually gets billed.

Overlap is a category problem, not a name problem

The obvious approach — string-matching service names to find duplicates — falls apart immediately, because the real overlap in most people's subscription list isn't two services with similar names, it's two or three services doing the same job under completely different names (two cloud-storage tools, two AI writing tools, three streaming services). So the tool groups entries by a user-assigned category instead: for any category with two or more entries, it sorts by normalized monthly cost, keeps the cheapest as the one worth having, and flags the rest as redundant — summing their cost as the waste attributable to that overlap.

A second, unrelated waste signal

Overlap isn't the only way a subscription is a bad deal. A tool can be perfectly non-redundant and still be a waste if nobody's using it: the audit separately flags anything with zero recorded uses this period, or a cost-per-use at or above a fixed threshold. Those two waste sources (redundant-with-something-else, and low-value-on-its-own) are computed independently, then de-duplicated before being added to a total potential-savings figure — an item already counted as redundant doesn't also get counted again under the low-value bucket, or the headline savings number would overstate what cancelling everything flagged would actually save.

One thing to cut, not a wall of flags

A results page that flags six problems and asks the user to prioritize them is asking the user to do the analysis the tool was supposed to do. So on top of the category breakdown, there's a single "cut this first" callout: whichever flagged item has the highest waste amount, with a one-line reason (duplicates a cheaper tool in the same category / unused this period / costs a lot per use) and the annualized number cancelling just that one item would save. One concrete next action beats a complete list every time the goal is to get someone to actually act on it.

No backend, on purpose

Every row lives in localStorage as a small JSON blob ({rows, currency}), reloaded on page load and rewritten on every edit. First-time visitors see a small set of example rows so the layout and the overlap logic are visible before anyone types in real numbers, and editing any seeded row quietly converts the whole set from example data to the user's own — no separate "start fresh" step required. There's no reason this particular tool needs a server: nothing here has to be shared across devices or persisted past the browser it was entered in, and skipping the backend means skipping an entire class of problems that comes with it.

Live tool: https://overlap-audit.pages.dev/?utm_source=devto&utm_medium=backlink

Happy to go deeper on the overlap-grouping logic or the localStorage/demo-seeding pattern if useful — drop a comment.

A cancel-by-date calculator that gets clamped month math right (so it doesn't break on Jan 31 + 1 month)

KunStudio — Sat, 18 Jul 2026 13:21:48 +0000

A cancel-by-date calculator that gets clamped month math right (so it doesn't break on Jan 31 + 1 month)

Most trial-reminder tools just tell you "day 7 of 14." I built Trial Guard to compute the one date that actually matters — the last safe day to cancel — and then get that date out of the browser tab and into a calendar, because a banner you have to remember to look at on the right day is not a reminder system.

Three dates, not one

A signup trial has three distinct dates that are easy to conflate:

Trial ends — the last day of the trial window itself
Billing date — the day the card actually gets charged (one day after trial end)
Cancel-by date — billing date minus a safety buffer the user sets (default a couple of days), so "cancel today" doesn't mean "cancel at 11:59pm and hope"

If the buffer is longer than the trial itself, the cancel-by date would land before the trial even started — the tool clamps it to the start date instead and surfaces a note explaining why, rather than showing a date that makes no sense.

The month-length trap

The naive way to add "1 month" to a date is date.setMonth(date.getMonth() + 1). That breaks the moment someone starts a trial on the 31st of a month: adding one month to Jan 31 in JavaScript doesn't land on Feb 28, it silently rolls forward into March, because Date normalizes an out-of-range day. For a tool whose entire job is telling you the correct day, a silent one-to-three-day drift is exactly the bug you can't have.

The fix is a clamped-add helper: compute the target month, work out that month's actual last day (new Date(year, month+1, 0).getDate()), and cap the day-of-month to whichever is smaller — the original day or the target month's last day. Jan 31 plus one month becomes Feb 28 (or Feb 29 in a leap year), not Mar 3. The same helper handles week- and day-denominated trials by just adding milliseconds instead, so the clamping logic only kicks in for the month case where it's actually needed.

A verdict, not just a countdown

Rather than rendering a bare number, compute() resolves the dates into one of a handful of states: already billed (trial-end date is in the past), inside the buffer window (cancel now), the last safe day, tomorrow's the deadline, or a plain days-remaining count. Each state gets its own copy and its own color on a countdown gauge, because "cancel today" and "you have three weeks" are different actions and should not look like the same UI element with a different number in it.

Getting the date out of the tab

A date sitting in a browser tab you'll close in ten seconds is not a reminder. The tool offers two exports:

A one-tap Google Calendar deep link, built entirely from URL parameters (calendar.google.com/calendar/render?action=TEMPLATE&dates=...). The fiddly part: Google's all-day event end date is exclusive, so the link has to add one calendar day to the cancel-by date or the event shows up ending a day early.
A hand-built .ics file for every other calendar app, generated client-side as a plain string (BEGIN:VCALENDAR... DTSTART;VALUE=DATE:...) with no library — an ICS file for a single all-day event is a small enough spec that pulling in a dependency for it isn't worth it.

Handing off instead of starting over

Once the tool has a service name and a decision to cancel, it doesn't just say "good luck" — it links to Cancel Helper with the service name pre-filled via a ?service= query parameter, so the next step in the actual task (writing the cancellation message) doesn't make the user retype what they just typed here.

Live tool: https://trial-guard.pages.dev/?utm_source=devto&utm_medium=backlink

Happy to go deeper on the calendar-export edge cases or the clamped date math if useful — drop a comment.

æµ å· å 3 å¤© 2 å¤ â ä å æ å®¢é ¿å æ …æ å ¢å¿…å » 5 ä ªæ ç

KunStudio — Sat, 18 Jul 2026 00:30:45 +0000

æµŽå·žå²› 3 å¤© 2 å¤œ â€” ä¸å›½æ¸¸å®¢é¿å¼€æ—…æ¸¸å›¢å¿…åŽ» 5 ä¸ªæ™¯ç‚¹

æµŽå·žå²›è·Ÿæ—…æ¸¸å›¢èµ° 80% æ—¶é—´åœ¨è´ç‰©ã€‚æœ¬æŒ‡å—ä¸ºä¸å›½æ¸¸å®¢è‡ªç”±è¡Œè®¾è®¡ 3 å¤© 2 å¤œè·¯çº¿ â€” 5 ä¸ªçœŸæ£å€¼å¾—åŽ»çš„æ™¯ç‚¹ + å®žç”¨é¢„ç®— + å½“åœ°äº¤é€šæŠ€å·§ã€‚

Chaining a segmentation model, a compositing model, and an LLM behind one API call for product photos

KunStudio — Fri, 17 Jul 2026 13:09:29 +0000

Chaining a segmentation model, a compositing model, and an LLM behind one API call for product photos

Most "AI product photo" tools do one thing: cut the background out, or generate a lifestyle scene, or write the listing copy. I built Product Studio to chain all three behind a single payment-gated call, because in practice an Etsy or Amazon seller needs all three from the same photo, and doing them as three separate tools means three separate uploads.

The three models, and why each one is a different model rather than one generalist

product photo → fal-ai/birefnet/v2        (clean transparent cutout)
             → fal-ai/bria/product-shot   (lifestyle scene, optional)
             → gpt-4o-mini                (SEO listing copy, optional)

birefnet/v2 is a dedicated background-removal/segmentation model. It runs unconditionally on every request because a clean cutout is the baseline deliverable regardless of what else the user paid for.
bria/product-shot is a compositing model purpose-built for placing a product into a photoreal scene — not a general image-to-image model prompted to "add a nice background." It takes the original photo plus a scene_description and produces the lifestyle shot directly, which is a meaningfully different (and more reliable) task than asking a generalist model to hallucinate a coherent scene around an existing product.
gpt-4o-mini handles the SEO copy because it's a text-structuring problem (title/bullets/description/backend-keywords/tags in strict JSON, following Amazon A10 and Etsy tag conventions), not an image problem — there's no reason to route it through an image model.

Splitting these three concerns across three purpose-built models instead of trying to get one model to do everything is a smaller version of the same lesson everyone rediscovers with LLM agents: a narrow tool that's good at one thing beats a generalist prompted six different ways.

Scene presets instead of a free-text background prompt

The lifestyle-shot step doesn't take an arbitrary scene description from the user — it offers four presets (marble, wood, studio, outdoor), each a fully-specified scene_description string ("on a clean white marble surface with soft natural window light, minimal editorial ecommerce lifestyle photo, soft realistic shadow"). Sellers know their product; they don't know how to write a compositing model's scene prompt, and a free-text box would mean a much wider variance in output quality for a paid, one-shot generation. Constrained choice beats an open prompt field whenever the buyer's expertise is in their product, not in prompt engineering.

Resilience: independent try/catch per stage, degrade instead of fail

Each of the three stages is wrapped independently: if the cutout succeeds but the lifestyle scene call fails, the user still gets their cutout back rather than a hard error. Only if both image stages fail does the whole request return an error. The SEO-copy failure path is even more explicit — it returns a real result plus a plain-language message pointing the user to support with a refund offer, rather than swallowing the failure silently. On a paid API chain, "one sub-step failed" and "the whole request failed" need to be distinguishable outcomes, or you either refund people who got most of what they paid for, or ship them nothing when you could have shipped two-thirds of it.

Gating three paid capabilities behind one grant

Same HMAC-signed payment-grant pattern as the rest of this pipe family: the grant payload carries whether the SEO-copy add-on (grant.c) was purchased, checked alongside a client-sent wantCopy flag before the OpenAI call ever fires — so an un-paid request can't trigger the more expensive LLM step even if it asks nicely.

What I'd tell anyone chaining multiple AI models behind one endpoint

Pick a dedicated model per concern (segmentation, compositing, text) over one generalist model reused three ways — you'll get more consistent output and it's easier to reason about failure per stage.
Offer presets instead of free text wherever the user's expertise doesn't match the prompt-engineering skill the step actually needs.
Design for partial success. A multi-model chain that returns "at least what worked" is a materially better product than one that's all-or-nothing.

Live tool: https://product-studio-eor.pages.dev/

Happy to go deeper on the fal model chaining or the SEO-copy JSON schema if useful — drop a comment.

Making AI dating photos that don't look AI-generated (the negative prompt matters more than the model)

KunStudio — Fri, 17 Jul 2026 13:09:28 +0000

Making AI dating photos that don't look AI-generated (the negative prompt matters more than the model)

I already wrote about why identity-preservation models like fal.ai's flux-pulid beat LoRA fine-tuning for keeping a face recognizable. Building AI Dating Photos on the same model surfaced a different, harder problem: keeping the skin recognizable. Identity-preserving generation solves "does this still look like the same person." It does nothing for "does this look like a real photograph," and for a dating profile picture, the second failure mode is the one that gets someone unmatched — that telltale waxy, over-smoothed, poreless AI skin is instantly recognizable to anyone who's swiped past a few AI-generated profiles already.

The two-stage pipeline

Every generation is two fal.ai calls, not one:

fal-ai/flux-pulid — generates the styled photo from the reference selfie, tuned with num_inference_steps: 26 (above the model's 20-step default) and id_weight: 1.0 for a hard face lock.
fal-ai/clarity-upscaler — a finishing pass with creativity: 0.3, resemblance: 1.5, run purely to reintroduce real skin texture and kill plastic/CGI artifacts, not to increase resolution as a goal in itself.

The negative prompt carried through both stages is doing most of the actual work against the "looks AI" problem: waxy skin, plastic skin, airbrushed, over-smooth skin, poreless skin, beauty filter, oversaturated sit right alongside the more expected deformed, extra fingers, blurry. Most negative-prompt lists you'll find in tutorials stop at the structural failure modes (extra limbs, wrong eye count) because those are the obviously broken outputs. The skin-texture terms exist because a structurally correct face with plastic skin is arguably the more common failure mode for a photoreal use case, and it's the one that actually kills conversion on a dating-photo product specifically.

Architecture: one style per call, by design

The Cloudflare Pages Function behind this doesn't generate a full batch of every style in one request — it generates one style per call, and the browser loops through styles client-side. That's not an accident of the code, it's a direct consequence of Cloudflare Functions' CPU/wall-time limits: flux-pulid generation plus an upscale pass, polled at 1.5s intervals with up to 60 polls, can run long enough that bundling four styles into one request risks the whole batch timing out and the user getting nothing. Splitting by style means a slow style can fail or time out without taking the other three down with it.

Payment-gated generation with a signed grant, no database

There's no order table anywhere in this flow. Checkout produces an HMAC-signed grant (payload + signature, verified with the Web Crypto crypto.subtle API already available in the Functions runtime) carrying the paid tier and an expiry timestamp. The generation endpoint verifies the signature and expiry before touching fal at all — no payment, no fal API call, so a failed or forged request never costs anything. Tier determines both which style presets are unlocked and how many images per style get generated (tier.count / tier.styles.length, capped at 12 per style regardless of tier).

What I'd tell anyone building a photoreal (not stylized) generation product

Write your negative prompt as if the model's default failure mode is "technically correct but obviously synthetic," not "visibly broken." For dating/headshot/portrait use cases, skin texture is the tell, not anatomy.
If your finishing/upscale step exists to fix a texture problem, tune its creativity low and resemblance high — you want it correcting texture, not reinterpreting the image.
Split long-running generation work by the smallest reasonable unit (here: one style) if you're running on a platform with hard function time limits. It's a resilience boundary, not just a UX choice.

Live tool: https://dating-photos.pages.dev/

Happy to go deeper on the negative-prompt list or the CF Functions time-limit workaround if useful — drop a comment.

Turning pet photos into oil portraits without losing the pet's actual face (FLUX.2 [pro] edit, not a LoRA)

KunStudio — Fri, 17 Jul 2026 13:08:52 +0000

Turning pet photos into oil portraits without losing the pet's actual face (FLUX.2 [pro] edit, not a LoRA)

Most "AI pet portrait" generators are a text-to-image model with your pet's name stuffed into the prompt. The output looks like a dog in a crown, not your dog in a crown — the markings drift, the ear shape changes, the face is close enough to fool nobody who actually owns the animal.

I built Regal Paws around a different primitive: fal.ai's flux-2-pro/edit model (fal-ai/flux-2-pro/edit), which does image editing from a reference photo rather than text-to-image generation from a prompt alone.

Why an edit model instead of generation-from-prompt

The two approaches solve different problems:

Text-to-image + LoRA fine-tune: train a small model on the pet's photos, then generate. Identity fidelity depends entirely on how well the LoRA trained, and it degrades fast the further the target style is from the training photos (a corgi in Renaissance oil paint is a big style jump).
Image-editing model with a reference: pass the actual photo in as image_urls, and the prompt describes the transformation to apply to that specific image rather than describing a new image from scratch. The model has the real pixels of the real pet to work from, not a compressed embedding of "roughly this dog."

For a one-shot product (someone uploads one photo and wants one good result in under a minute, no training queue), the edit-model approach is the only one that doesn't need a per-user training step.

The prompt design problem this creates

Every style prompt in the pipeline explicitly repeats the same instruction:

"Preserve the EXACT face, fur color, markings, breed and likeness of THIS specific pet."

That's not filler — it's load-bearing. Edit models will happily reinterpret a subject if the prompt leans too hard on the target style (a "regal royal portrait as a king or queen" prompt, taken alone, gives the model license to invent a generic regal animal). Anchoring the identity-preservation instruction in every single style prompt, worded almost identically to how a fal team engineer describes their own image-editing model's spec, is what keeps the actual pet recognizable across five very different aesthetics (realistic studio, Renaissance oil, royal/baroque, classic oil, Victorian).

The finishing pass

Raw edit-model output goes through a fal-ai/clarity-upscaler pass afterward — moderate creativity (0.35), high resemblance (0.7), which enriches painterly detail without letting the upscaler drift the face again. If the upscale call fails for any reason, the pipeline falls back to the un-upscaled base image rather than losing the job — a paid generation should never come back empty because a secondary enhancement step timed out.

Reliability: one retry, not an open-ended loop

For unattended production traffic (no human reviewing outputs before delivery), the generation function tries once, and if the model returns nothing usable, retries exactly once more before surfacing a "contact support for a refund" error. That single retry meaningfully cuts the failure rate on a paid flow without turning every request into an open-ended retry loop that burns fal credits on a request that's actually going to keep failing.

What I'd tell anyone building a "keep the real subject" image tool on fal

If your use case is "transform this specific photo" rather than "generate something inspired by this photo," reach for an edit/image-to-image model before a LoRA training pipeline — it's less infrastructure and the identity fidelity ceiling is usually higher for a single-shot product.
Repeat your identity-preservation instruction inside every style prompt, not just once in a system-level preamble. Style-specific language competes with it for the model's attention.
Always have a same-quality fallback for your finishing/upscale pass. Treat it as an enhancement, never a dependency the paid job can fail on.

Live tool: https://regal-paws.pages.dev/

Happy to go deeper on the fal edit-model prompt structure or the style preset list if useful — drop a comment.

How I wired Printify's API to a PayPal-only checkout for a print-on-demand shop (no Shopify, no Stripe)

KunStudio — Fri, 17 Jul 2026 06:12:06 +0000

How I wired Printify's API to a PayPal-only checkout for a print-on-demand shop (no Shopify, no Stripe)

Most print-on-demand tutorials assume you're building on Shopify with the Printify Shopify app, or on WooCommerce, or accepting Stripe. I wanted none of those — a static storefront, PayPal as the only payment rail, and Printify purely as a fulfillment API, no platform lock-in.

Here's the actual wiring behind Inkwell & Co, a small graphic-tee shop built this way.

Why skip the Shopify/Printify app integration

The standard Printify + Shopify integration is genuinely easy to set up, which is exactly why I didn't want it for this project — it couples your storefront to Shopify's checkout, theme system, and monthly fee regardless of order volume. For a single small catalog:

Printify's REST API (api.printify.com/v1) exposes products, variants, and order creation directly — no app-store middleman needed.
PayPal's REST API (Orders v2 + webhooks) handles checkout and capture without needing a full commerce platform underneath it.
A static frontend + a couple of serverless functions is enough glue code to connect the two.

The order flow

customer checks out via PayPal (Orders v2 create + capture)
  → PayPal webhook fires on PAYMENT.CAPTURE.COMPLETED
  → webhook handler POSTs an order to Printify (/shops/{id}/orders.json)
    with the captured shipping address + line items
  → Printify handles print + fulfillment + shipping
  → order status polled back for customer-facing tracking

The part that actually took iteration wasn't the happy path — it was getting the PayPal capture payload's shipping address mapped correctly onto Printify's expected order schema (Printify wants a fairly specific address object shape, and PayPal's capture response nests it differently depending on whether the buyer used a saved address or typed one in at checkout). Test both paths explicitly if you're building something similar; they don't look the same in the response.

What I'd do differently starting over

Log the full raw PayPal webhook payload before transforming it, not after. The one bug that cost real time was an address field silently going empty for guest checkouts specifically — invisible until you have the raw payload to diff against.
Printify's variant IDs are size/color-specific and not obvious from the product API alone — pull the full variants list once at setup and cache it, don't try to guess the mapping.
A webhook retry from PayPal (they do retry on non-2xx) can create a duplicate Printify order unless the handler is idempotent on PayPal's capture ID. Worth building that guard in from the start rather than after the first duplicate print run.

Live shop: https://pod-shop.pages.dev/

If you've wired Printify to a non-Shopify checkout and hit different edge cases, I'd like to compare notes in the comments.

DEV Community: KunStudio

How Korean fintech (Toss / KakaoPay / PortOne) actually works under the hood

The Architecture Behind Korea's Fintech Giants: How Toss, KakaoPay, and PortOne Actually Work

Understanding the Three-Layer Korean Fintech Model

The Real-Time Clearing System: A-Wait-FTS

How KakaoPay Handles Money Without Being a Bank

PortOne's API Abstraction Layer

Security: Beyond HTTPS

Why Integration Speed Still Matters

Two SKUs, One Model: How Prompt Engineering Alone Creates a $19 vs $29 SOP Generator

Two SKUs, One Model: How Prompt Engineering Alone Creates a $19 vs $29 SOP Generator

One generation function, two tiers

The free preview is a capped, separate generation — not a truncated one

Fulfillment happens inline with payment capture — deliberately

Rendering the result without a Markdown library

Redesigning a Yard Without Touching the House: Structure-Preserving AI Image Edits With FLUX.2 [pro]

Redesigning a Yard Without Touching the House: Structure-Preserving AI Image Edits With FLUX.2 [pro]

The model choice: an edit model, not a fresh generation

Preserving structure is a prompting problem, not a masking problem

Same finishing-pass trick as the rest of the fal.ai pipes

The upsell: an LLM-written landscaping brief, gated by the same grant

Fusing Two Parents Into One Face: Building an Identity-Preserving AI Baby Generator on Cloudflare Functions

Fusing Two Parents Into One Face: Building an Identity-Preserving AI Baby Generator on Cloudflare Functions

The model: PuLID, not a generic text-to-image call

The finishing pass: a second model call kills the "AI plastic" look

Why the browser drives the loop, not the server

Payment: a signed grant instead of a database

Why a cancellation-script generator is a lookup table and a template matrix, not an LLM call

Why a cancellation-script generator is a lookup table and a template matrix, not an LLM call

A known-service table with fuzzy lookup

The template matrix instead of a per-request generation call

Why the legal-tone branch is the actual reason not to use a model here

Disclosing the affiliate step instead of hiding it

Detecting redundant subscriptions by category instead of matching names (all client-side, localStorage only)

Detecting redundant subscriptions by category instead of matching names (all client-side, localStorage only)

Normalizing before comparing

Overlap is a category problem, not a name problem

A second, unrelated waste signal

One thing to cut, not a wall of flags

No backend, on purpose

A cancel-by-date calculator that gets clamped month math right (so it doesn't break on Jan 31 + 1 month)

A cancel-by-date calculator that gets clamped month math right (so it doesn't break on Jan 31 + 1 month)

Three dates, not one

The month-length trap

A verdict, not just a countdown

Getting the date out of the tab

Handing off instead of starting over

æµ å· å 3 å¤© 2 å¤ â ä å æ å®¢é ¿å æ …æ å ¢å¿…å » 5 ä ªæ ç

æµŽå·žå²› 3 å¤© 2 å¤œ â€” ä¸­å›½æ¸¸å®¢é¿å¼€æ—…æ¸¸å›¢å¿…åŽ» 5 ä¸ªæ™¯ç‚¹

Chaining a segmentation model, a compositing model, and an LLM behind one API call for product photos

Chaining a segmentation model, a compositing model, and an LLM behind one API call for product photos

The three models, and why each one is a different model rather than one generalist

Scene presets instead of a free-text background prompt

Resilience: independent try/catch per stage, degrade instead of fail

Gating three paid capabilities behind one grant

What I'd tell anyone chaining multiple AI models behind one endpoint

Making AI dating photos that don't look AI-generated (the negative prompt matters more than the model)

Making AI dating photos that don't look AI-generated (the negative prompt matters more than the model)

The two-stage pipeline

Architecture: one style per call, by design

Payment-gated generation with a signed grant, no database

What I'd tell anyone building a photoreal (not stylized) generation product

Turning pet photos into oil portraits without losing the pet's actual face (FLUX.2 [pro] edit, not a LoRA)

Turning pet photos into oil portraits without losing the pet's actual face (FLUX.2 [pro] edit, not a LoRA)

Why an edit model instead of generation-from-prompt

The prompt design problem this creates

The finishing pass

Reliability: one retry, not an open-ended loop

What I'd tell anyone building a "keep the real subject" image tool on fal

How I wired Printify's API to a PayPal-only checkout for a print-on-demand shop (no Shopify, no Stripe)

How I wired Printify's API to a PayPal-only checkout for a print-on-demand shop (no Shopify, no Stripe)

Why skip the Shopify/Printify app integration

The order flow

What I'd do differently starting over

æµŽå·žå²› 3 å¤© 2 å¤œ â€” ä¸å›½æ¸¸å®¢é¿å¼€æ—…æ¸¸å›¢å¿…åŽ» 5 ä¸ªæ™¯ç‚¹