Opensalestax Bagisto Laravel Package

Product Decisions This Supports

• Nexus-scoped tax calculation (new in v0.2.0). The nexus_states option lets us declare exactly where we have a collection obligation, and the plugin will only call the OpenSalesTax engine for carts shipping into those states. Everywhere else, Bagisto's native tax rules apply. This turns the integration from "always on" into a jurisdiction-scoped capability — a decision we can now make per market rather than per storefront.
• Sequencing and roadmap for state-by-state rollout. We can ship the integration nationally on day one with a narrow nexus list and widen it as registrations land. Expanding to a new state becomes a config change, not an engineering project — that is the single biggest planning unlock in this release.
• Variable cost control on the tax engine. Every cart currently hits the engine, including ones we have no obligation to tax. Filtering at the edge means engine call volume scales with nexus footprint, not traffic. Worth modeling against whatever per-call or per-transaction pricing we're on before we commit to volumes.
• Build vs. buy tilts further to buy. A per-state nexus filter is the kind of logic that looks trivial and isn't — it interacts with shipping destination, cart state, and fallback behavior. Getting it from the vendor, in config, at zero integration cost, is cheaper than owning it.
• Fallback behavior is now a product decision, not an implementation detail. For non-nexus states the plugin defers to Bagisto's built-in tax. That means our tax outcome in 30+ states depends on how we've configured native tax rates. Someone must own that mapping, and it needs to be reviewed whenever the nexus list changes.
• Platform parity reduces a recurring objection. Release notes cite WooCommerce v0.5, Vendure v1.2, and Odoo v0.3 as already having this. If we run multiple storefronts, this closes a capability gap and lets us use one nexus definition across platforms rather than documenting exceptions per channel.
• Use cases this directly unblocks: US SMB/mid-market sellers with economic nexus in a handful of states; merchants who registered in some states and not others; multi-store setups where one brand has a different footprint; pilots where we want to measure tax engine accuracy in a single state before committing.

When to Consider This Package

Adopt when most of these hold:

• We're on Bagisto and need US sales tax calculation — this is a thin adapter, so the platform question is settled first.
• Our nexus footprint is narrower than our shipping footprint. Without that asymmetry, the new filter buys us nothing and v0.1 behavior is fine.
• We can maintain the state list as configuration (config file or OPENSALESTAX_NEXUS_STATES), with a named owner and a change process tied to registration dates. This is not self-maintaining.
• We're comfortable with a pre-1.0 dependency (0.2.0) — pin the version, watch the changelog, expect schema and config keys to move. Do not treat the config surface as stable.
• Our tax needs are calculation only. Confirm we don't need filing, remittance, returns, or exemption-certificate lifecycle management from the same vendor; those are separate problems and a different buy.
• Fallback is acceptable for non-nexus states. We're prepared to validate that Bagisto's native tax produces a defensible result (including zero) in states we've excluded.

Look elsewhere when:

• We need admin UI for nexus management — this is config-file and env-var only. If finance or ops needs to self-serve, that's a gap we'd be building ourselves.
• We need per-store or per-channel nexus lists — the release describes a single global list. Multi-brand footprints with different registrations would need separate deployments or a contribution upstream.
• We operate outside the US, or need EU VAT, GST, or cross-border rules.
• We need address validation, exemption certificates, or filing in the same system.
• We're on a platform other than Bagisto — take the equivalent adapter (WooCommerce, Vendure, Odoo) rather than assuming parity; the release notes imply comparable behavior, not identical.

How to Pitch It (Stakeholders)

For executives: The tax integration now respects where we're actually registered to collect. We tell it which states we have nexus in; it only calculates tax for those states and leaves the rest to the platform's built-in rules. Practically, this means we can launch nationally without over-collecting in states where we have no obligation, and we can expand to a new state by changing a configuration value rather than funding a development cycle. It also reduces our per-transaction exposure to the tax vendor, since we stop paying to calculate tax we're not required to collect. The release brings us level with what our other storefront platforms already do.

For engineering: Small, contained change. New nexus_states config key and matching OPENSALESTAX_NEXUS_STATES env var, comma-separated two-letter state codes. When set, the listener short-circuits the engine call for carts shipping outside the list and lets Bagisto's native tax take over. Unset or empty is exactly v0.1 behavior, so it's opt-in and safe to deploy before the list is agreed. No migration implied.

For finance/tax: Two asks before we enable it. First, confirm the nexus list — this becomes the authoritative record of where we collect, so it needs to come from tax, not engineering. Second, sign off on what Bagisto's native tax does in the excluded states, because that's now the answer customers see there. Changing the list later changes customer-facing tax outcomes, so we'd want a review step, not an ad-hoc config edit.

Caveats to state up front: version 0.2.0 is pre-1.0 and the configuration surface may still change — we should pin it. The nexus list has no admin UI, so it's an engineering-mediated change until we build one. And there's no stated per-channel support, so a multi-brand rollout may need more than this release provides.