Skip to main content
The Payments tab of an order, showing its payment tables

Orders > [order] > Payments

Open in TWICE Admin

orders
Collect money from the Payment button on the order’s Payments tab. Handle two kinds separately: what the customer owes for what they ordered, and the deposit you hold against the goods coming back. Keep the deposit distinct as you go. It is collected differently, tracked on its own balance, and released or kept independently of the order total.

Prerequisites

Required permissions: orders:order_payments. Owner, Admin and Manager hold every operation on it. Member does not hold it at all, so the Payments tab does not appear for that role and none of this is available to them. See Users & Roles.
Have ready before you start:
  • A way to take the money. Connect a provider for checkout links and card deposits, or configure a manual method for cash and terminals outside TWICE. See Payments settings.
  • The customer’s email, if you are sending a checkout link.
  • A saved card on the order, if you want a deposit actually authorised rather than only recorded.

The walkthrough

1

Read where the order stands

Read the right one of the Payments tab’s five tables:Read the order’s own Payment chip for Paid or Unpaid only. It is deliberately coarse, so anything finer than “is there a balance” is read here.
2

Choose how to collect

Open Payment and pick the route the customer’s location decides:Expect both collect routes to open onto the same amount picker, so everything in the next step applies either way.
3

Collect part of the total rather than all of it

Set an amount against each target in the collect drawer, which splits what is owed into two buckets:Press Collect all to fill every target at its full remainder, or type the amount you want against each. Select line items on the order before opening the drawer to pre-seed those lines and leave everything else at zero, which is how you charge one person’s items on a shared order.
4

Take a set share of the total, such as half up front

Choose Send checkout link and press Apply to selected items above the amount list. Type 50, switch the toggle to %, and press Apply. Every ticked row takes its share of half the combined balance, across Uncollected items and Open invoices alike.Untick the rows you are leaving out and press Apply again. Switch the toggle to the currency symbol to spread a fixed sum instead.Applying 50% twice still collects 50%: the fill works from what each row owes, not from the amounts on screen. Edit any figure it writes.
Apply to selected items expanded in the Send checkout link drawer with 50 percent entered

Order > Payment > Send checkout link

On Manual payment, type the amounts row by row.
5

Collect the rest by hand when the time comes

Collect part now and the rest later, by hand, each time, because TWICE has no installment plan. Nothing schedules a series of future charges against an order, and nothing chases them.Use a subscription for the one exception, which bills on its own cycle and generates an invoice per period.
6

Reserve the deposit

Use Payment → Reserve deposit to hold the deposit against the order. Read which of the two you are offered, because the system decides rather than you:
7

Check which of the two you ended up with

Check this before the goods come back, because the distinction matters at the end. Capture a real authorisation. Treat a recorded one as a note to yourself that you took a deposit some other way, and collect on it yourself.
8

Capture or release the deposit

Use Capture deposit to keep some of it when the goods come back. The dialog shows Reserved, Already captured and Available to capture, and asks for:
9

Release the deposit by capturing nothing

Capture nothing to release it. An authorisation you never capture lapses on its own, and the Payments table records it as Expired. See Security deposits for the reservation schedule and expiry.
10

Read the result in the Payments table

Read every movement as a row, with its Receipt, Amount, Type and State.Read Type for what the money did: Payment, Refund, Deposit Auth, Deposit Capture or Cancellation. Read State for how far it got: Succeeded, Captured, Pending, Failed, Voided, Cancelled, Expired, Refunded or Refund Reversed.Expect a receipt number only once a payment has settled. A row still Pending gets one when it succeeds, so a blank receipt there is not a fault.

How do I know it worked?

  • The order’s Payment chip reads Paid, or Unpaid for a balance you know about and intend to collect.
  • The Payments table carries a Succeeded row for the amount, with a receipt number.
  • The deposit shows on its own balance as reserved or captured, rather than mixed into the order total.
  • The customer has their receipt, if you sent one.

Troubleshooting / common pitfalls

Cause: the order has no stored payment method, so there is no card to authorise against.What to do: use it anyway, because it records the deposit as reserved rather than holding money. Take the deposit by whatever means you actually use, and remember that capturing it later is a manual step rather than a card capture.To hold a real authorisation, have the customer pay by card through a checkout first so the card is on the order.
Cause: a reservation is in flight, usually a double click or two people on the same order.What to do: wait a moment and check the Payments table before retrying. The first attempt has probably succeeded, and retrying immediately risks a second hold.
Check three usual reasons:
  1. You collected part of it. The chip is binary, so anything short of the full total reads Unpaid.
  2. The payment is still Pending. It has not settled yet, so it does not count toward paid.
  3. The order total moved after you collected, because an edit re-opened the balance. See Edit an order.
Cause: TWICE does not do this. There is no schedule of future charges against an ordinary order, no automatic retry of them, and nothing that chases the customer.What to do: collect part now and the rest later, by hand, each time, which is what the collect drawer is built for. Model a genuinely recurring arrangement as a subscription instead, which does bill on a cycle.
Cause: a capture cannot exceed what the authorisation is holding. Available to capture is the ceiling, and the dialog names the figure it will accept.What to do: capture up to that amount. Charge the remainder separately against the order where the damage exceeds the deposit, rather than attempting a bigger capture.
Expect that, and treat deposits as a short hold. An authorisation lapses after its window, and the Payments table records it as Expired.What to do: charge the customer separately if something is owed, because a lapsed authorisation has nothing to capture. Security deposits covers the reservation schedule and expiry window.
Cause: your role does not hold orders:order_payments, and the Member system role does not by design.What to do: have someone with Owner, Admin or Manager take the payment, or add the permission to a custom role. The tab is not hidden: it is not yours. See Users & Roles.

Refund an order

Sending money back, in full or in part.

How payments work

Checkouts, payments and transactions in the data model.

Security deposits

The reservation schedule, states and expiry.

Order Payment tab

The tab this all happens on, including checkout links.