First‑Dollar Legal & Tax Playbook for Microcheckout Experiments

Pick one of three payment patterns before you code: (A) full redirect to a hosted payment page, (B) iframe/embedded hosted page, or (C) direct card capture with a payment API. Each pattern creates different PCI and operational obligations. Treat the pattern as a hard boundary: if the browser ever executes third‑party payment scripts or hosts card fields, assume additional PCI controls are needed.

For fast experiments, prefer full redirect (A) — your page links out to the PSP’s hosted checkout. This minimizes PCI scope and usually keeps you eligible for the simplest self‑assessment (SAQ A) because your systems never receive card data. Embedded iframes can be okay, but they frequently pull you into SAQ A‑EP or additional requirements because the merchant page still 'delivers' elements to the browser.

If you must use a tokenizing JS library or create a custom form, treat that as a production change — don’t use it for throwaway experiments unless you’re ready to accept added scope and controls.

Operational checklist:

Before you flip the switch, map which jurisdictions your experiments will bill into. In the U.S., economic nexus thresholds (commonly $100k/200 transactions but varying by state) trigger registration and collection obligations. Marketplace facilitator rules may shift the collection burden to platforms (e.g., Amazon), but if you sell on your own checkout you’re usually the responsible party.

For EU sales of digital goods or services, the One‑Stop‑Shop (OSS) exists to simplify VAT reporting across member states: register in one EU country and report consolidated VAT through OSS rather than registering in every country. There are thresholds and product/service distinctions to confirm (digital goods vs goods shipped).

Practical checklist for experiments:

Microcheckout experiments still generate merchant fees and accounting records. Expect PSP fees (percentage + fixed) and occasional chargebacks. Capture clear line‑item receipts that separate price, tax, shipping, and platform fees so you can reconcile later and categorize transactions in your accounting system.

Design receipts and bookkeeping rules up front: autopopulate product SKU, experiment tag, and customer email. That single tag saves you time when you later reconcile test orders, process refunds, or exclude experimental revenue from growth dashboards.

Simple bookkeeping checklist:

A clear, public refund policy reduces disputes. For experiments, make the policy explicit on the product page and in the receipt. If you’re selling a promise (e.g., 'join waitlist — pay now to reserve'), label it clearly (preorder, refundable, refundable within X days) and state when/if the money will be charged versus authorized.

Chargebacks are costly and can flag accounts. For microtests expect higher chargeback ratios because buyers are confused by experimental language. Use explicit product descriptions, confirmation emails, and a short refund window (e.g., 7–14 days) to keep disputes low.

Short operational checklist:

Before accepting the first real payment, run a 7‑point checklist: (1) payment flow chosen and PSP compliance verified, (2) jurisdiction mapping for tax and OSS/nexus exposure, (3) receipts and accounting tags in place, (4) public refund policy text added, (5) PCI scope assessed (SAQ A vs A‑EP vs D), (6) PSP terms and AOCs stored, (7) plan for refunds/chargebacks and bookkeeping.

Copyable launch script you can paste into your checklist manager or README: