Affiliate Marketplace Architecture: The Sub-ID Trick

The Mistake Founders Make Building a Marketplace

When founders set out to build a two-sided creator marketplace, they imagine a year of work that doesn't actually exist. They think they have to rebuild attribution from scratch for thousands of sellers. Negotiate direct affiliate relationships with every merchant. Manage payouts, tax forms, and reconciliation per creator, one at a time.

That's not a product. That's an ops nightmare wearing a product costume.

I'm building a creator marketplace right now, and the core realization that unlocked the whole thing was this: you don't rebuild affiliate marketplace architecture, you aggregate it. The attribution machinery already exists. The payment rails already exist. Your job is to sit in the middle and route value, not reinvent the plumbing underneath.

Here's the whole thesis in one breath. You hold one master publisher account per affiliate network. You stamp a per-creator sub-ID into every link that goes out. You tag conversions on the way back to figure out which creator earned what. Then you redistribute the money through Stripe, keeping the spread between what the network pays you and what you pay the creator.

That's it. That's the architecture.

The concept is simple. Anyone can sketch it on a napkin. The hard part isn't the idea, it's the discipline behind it. Sub-IDs get mangled. Networks lie about conversions until they don't. You float money you haven't been paid. Pay the wrong creator once and you've torched trust on both sides of your marketplace.

So this article is about the part that actually decides whether your marketplace survives. Not the napkin sketch. The load-bearing engineering underneath it.

What a Sub-Affiliate Aggregator Actually Is

A sub-affiliate aggregator is a legitimate, well-known pattern, not a workaround. Let me define it concretely.

Sub-affiliate aggregator architecture overview

One account, thousands of sellers

You hold a single publisher account with each affiliate network you work with. A major social commerce platform's shop program. The large networks that run on Impact or Rakuten style infrastructure. Each one gives your account a sub-ID field, usually called something like sub1, subId, or a custom param. It's designed so publishers can track their own campaigns.

You repurpose that field. Instead of tracking your campaigns, you use it to identify which creator drove the click.

The network sees one publisher account doing a lot of volume. You see thousands of individual creators, each tagged by a sub-ID, each earning their own slice. The network never has to know your creators exist. You handle that layer entirely.

The spread is the business model

The money is straightforward once you see it.

The commission spread business model

The network pays your master account a commission on every sale. Say a merchant offer pays 10%. You pay your creator a share of that, say 7%. You keep the difference, 3%, across every transaction in the marketplace.

Multiply 3% across thousands of creators and tens of thousands of conversions a month, and that spread is your entire business. You're not charging creators a subscription. You're not selling ads. You're the aggregation layer that lets a single creator access merchant relationships they'd never qualify for on their own, and you take a cut for providing that access plus the tooling.

This is sub-affiliate aggregation. Real merchants run real programs that allow it. The trick isn't the model. The trick is operating it without paying the wrong people or going broke on float, which is where the rest of this gets interesting.

Normalizing Offers Across Networks

Every affiliate network has its own schema, and none of them agree on anything.

Normalized offer schema with per-network adapters

Different commission structures. Different product feed formats, some CSV, some XML, some a REST API with pagination that fights you. Different sub-ID field names. Different attribution windows, anywhere from 24 hours to 90 days. If you let each network's quirks leak into your product, your codebase becomes a swamp of special cases, and every new network you add doubles the mess.

The fix is a normalized internal offer schema.

Every offer, no matter which network it came from, maps to one common shape inside your system: offer ID, merchant, commission rate, cookie window, payout terms, and a tracking link template. Your product, your UI, your payout engine, all of it speaks this one internal language and nothing else.

Then you write an adapter per network. The adapter does two jobs. Inbound, it translates that network's feed format into your normalized offer. Outbound, it takes your normalized tracking link and formats it the way that specific network expects, including injecting your sub-ID into whatever field that network happens to call it.

This is the data-as-config pattern. The networks aren't hardcoded into your logic. They're configurations that adapters read. Adding a new network means writing one adapter, not rewriting your marketplace.

The payoff shows up in the UI. A creator browses "offers" in one clean interface. They pick the ones they want to promote. They never know or care that one offer is powered by a social commerce platform and the next runs on Impact-style infrastructure. The sub-ID field mapping happens silently in the adapter layer, so the creator's ID lands in the right place on every link regardless of which backend powers it.

One schema in the middle. Adapters at the edges. That's what keeps the whole thing from collapsing under its own special cases.

Why You Can't Trust the Network's Attribution

This is the section that matters most. If you skim everything else, read this.

You cannot trust the network's own attribution to decide who gets paid in a marketplace. I learned this the hard way, and it's the difference between a marketplace that works and one that quietly pays the wrong creators until both sides lose faith in it.

Sub-IDs truncate and drift

Networks mangle sub-IDs constantly. Three ways it happens.

They truncate. Character limits vary wildly, some cap sub-IDs at 32 characters, some at 64. If your creator IDs are longer, the network silently chops them and you can't tell which creator the conversion belongs to.

They drift. A click passes through a redirect chain before it lands at the merchant. Somewhere in that chain, encoding differs, a URL gets re-encoded, special characters get stripped. The sub-ID that arrives isn't the one you sent.

They lag and drop. Network reporting runs behind, sometimes by days, and occasionally a field just doesn't make it into the report at all. No error. The data is simply gone.

If you rely on the network telling you "sub-ID X converted," you will misattribute payouts. You'll pay the wrong creators. In a marketplace, that's fatal. The creators who didn't get paid leave, and the ones who got overpaid become a liability you can't recover from. This is exactly the kind of silent pipeline failure where everything looks fine on the dashboard while the underlying data quietly rots.

Run your own click ledger as source of truth

The fix is to run your own redirect and click ledger.

Own click ledger as source of truth vs trusting network attribution

Every creator link points to your domain first, not the network. When a click hits your domain, you log it: the full creator ID, your own timestamp, and a short stable token you generate. Then you redirect into the network with a compact sub-ID that you control, one that fits inside the network's character limit and survives their encoding.

When conversions report back from the network, you don't trust their mangled sub-ID field. You join on your token. Your ledger says token ABC belongs to creator 4,812, full stop.

Your ledger is the source of truth. The network is just the money rail.

This join is deterministic. It's not AI, it's not fuzzy matching, it's a clean key lookup against data you recorded yourself. That's deliberate. When real money moves based on attribution, you want the code to do the math, not a model making a probabilistic guess about who earned a payout. The token maps to exactly one creator, every time, or it doesn't map at all and lands in your unattributed bucket where you can investigate it.

Own the ledger that decides who gets paid. Everything downstream depends on it.

Redistributing Payouts With Stripe Connect

Once you know who earned what, you have to pay them without becoming a payments company yourself. Stripe Connect handles that. Each creator is a connected account. Stripe takes care of KYC, the actual transfers, and the 1099s at year end.

But the rails are the easy part. The discipline around when you pay is what keeps you solvent.

Gate payouts on "locked," not "pending"

Networks report conversions as pending first. A conversion is not money. A meaningful percentage of pending conversions reverse before they ever lock, because of returns, fraud, or cancelled orders. In my modeling I assume around 8% of pending conversions reverse.

If you pay a creator on a pending conversion and it reverses, you eat the loss. You can't easily claw money back from a creator who's already spent it. So the rule is absolute: payouts only release when a conversion moves to "locked" in your ledger.

Surviving net-90 float and clawbacks

There's a second trap stacked on top. Networks pay your master account on net-60 or net-90 terms. So even after a conversion locks, you might wait three months to actually receive the cash.

Payout state machine with float and clawback gating

If you pay creators before the network pays you, you're floating money you don't have. Run that across thousands of creators and you'll run out of cash long before the marketplace gets big enough to matter.

So payouts gate on two conditions, both required. The conversion is locked in your ledger, and you've actually been paid by the network. Until both are true, the money stays put. On top of that, hold a clawback reserve, a slice of every payout you keep back to absorb the reversals that slip through even after locking.

This is where most naive marketplaces die. They pay fast to make creators happy, the reversals come in, the float catches up, and they're underwater before they understand why. I went deep on this math in the commission engine that decides if a marketplace survives, because the payout state machine is genuinely the thing that determines whether you have a business or a slow-motion bankruptcy.

What This Architecture Costs You to Build (And What It Doesn't)

Let me be honest about the work, because I'm building this right now and I'd rather you trust the assessment than the hype.

What's genuinely hard:

• The click ledger discipline. Owning the redirect, logging every click, generating stable tokens, never letting the network's data become your truth.
• The per-network adapters. Each one is real work, and each network has its own quirks you discover the hard way.
• Reconciliation between your ledger and the network's reporting. This is ongoing, not a one-time build.
• The payout state machine. Pending to locked to paid, with float gating and clawback reserves baked in.

What you don't have to build:

• Attribution science itself. The networks do the cookie tracking and postback work. You're reading their signal, not inventing the mechanism.
• Payment infrastructure. Stripe Connect handles KYC, transfers, and tax forms. You're not building a payments company.

And the honest limitations. Reconciliation is never 100% clean. You'll always have a small unattributed bucket where a click didn't join to a conversion, and you have to decide how to handle it. You need monitoring that alerts you when the network's reporting drifts from your ledger beyond a threshold, because drift is the early warning that something upstream broke.

The point is this. The aggregation pattern collapses a year of imagined work into a build you can actually ship. But the click ledger is non-negotiable. Skip it to move faster and you'll pay for it in misattributed payouts and lost trust, which is the one thing a marketplace can't buy back.

Where This Pattern Fits Your Business

This pattern is bigger than affiliate marketplaces.

The shape is: you're an intermediary, redistributing value across many parties, and a third party controls the source data you can't fully trust. That describes referral programs. Partner networks. Multi-vendor commission structures. Any model where you sit in the middle and route money based on signals someone else generates.

The lesson that generalizes is simple and it's the one I'd tattoo on a founder's arm if they let me. When you're the middle layer, own the ledger that decides who gets paid. Never let the upstream system be your source of truth. The moment you trust their data over yours, you've handed them control of your most important decision, and they don't care if it's wrong.

If you're a founder or operator staring at a two-sided model and assuming you have to rebuild everything from scratch, you almost certainly don't. The hard part isn't volume. It's knowing which single piece is the load-bearing wall, and building that piece with real discipline while you aggregate the rest.

That's the architecture decision I make before a single line of code gets written. Which piece carries the weight, and what you're allowed to borrow from everyone else. Get that right and the build gets small. Get it wrong and you're back to the imaginary year of work. If you're weighing a model like this, let's talk about the architecture before you commit a quarter of engineering to the wrong load-bearing wall.

Want to explore what AI could do for your business?

Book a free 30-minute strategy call. No pitch deck, no sales team, just a real conversation about your operations and where AI actually fits.

Book a Discovery Call