Opensalestax Laravel Package

Product Decisions This Supports

• Cost Optimization: Replace high-cost commercial tax calculation APIs (e.g., Avalara, TaxJar) with a self-hosted, open-source alternative, reducing per-transaction fees (0.5%–10% of revenue) to near-zero operational cost.
• Compliance & Control: Eliminate dependency on third-party APIs for critical tax calculations, reducing vendor lock-in and enabling full control over tax logic and data.
• Feature Roadmap:
  • Integrate tax calculations into checkout flows (e.g., Laravel-based e-commerce platforms).
  • Build a "tax engine" feature for SaaS platforms selling to US merchants (e.g., subscription services, marketplaces).
  • Add caching layers (e.g., Redis) for high-volume use cases, while maintaining compliance with jurisdiction-specific rules.
• Build vs. Buy:
  • Buy: Commercial APIs (e.g., Stripe Tax, TaxJar) for simplicity and guaranteed accuracy.
  • Build: Self-hosted OpenSalesTax for cost savings, customization, and compliance control. This SDK accelerates the "build" path by providing a battle-tested PHP wrapper.
• Use Cases:
  • E-commerce platforms (e.g., Laravel-based stores) needing real-time tax calculations.
  • Marketplaces or SaaS platforms with multi-state US customers.
  • High-volume sellers where per-transaction costs of commercial APIs become prohibitive.

When to Consider This Package

• Adopt this package if:

  • Your product operates in the US and requires accurate, real-time sales tax calculations.
  • You want to avoid recurring costs of commercial tax APIs (e.g., $0.50–$10+ per transaction or 0.5% of revenue).
  • You need full control over tax logic, data, and compliance (e.g., for audits or custom jurisdiction rules).
  • Your tech stack includes PHP/Laravel, and you can self-host the OpenSalesTax engine (e.g., Docker, Kubernetes).
  • You prioritize open-source, transparent, and self-managed solutions over vendor-dependent services.
  • Your team can maintain and update the engine/SDK in sync with tax law changes (e.g., quarterly rate updates).

• Look elsewhere if:

  • You need tax filing or remittance services (this SDK only calculates taxes; filing is the merchant’s responsibility).
  • Your product serves non-US markets (this is US-focused).
  • You lack the infrastructure or DevOps resources to self-host the OpenSalesTax engine (requires Docker/Kubernetes).
  • You need Stripe-specific integrations (use the opensalestax-stripe-php package instead).
  • You require guaranteed accuracy without maintenance overhead (commercial APIs offer SLAs and customer support).
  • Your team cannot commit to regular updates (tax laws and rates change frequently; the engine/SDK must be kept current).
  • You need caching or performance optimizations out-of-the-box (this SDK intentionally avoids caching to defer platform-specific decisions to the consumer).

How to Pitch It (Stakeholders)

For Executives:

"We can cut our sales tax calculation costs from $X per month (commercial API fees) to near-zero by switching to OpenSalesTax—a self-hosted, open-source alternative. This reduces vendor dependency, gives us full control over compliance, and aligns with our long-term cost-efficiency goals. The PHP SDK integrates seamlessly with our Laravel stack, and the upfront effort is justified by the 50–90% cost savings at scale. We’ll mitigate risk by treating it as a pilot for high-volume regions first."

Key Outcomes:

• Cost savings: Eliminate per-transaction fees (e.g., $0.50–$10+).
• Control: No vendor lock-in; full visibility into tax logic and data.
• Scalability: Self-hosted solution grows with our business without incremental costs.
• Compliance: Customizable to handle edge cases (e.g., state-specific taxability rules).

For Engineering:

*"This PHP SDK wraps the OpenSalesTax engine, an open-source US sales tax calculator. It’s a lightweight (~200 LOC), stateless wrapper for the engine’s HTTP API, with no hidden dependencies or caching logic. Here’s why it’s a strong fit for us:

• No black boxes: The engine is self-hosted; we control the data and logic.
• Laravel-friendly: Works with PHP 8.2+, uses PSR-18 HTTP clients (defaults to Guzzle), and integrates cleanly with our existing services.
• Feature-rich: Supports address-based calculations, line-item categorization (e.g., clothing, groceries), shipping taxes, and jurisdiction breakdowns for accounting.
• High quality: Zero PHPStan errors, 100% test coverage, and CI on PHP 8.2–8.4.
• Future-proof: Engine compatibility is version-pinned, and the SDK supports feature detection (e.g., shipping taxes) via the /capabilities endpoint.

Trade-offs:

• We’ll need to self-host the OpenSalesTax engine (Docker/Kubernetes).
• Maintenance: We must keep the engine/SDK updated with tax law changes (quarterly rate updates).
• No caching: The SDK defers caching to us (e.g., Redis) to avoid platform-specific assumptions.

Proposal:

1. Pilot: Deploy the engine in staging and test with a subset of US transactions.
2. Integrate: Replace commercial API calls in checkout flows with this SDK.
3. Monitor: Validate accuracy against commercial APIs (e.g., Avalara) and state DoR guidelines.
4. Scale: Roll out to high-volume regions first, then expand.

Alternatives:

• Stick with commercial APIs: Higher cost, less control.
• Build our own tax logic: High risk of errors and maintenance burden.
• Use the Stripe-specific SDK: Only if we’re deeply tied to Stripe’s ecosystem.

This is a low-risk, high-reward move for cost savings and compliance control."*