Connect payments and build your checkout

Part of step 2 of the launch path, Connect payments. If you have not started your provider application yet — see Before you start — start it now. Approval is on someone else’s clock, not yours. What you ask for at checkout is what you have afterward. Merchants routinely discover at the counter that they never collected a phone number, or that a fitting question that belonged to one listing was never asked. Deciding both halves — the provider and the form — together is what this guide is for.

Connect a provider

Connect under Settings → Payments.

Provider	Available to	What it takes
Stripe	Every store	Connect through TWICE’s own Stripe platform — no separate Stripe account needed. Enable the card methods you want to accept.
Manual methods	Every store	Add offline methods you accept — pay on pickup, bank transfer, cash — with a label and description. Reconciled by hand, not by a provider.
Adyen, SumUp	Selected merchants only, off by default	Skip these for a standard launch. Contact TWICE if your account needs one.

Apple Pay and Google Pay activate automatically once Stripe card payments are enabled — there is no separate toggle, and TWICE registers your storefront domains for verification in the background. The one exception: neither wallet appears in an embedded (iframe) checkout link.

Verification is outside your control. Nothing else on the launch path depends on it finishing, so keep working down the path while it clears. The one thing it gates is going live: a live-mode payment, taken and refunded on a real card, is a go-live condition — you run it properly at Test your processes, not here.

Build the checkout

A checkout is a configurable flow from cart to confirmation, built under Settings → Checkouts. You can build more than one — a B2C checkout and a separate B2B one, for example — and duplicate an existing checkout rather than start blank. Each checkout has two parts: its steps and sections (the flow itself) and its styling (colours, typography, layout). Styling is cosmetic and safe to leave for later; the flow is not.

Step	Appears when	What it decides
Delivery	You enable it	Pickup, shipping, delivery — and the schedule customers pick from
Contact	You enable it	What you ask about the customer — see Decide what it collects
Additional details	An item in the order asks for extra information	Its own title and description
Payment	Always	Which of your connected system methods and any custom methods are offered
Confirmation	Always	The post-purchase screen’s information and layout items

If you take deposits: the deposit amount is a listing decision, set on the listing’s Pricing tab — not here, and not something a checkout carries a setting for. It reaches the checkout automatically once a deposit-carrying listing is in the cart. What you decide here is whether the checkout offers a card method: Stripe and Adyen cards can place the hold automatically, and a checkout offering only manual methods still accepts these orders — you just track and release the deposit yourself instead of a provider doing it. See Security Deposits.

Decide what it collects

Route every question to one of two places before you build the form. Getting this wrong is why merchants end up with data they cannot find again.

Ask about	Put it	Lands on
The person, and it is a built-in (name, email, phone, address, tax ID, …)	A Customer field on the Contact step	The matching column on the customer profile
The person, and it is your own field (membership number, licence class)	A customer attribute, surfaced on the Contact step	The attribute on the customer profile
The item they are taking (height, shoe size, a condition acknowledgement)	A listing checkout field, on that listing’s Checkout Settings tab	The order line, not the customer

A phone number is a person question — put it on Contact, once, and every future order has it. A shoe size is an item question — put it on the listing, and only orders for that listing ask it. Mixing the two up is the single most common way a launch checkout collects the wrong thing in the wrong place. Full detail on each: collect customer data at checkout for the person, ask customers for information at checkout for the item.

Attach it to the channel that will use it

A checkout does nothing until it is Active and reachable. Set its status to Active, then either:

Mark it Default for the whole account, or
Connect it to a specific storefront in the Theme Editor’s Checkout page, or
Assign it to one or more locations there, for locations with different requirements — a ship-only warehouse without a pickup step, say.

Priority	Source
1	The customer’s selected location, if it has a checkout assigned
2	The storefront’s own default, set in the Theme Editor
3	The account’s Default checkout

A checkout assigned to a location cannot be deactivated or deleted until you remove the assignment first — and removing an assignment falls that location back to the next checkout in the priority order above. Check the fallback is the one you want before you remove it.

Done when

Every payment method you plan to accept is connected under Settings → Payments, and Stripe verification is complete or visibly in progress.
At least one checkout is Active and either marked Default or assigned to the channel that will use it.
The Contact step asks for exactly the account-level details you need — nothing you have not decided to act on.
Every per-item question (sizing, personalisation text, a condition acknowledgement) lives on the listing’s Checkout Settings tab, not on the checkout.
If you take deposits, the deposit is set on the relevant listings’ Pricing tabs, and at least one connected method on the checkout can place an automatic hold — or you have a plan to track manual ones yourself.