Engineering Evaluation · Tax Compliance

Avalara 1099 / W-9 — V1 vs V2 API

Choosing the API version to collect tax forms (W-9 / W-8) from players whose payouts cross the reporting threshold, and to file the resulting 1099s.

Prepared for: Product Context: Avalara payout-form integration June 2026

?First, what are these forms?

Plain-language background — we're not US-based and this isn't legal advice, just enough to make the decision.

The US tax authority (the IRS) wants to know about money businesses pay out to people in the US. When we pay a player above a certain amount in a year, the IRS expects two things from us:

W-9 A form the player fills in to give us their legal name and US taxpayer ID number. It's how we collect who we're paying. (Players outside the US fill in a W-8 instead — same idea, for non-US people.)
1099 A form we send (to the player and to the IRS) at year-end that reports how much we paid them. We can only produce it once we've collected their W-9.

Why we have to do this: if we pay US players over the threshold and don't collect a W-9 / can't file the 1099, that's a compliance problem for us — potential fines and being forced to withhold a chunk of every payout. Avalara is the service that handles both the collecting and the filing for us. This document compares the two versions of Avalara's tool for doing that.

★The short version

Both versions collect the form the same way — an embedded, low-code component dropped into our own page. Neither forces players to fill it out up front, so our "show it only after they request a payout over the threshold" plan works either way.
V1 does only form collection. Avalara themselves call it "limited use," and it's still on early 0.x versioning (latest Nov 2024).
V2 does the whole lifecycle: collect the form → verify the tax ID → store the payee → e-file the year-end 1099 with the IRS & states. It's the version Avalara is actively building on.
The decision is not "which one collects the form" (both do) — it's "do we only need to collect, or do we also need to file 1099s for those payouts?" A payouts platform will need to file. That points to V2.

1Feature comparison

Capability	V1 (Track1099 API)	V2 (Avalara 1099 & W-9)
Primary purpose	Form collection only	Full 1099 / W-9 lifecycle
Embedded form in our own page (the iFrame)	✔ Yes	✔ Yes — same flow
What we get back	Tax-ID match status, signature date, signed PDF link	Same — plus the payee & form are stored as records we can query later
Tax-ID (TIN) verification	✔	✔
Year-end 1099 e-filing (IRS + states)	✘ No	✔ Yes — the main reason to choose V2
Webhooks (event notifications)	✘ Not documented — we'd poll	✔ Submission, verification & filing events
Stored payee / company records	Thin	Rich, queryable data model
Login / security model	Identical — same Avalara credentials & 1-hour token (not a differentiator)
Maturity & longevity	Early `0.x`, breaking changes still landing; kept "as needed"	The strategic, supported version

2How the player flow works (same for both)

Our trigger — only showing the form once a player requests a payout over the threshold — is fully supported by both versions. The flow is:

Threshold crossed. A player's payout request goes over the reporting threshold (we already track payout totals).
Backend prepares the form. Our server asks Avalara to create a form request (done server-side to keep credentials safe).
Form appears in-page. The embedded component renders the W-9 (US players) or W-8 (foreign players) right in our payout screen — no redirect to Avalara.
Player signs. We instantly get back the tax-ID match result and a signed PDF.
Payout decision. We release or hold the payout based on that result.

Where the versions diverge: after collection. With V1 we've solved step 1–5 but still need a separate path to actually file the 1099 / W-2G at year-end. With V2, the signed form and payee persist as records we can attach payout amounts to and e-file directly — one integration instead of two.

3Who decides "over the threshold"? This is on us, not Avalara

Step 1 of the flow above ("threshold crossed") is the one part Avalara does not do for us. Worth being explicit about it.

Our system	Detecting the crossing. Avalara never sees a payout until we send it — it does not watch our payout stream or notify us. So we evaluate each player's payouts against the limit. We already track payouts, so this is our existing data. How we aggregate depends on the form: 1099-MISC/NEC and 1099-K look at the annual cumulative total per player (calendar year, Jan 1–Dec 31), whereas W-2G is assessed per winning payout, not summed over the year — one more reason the form type (below) drives the logic.
US tax law (IRS)	Setting the threshold value. The number isn't ours or Avalara's to choose — it's set by IRS rules, and it depends on which form applies. The amounts also just changed for 2026 (see table below), so this is config we maintain, not a hardcoded constant.
Avalara	Collecting the form & filing. Once we decide to prompt, Avalara renders the form and (V2) files the year-end 1099. It also applies thresholds at filing time — but that's after the fact, not the live gate we need at payout.

The current IRS thresholds (which form applies is the open question for Avalara):

Form — what it covers	Threshold
W-2G — gambling / gaming winnings	$2,000 as of Jan 1 2026 (was $1,200 slots, $1,500 bingo & keno) — per IRS 2026 W-2G instructions
1099-MISC / 1099-NEC — other payouts	$600 through 2025 → $2,000 from 2026, inflation-indexed after
1099-K — third-party payment settlement	$20,000 + 200 transactions (the $600 phase-in was repealed)

Figures reflect post-OBBBA rules and IRS guidance current as of June 2026 (verified against Avalara, RSM, and IRS sources below). They are not legal/tax advice — confirm the applicable form and amounts with Avalara / a US tax advisor.

Product decision to confirm: if a player crosses the threshold without a signed form on file, IRS rules can require us to apply 24% backup withholding on the payout. Collecting only at the moment of crossing is a reasonable UX call, but it leaves no buffer — do we block the payout until the form is signed, or pay and withhold? This should be an explicit choice, not a default.

4Recommendation

Build on V2.

Even though Avalara's rep highlighted V1 for the embedded iFrame, V2 gives us the same in-page collection experience plus tax-ID verification, persistent payee records, webhooks, and — most importantly — the year-end 1099 filing we will inevitably need for reported payouts. It's also the version Avalara is investing in, so we avoid building on a "limited use" surface.

Use V1 only if we want the fastest possible throwaway spike ("drop in an iFrame, get a signed PDF") and are certain filing will be handled entirely outside the API.

5Open question for Avalara

Confirm on the call which form our payouts report on — 1099-MISC / 1099-K vs. W-2G for gambling winnings, and W-8BEN + 1042-S for foreign players. The W-9 / W-8 collection is the same prerequisite regardless, but it determines what the V2 filing side needs to produce.

6Not yet verified

The exact V2 request/response shapes — Avalara's V2 developer site is a JavaScript app our tooling can't read directly. We have V2's full feature inventory but not the literal field-by-field contract.
These can be confirmed from the V2 Production / Sandbox Swagger links Avalara sent (the links didn't carry over as text in the forwarded email — we'll grab them from the original).