> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Run your pre-launch test order
> The one scripted round trip that proves a launch-ready account actually works — a real order, a real card, a damaged return, and the counter path staff will use.
Part of step 8 of the [launch path](/docs/guides/launch/overview), [Test your processes](/docs/guides/launch/test-end-to-end). Everything up to here is configuration you have read back to yourself. This step is where you stop reading and place an order.
Do it yourself, on your live storefront, with your own card. There is no sandbox for this — TWICE Commerce has no test-mode toggle for payments, so the account you are testing is the account that goes live. Pick a listing and dates that do not block anything else: you are genuinely charging and refunding a card, fees included on both sides.
## Run the round trip on the storefront
One order, placed the way an actual customer would, taken all the way through a return that goes wrong on purpose. A clean return proves less than a damaged one — it exercises the happy path you already trust, not the money decisions you have not tested yet.
| Step | What to check |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Place the order | Multi-line, at least one add-on, your own card, on your live storefront domain |
| It lands in admin | The order appears in **Orders** with the right customer, lines and dates |
| Confirmation email | A completed checkout fires two templates — **Storefront order confirmation** to the customer, **Admin order confirmation** to your team (see [Emails](/docs/settings/emails)). Check the customer's actual inbox, spam folder included — a template that renders correctly in the editor preview can still land nowhere |
| Receipt | Generated automatically as an attachment on the confirmation email. Open it — your business details, the amount and the line items on it are what the customer keeps |
| Custom documents | If you built an order document template — terms, a rental agreement — generate one from the order's **Documents** tab with **Create from template**, and check it renders this order's real data rather than the template editor's sample data |
| Hand it out | [Take payment](/docs/guides/orders/take-payment) for anything still owed, then mark the items **Fulfilled** |
| Take it back damaged | Mark the items **Returned**, then work it as a genuine [damaged return](/docs/guides/orders/handle-a-return): record the damage on the stock item, and charge for it — capture the deposit if one is held, or add a line item if not |
| Refund | [Refund](/docs/guides/orders/refund-an-order) what the round trip should give back, so the order's balance ends where a real damaged-and-settled order would |
| Clean up | [Close, and archive if it should leave the Orders table,](/docs/guides/orders/cancel-or-archive-an-order) so the test does not sit in your live numbers |
**A deposit only proves the capture path if it was actually authorized.** Pay with a real, storable card and let TWICE place a real authorization before you capture against it. A deposit with no saved card is only *recorded*, not authorized — capturing it is bookkeeping, not a payment, and tells you nothing about whether a real capture works. See the deposit steps in [Take payment and deposits](/docs/guides/orders/take-payment).
## Run it from the counter too
Staff take orders in admin; customers place them on the storefront. Both reach the same Order, but the paths are not equivalent — which is exactly why this step covers both.
**An order created in admin sends nobody an email by itself.** The confirmation emails above fire on a completed checkout — the storefront's, or a checkout link's, once the customer pays it. **Create Order** plus **Manual payment** completes an order without either ever happening, so a counter sale where staff took cash or a card themselves produces no automatic customer confirmation and no automatic receipt. If the customer should have one, send a checkout link instead of collecting manual payment, or hand them a printed receipt from the order's Documents tab yourself.
[Take an order in admin](/docs/guides/orders/take-an-order-in-admin) the way your counter actually will, start to close. You do not need to repeat the damaged return here — the point of running it a second time is the path, not a second full round trip.
## Done when
* One storefront order has been placed, confirmed by email, paid, handed out, returned damaged, charged for the damage, refunded, and closed.
* The confirmation email arrived in a real inbox — not just the template editor's preview — and its receipt attachment read correctly.
* Any custom document template you rely on has rendered this order's real data from the Documents tab, not sample data.
* A deposit capture actually moved money, because it was captured against a real authorization rather than a recorded one.
* A counter-created order has been run through the same states as the storefront one, and your team knows which of its payment methods leave a customer without an email.
* Nothing from this round trip is sitting open in the Orders table.
## Related articles
The launch step this guide belongs to.
The counter path, in full.
Reserving and capturing the deposit this test relies on.
Recording damage and charging for it.
Sending the money back at the end of the round trip.
Closing the test out so it does not linger.
The two order-confirmation templates, and where they are edited.