How checkout works

Hosted checkout: create → validate → checkout

Keep this integration when using printing credit. For server-API and live-mode standalone widget carts, checkout automatically uses enough eligible partner credit for printing, otherwise it uses normal full payment. Customers pay shipping and fulfillment tax through Stripe. The existing API key still works; no extra wallet or prepaid endpoints are required. See printing credit for eligibility and the optional advanced flow.

1. POST /v1/carts returns 202 Accepted, status: validating, and no checkout URL.
2. A separate background worker downloads, checks and applies automatic print bleed to both fronts and backs. Poll GET /v1/carts/{id} every 3–5 seconds, honoring Retry-After. Progress may remain unchanged while a job waits for the worker.
3. When a live cart is open, browser JavaScript calls TCGPlaytest.checkout(cart) to embed delivery details; the customer then continues to Stripe outside the frame. For a test cart, open its returned checkout_url as a full-page simulator with no Stripe payment.
4. Confirm payment from a signed order.paid webhook or the order API. TCGPlaytest prints from the already-checked files; payment does not trigger another source download.

Automatic bleed is handled by the API. Submit finished-card artwork; partners do not need to add bleed. Before checkout opens, TCGPlaytest applies the website’s standard 2 mm auto-bleed around a 63 × 88 mm finished card, using the same mask and corner treatment. Recognized artwork with existing bleed is preserved at 2 mm or cropped from 3 mm to 2 mm, without adding a second margin. A 1500 × 2100 image becomes 1596 × 2196 pixels. The dashboard and production use the prepared file. Optional SHA-256 values must still describe the original submitted bytes. Both source and prepared files remain private, scoped to that cart, and follow its expiry/retention and legal holds.

Send Authorization: Bearer <your API key> on server-side upload-grant, cart and order API requests, and Content-Type: application/json on POST. Never expose keys in browser code or the widget. Signed storage PUTs and image-reference reads use their temporary URL capability instead, without a bearer key. Cart and order reads are scoped to the partner and key mode.