Skip to main content
Part of step 8 of the launch path, Test your processes. 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.
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.

​
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 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.

Test your processes

The launch step this guide belongs to.

Take an order in admin

The counter path, in full.

Take payment and deposits

Reserving and capturing the deposit this test relies on.

Handle a return

Recording damage and charging for it.

Refund an order

Sending the money back at the end of the round trip.

Cancel or archive an order

Closing the test out so it does not linger.

Emails

The two order-confirmation templates, and where they are edited.