Hosting choices that cut US tax risk and latency use US origins, a CDN edge, and a tax engine. Configure multi-origin routing, DDP checkout, and 3PL rules to limit nexus and speed checkout.
Key variables for US-facing international storefronts
Choose origin regions, CDN/GeoDNS, tax engine, and fulfillment routing first. These four choices set latency, tax exposure, duties handling, and per-order cost.
How latency affects conversions
Median client-side RTT and server TTFB are related but distinct metrics. Both matter for conversion and must be tracked separately.
Use real user monitoring to track median RTT to edge POPs. Also use synthetic tests for TTFB from edge to origin.
Aim for median client RTT to US edges under 100 ms for core metros. Aim for end-to-end median TTFB under 200 ms for dynamic checkout endpoints.
Poor TTFB can exist with good RTT when origin processing or tax APIs are slow. Instrument both and set alerts on regressions.
The most frequent error at this point is ignoring DNS latency and origin placement.
Which origin regions to choose
Host dynamic origins in us-east (N. Virginia) for broad reach. Add us-west for Pacific traffic and lower latency to LA and SF.
Use regional replicas for heavy traffic in Los Angeles, San Francisco, Chicago, or Miami. Place checkout APIs in US regions for predictable TTFB.
CDN, anycast, and DNS best practices
Use a CDN with origin shielding, cache rules, and edge compute for static and fast dynamic delivery. Configure anycast and latency-based DNS so US users hit US POPs.
Prescribe a subdomain strategy: checkout.example.com or us.example.com. Isolate cookies and apply different security and TTL policies.
Localize content and currencies at the edge. Make privacy and data-residency choices when handling US buyer data.
Configure edge caching with long TTLs for assets and short revalidate rules for session endpoints. Use origin shielding to reduce origin load.
Implement multi-origin routing so checkout resolves to US origins while catalog traffic uses regional mirrors. Test DNS failover under load.
Document TTLs, cookie domains, and origin region selection in the infrastructure runbook. This ensures repeatable routing choices.
Key difference: most states default to $100,000 or 200 transactions for economic nexus; exceptions like California and Texas use $500,000.
Use this rule to model where to place inventory and whether to accept sales tax registration costs.
Pick a platform by matching control needs to integration effort, not by price alone. Managed SaaS reduces hosting and PCI burden while limiting origin control.
When to use shopify or BigCommerce
Choose Shopify or BigCommerce for fast launches, baked-in hosting, and PCI scope reduction. These platforms offer Avalara and TaxJar apps and many 3PL integrations.
Expect higher per-order platform fees and less control over custom duty logic. Webhook limits or locked origin placement can complicate high-volume tax lookups.
When to choose magento or headless
Choose Magento or a headless stack when checkout needs custom duty logic or multi-warehouse routing. Self-hosting on AWS, GCP, or Azure allows multi-region replicas.
Plan for SRE costs, regular patching, and PCI responsibilities. Self-hosted stacks let teams control origin placement and webhook flows.
Our opinion: A managed platform works well for most sellers entering the US market quickly. Headless or self-hosted solutions pay off when orders exceed the break-even point or when complex tax and 3PL rules dictate control.
In practice: if per-order HS code enforcement and pre-tokenization tax calls are needed at scale, headless or self-hosted wins. If rapid launch with standard Avalara and TaxJar flows suffices, Shopify or BigCommerce win.
When choosing between Shopify, BigCommerce, Magento, or headless, teams need concrete integration tradeoffs. Document webhook limits, carrier API support, and whether the platform shows duties before payment authorization.
Decide DDP or DDU early because this choice changes checkout UX and cashflow. DDP requires duties at checkout and accurate carrier duty rates.
Tax engine wiring: what fields to send
Send full address, ship_from, order lines with HS codes, product price, discounts, and Incoterms to the tax engine. Include seller identifiers and tax exemption flags.
Call the tax engine before tokenizing payment so totals include duties and taxes when using DDP. This prevents undercollection and chargebacks.
Checkout UX examples for DDP and DDU
For DDP show a clear total with duties and taxes included. Include a line-item breakdown labeled "duties and taxes included."
For DDU show an estimated duties notice and a clear statement that duties may be collected on delivery. Test both flows with sample orders to measure chargebacks.
Sample webhook JSON for tax lookup
POST /tax/lookup
{
"order_id": "ORD-12345",
"currency": "USD",
"ship_from": {"country": "CN", "region": "CN-ZJ", "postal_code": "310000"},
"ship_to": {"country": "US", "region": "CA", "postal_code": "90001"},
"line_items": [{"sku": "SKU-001","quantity":1,"unit_price":75.00,"hs_code":"950300"}],
"incoterm": "DDP",
"declared_value": 75.00
}
Fulfillment routing, state economic nexus, and tax impact
Fulfillment locations and 3PL inventory often create economic or physical nexus. Nexus can force sales tax collection in affected states.
Use a nexus model to decide where to hold inventory and how to route orders. This avoids accidental thresholds or lets teams accept nexus intentionally.
Common state thresholds and impact
Economic nexus thresholds vary by state and can change over time. A common framework is $100,000 or 200 transactions, but exceptions exist.
Do not rely on a single rule. Maintain a state-by-state table listing current thresholds, marketplace exceptions, and filing cadence.
Use that table to model when a seller will hit nexus: threshold divided by average order value gives orders to nexus. Compute whether local shipping savings justify registration and compliance costs.
Routing rules to control nexus
Route orders through centralized warehouses when possible and avoid stocking inventory in a state unless necessary. Remote fulfillment programs can keep inventory outside some states.
If nexus is unavoidable, register and use a tax engine to collect correctly. This reduces audit and remittance risk.
Cost per order: three realistic case studies
Compare total cost per order including hosting, tax engine, PSP fees, fulfillment, and duties. Use averages and break-even points for platform fees versus ops costs.
Case A: SaaS storefront
Assumptions: avg order $75, monthly Shopify Basic $29, Shopify txn fees 2.9% + $0.30, ShipBob pick and pack $5 per order, Avalara $50 per month. Platform fees average $3.70 per order. Fulfillment $5.00 and tax ops $0.50 bring total to about $9.20 per order excluding shipping.
Case B: self-hosted headless
Assumptions: EC2, ALB, and CDN about $600 per month for moderate traffic. SRE support 20 hours per month at $150 per hour. TaxJar or Avalara $50 per month. Multi-warehouse pick and pack $6.00 per order.
Fixed ops increase while per-order variable cost falls with volume. Break-even occurs around 2,000 orders per month versus SaaS.
This does not apply when selling purely digital goods with no physical shipping, when the marketplace handles tax and fulfillment, or when a large enterprise runs bespoke global infra and in-house tax teams.
Integration checklist: hosting, tax engine, PSPs, and 3PLs
Use this checklist to wire systems end to end and to make sure owners test each item. Assign owners for every task.
Copy-ready webhook mapping for orders
Send order_id, buyer_full_address, ship_from_address, items with SKU and HS code, declared_value, incoterm, shipping_service_code, currency, and buyer_tax_exempt flag. Validate fields with unit tests and a staging 3PL endpoint.
Inventory sync and routing rules
Emit real-time inventory_update and reservation webhooks to WMS and 3PLs. Route by rule: if destination state has nexus and local 3PL holds stock, prefer central fulfillment unless SLA or cost suggests otherwise.
Reconcile nightly and alert on inventory drift. This prevents long term stock mismatches.
| Platform |
Hosting control |
Tax/3PL integration |
Latency options |
Ops required |
| Shopify |
Managed (no origin control) |
Avalara/TaxJar apps; many 3PL apps |
CDN via platform; limited origin tuning |
Low |
| BigCommerce |
Managed hosting; some control via headless |
Good app ecosystem for tax and 3PL |
CDN + container options via partners |
Low to medium |
| Magento/Adobe Commerce |
Full origin control on AWS/GCP/Azure |
Direct Avalara/TaxJar SDKs available |
Multi-region replicas and caching |
High |
| Headless (Next/Vercel, custom API) |
Custom origins; edge compute options |
Custom tax webhooks; full control |
Best for low TTFB with correct DNS |
High |
Visual: hosting to tax to fulfillment flow
Browser (US)
→
CDN Edge / GeoDNS
→
Origin (us-east / us-west)
→
Tax Engine (Avalara/TaxJar)
→
3PL / Carrier
Errors that cause outages, tax mistakes, or bad UX
Common mistakes are easy to fix if found before launch. Check DNS, TTFB, tax webhook fields, and 3PL routing rules.
A misrouted DNS record can send US traffic to European origins and cause long TTFB. Relying only on CDN without origin tuning increases checkout latency.
Tax and fulfillment mistakes that look like:
Sending incomplete address data to the tax engine returns wrong tax or duty values. Using HS code defaults or missing Incoterms causes duty underpayment.
A typical case: an EU seller used DDP but did not send HS codes. The seller then undercollected duties and faced refunds and disputes.
Action checklist before go-live
Follow this checklist with owners and measurable SLOs. Each item must have an owner and a test case.
Priority launch tasks and owners
Set origin regions and CDN rules (Platform architect). Configure tax engine calls and reconciliation (Tax compliance officer).
Wire PSPs and tokenization flows (Payments engineer). Provision 3PL webhooks and sample orders (Logistics manager).
Measurable SLOs to validate
Confirm median RTT to US metros under 100 ms and checkout TTFB under 200 ms (DevOps or SRE). Complete a tax simulation for 100 sample orders across target states and reconcile totals.
Run three end-to-end DDP orders through 3PL with tracking and returns flow. Assign owners so results are actionable.
Start the 48-hour dry run: run performance tests, tax simulations, and at least one full DDP order through your 3PL. This proves the workflow.
Frequently asked questions
Do I need to collect US sales tax as an international seller?
It depends on economic or physical nexus in each buyer state and on marketplace facilitator rules. If revenue or transaction thresholds in a state are met, the seller must register and collect sales tax.
How does wayfair change my obligations?
The South Dakota v. The Wayfair decision allows states to require out-of-state sellers to collect sales tax. See the Supreme Court ruling for details (Wayfair, 2018).
Can a CDN alone guarantee low checkout latency?
No, a CDN alone does not guarantee low TTFB for dynamic checkout APIs. Origin placement and DNS routing determine where dynamic calls land.
Should duties be prepaid at checkout or charged on delivery?
Prepaying duties at checkout (DDP) removes buyer surprises and reduces returns but needs accurate duty estimates and prepayment. Charging on delivery (DDU) shifts duty risk to the buyer and raises support tickets.
How much will hosting add to per-order cost?
Hosting adds fixed monthly costs and variable egress or CDN fees; per-order hosting cost falls with volume. Expect hosting to add $0.50 to $2.00 per order for moderate volumes.
What monitoring is essential for a US-facing storefront?
Monitor real user RTT by metro, synthetic TTFB to checkout endpoints, DNS resolution times, tax engine API latency and error rates, and 3PL webhook success rates. Alert on errors over 2 percent for checkout APIs.
The plan to launch or migrate
Plan launches in three phases: prepare, test, and run. Preparation sets origin, CDN, tax engine wiring, PSPs, and 3PL endpoints.
Testing runs synthetic and RUM tests, tax simulations, and live DDP orders. Stage hosting and DNS in parallel and run a 48-hour dry run with real orders.
Cut over after the dry run and validate live metrics. Monitor RTT, TTFB, tax reconciliations, and fulfillment for 72 hours after launch.
