What actually changes when your website starts taking payments in the US

Adding payments to a site is usually scoped as a technical task: pick a processor, wire up a checkout, launch. The technical part is the easy half. The half that surprises people is everything the transaction drags along with it, most of which has to be decided before anyone writes code: who is responsible for collecting sales tax and where, how much of the payment card industry's rulebook lands on you, and what happens the first time a customer calls their bank instead of you. Here is the version of that conversation we have with clients before quoting the work.

Wayfair rewrote who has to collect sales tax, and your own site is not a marketplace

Before 2018, a state generally could not require you to collect sales tax without physical presence there. South Dakota v. Wayfair ended that, and states moved quickly to adopt economic nexus rules based on sales volume or transaction counts within their borders. Thresholds, filing frequencies and the definition of what is taxable are set state by state, and they are not stable year to year.

The trap for anyone graduating from a marketplace is that marketplace facilitator laws put the collection duty on Amazon, Etsy or eBay. Those sales were handled for you. On your own domain you are the seller of record, and the obligation is yours from the first order. Taxability itself also varies more than people expect: software and digital goods are taxed in some states and not others, clothing and groceries carry exemptions in some, and services follow their own patchwork. This is a determination to make with an accountant who works in your category, before the build, because it decides what the checkout has to calculate.

  • Economic nexus is per state, with its own threshold, registration and filing cadence
  • Marketplace sales usually do not carry over: your own storefront is a separate obligation
  • Whether your product is taxable at all is a state-by-state question, not a universal one
  • Registering in a state creates ongoing filing duties, including zero-dollar returns
  • Wholesale and reseller customers need exemption certificates collected and stored

The technical decisions that follow from the tax answer

Once you know where you have to collect, the build follows. A tax engine at checkout is the practical route: Stripe offers Stripe Tax as a paid add-on that calculates at checkout and reports on where your sales are approaching obligations, and dedicated providers do the same with deeper filing support. What almost never works long term is the static tax table built into a CMS, because rates and rules move and nobody remembers to update them.

Address handling matters more than it sounds. Rates in many states are determined at a level below the state, so a validated, complete shipping address is an input to the tax calculation rather than a nicety. B2B sellers need a way to capture and store exemption certificates and apply them automatically, and every invoice or receipt needs to show the tax separately in a form your accountant can reconcile.

PCI scope: choose the integration that keeps card data off your servers

The payment card industry's rules apply to any business that handles card data, and the amount of the rulebook you inherit depends almost entirely on how the checkout is wired. Processors document which self-assessment questionnaire applies to each integration type, and the difference between the lightest and heaviest options is enormous in effort and in liability.

The practical guidance is short. Use a hosted checkout page or payment link, or the processor's own hosted fields embedded in an iframe, so the card number never touches your server or your logs. Do not build a card form that posts to your own backend because a developer said it would be a cleaner user experience. It is a materially different compliance posture, it changes what a breach means for you, and the user experience gap on modern hosted checkouts is small enough that no US business we have worked with has regretted the trade.

  • Hosted checkout or payment links: lightest scope, fastest to launch, least to defend
  • Processor-hosted fields embedded in your page: near-native look, card data still isolated
  • Direct API with your own card form: heaviest obligations, rarely justified below real scale
  • Never log, email or store raw card details anywhere, including support tickets
  • Keep the processor's SDK current; an abandoned integration is a scope problem later

Disputes, refunds and the operational surface nobody scopes

Once money moves, the site stops being a marketing asset and becomes part of your operations. Chargebacks are the clearest example. A large share of them are not fraud; they are customers who did not recognize the charge. The name on the card statement is set by you, and when it does not match the brand the customer bought from, the dispute rate reflects it. That is a five-minute settings change and one of the highest-return things on this list.

The rest is process. You need retrievable evidence for disputes, a refund policy that is actually on the site rather than in someone's head, and, if you sell subscriptions, a cancellation path that does not require a phone call. California's automatic renewal law and similar state statutes set expectations for disclosure and for online cancellation, and a hostile cancel flow is a regulatory risk as well as a review problem. For high-ticket B2B, ACH under NACHA rules is worth pricing against cards: cheaper per transaction, slower to settle, and governed by its own return and dispute process rather than the card networks'. Surcharging to recover card fees is restricted by some states and constrained by card network rules, so treat it as a legal question, not a pricing tactic. And expect a Form 1099-K from your processor, with reporting thresholds that have moved repeatedly in recent years.

When you should not build a store at all

A large share of the US businesses that ask us for ecommerce do not need it. If you sell three service packages, take deposits, or invoice per project, a hosted payment link or invoicing built into your processor collects the money with no catalogue, no inventory, no tax matrix across forty states, and no maintenance. You can be taking payments this week instead of this quarter.

The threshold for a real store is a real catalogue: variants, stock that changes, shipping rules, returns, and someone whose job includes maintaining it. Below that line, a store is a recurring cost with a security surface attached. We would rather set you up with a payment link and revisit in a year than sell a build that becomes a burden by spring.

Frequently asked questions

Do I have to collect sales tax in every state I ship to?

Only where you have nexus, which after Wayfair can be created by economic activity as well as physical presence. Each state sets its own threshold, and crossing one triggers registration and filing there. This is an accountant's determination, not a plugin setting, and it is the first thing to establish because it shapes the whole build.

My marketplace collected tax for me. Does that carry over to my own site?

No. Marketplace facilitator laws place the duty on the platform for sales made through it. Sales on your own domain are yours, and the volume that built up on the marketplace does not exempt you. Treat launching your own storefront as starting the obligation clock fresh.

Is Stripe enough on its own, or do I need a separate tax service?

Stripe Tax handles calculation and monitoring for many businesses and is the lowest-friction option if you are already on Stripe. Dedicated tax providers make more sense with complex product taxability, many registrations, or heavy exemption-certificate handling. Either way, someone still has to file, and that someone is you or your accountant.

How much PCI work do I have to do?

Far less than most people fear, if you never touch card data. Hosted checkout and processor-hosted fields keep the card number out of your systems, which puts you in the lightest self-assessment category your processor documents. Building your own card form is what turns this into a project.

Can I add a fee to cover credit card processing?

Sometimes, and it is more constrained than it looks. Surcharging is restricted or prohibited in some states, card network rules impose disclosure and registration requirements, and debit cards are treated differently from credit. Confirm it for your states with counsel before wiring it into a checkout.

Planning to take payments on your own site? Tell us what you sell, who buys it and where they are, and we will map the decisions that have to come before the build, tell you honestly whether a payment link would serve you better than a store, and quote the integration against that.

More from the blog

Start my website