The card: five checks, in the order that keeps a code unspent
Run the 5 checks below before typing anything into a code field. Each costs about 30 seconds, and the first 3 can be completed while the basket is still empty, which is the only moment when a mistake costs nothing. Nothing on this page quotes a code, an amount or a percentage, because none of those can be verified from outside an account.
| Check | Where the answer lives | If the answer is missing |
|---|---|---|
| What the code applies to | The terms text on the page that showed you the code | Assume it reaches nothing, and ask before checkout |
| Every condition attached to it | The same terms text, read to the last line | A minimum spend or excluded category rejects it silently |
| The expiry as a printed date | "Valid while stocks last" is not a date | Ask for a date in writing and keep the reply |
| Whether it can sit alongside another code | The terms text again; rarely stated anywhere else | Enter 1 code, not 2, until a reply says otherwise |
| Whether the basket already satisfies all of it | Your own cart totals, added up by hand | Fix the basket first; the field is the last step, not the first |
The first check is the one people skip. A code can attach to the item subtotal, to the freight line, or to a service charge, and those 3 lines sit in different places in an order total. The [cost](/table/cost/) page breaks the same lines out one by one, and reading it once is faster than testing a code 3 times.
This note names no code, no expiry and no amount. Anything of that kind changes without notice, so the only verifiable copy is the one inside your own account.
How to find out whether a code still works, before you commit it
Three sources can tell you whether a code is live, and they are not equally good. The terms text inside your own account is the strongest, a written support reply is second, and a screenshot from a third party is the weakest, because it shows what was true on 1 day and says nothing about day 40.
- Read the terms inside the account, and screenshot the date the page shows alongside them
- Send 1 message naming the code and asking 2 questions: is it still active, and what does it attach to
- Keep the reply, with the agent name and the date, in the same folder as your order records
- Re-read the terms on the day you pay, not the day you first saw the code
Testing a code by entering it is the method with the highest cost, and the cost is not obvious. If an order is created with the code attached and you then cancel it, the code may already be marked as used, and getting it back means a support request rather than a second attempt at the field. One test on a basket you were going to place anyway is reasonable; 3 test baskets in one afternoon is not.
Why the split between the two payments decides what a code can reach
The [pay-domestic](/steps/pay-domestic/) stage settles the item, and the [pay-freight](/steps/pay-freight/) stage settles the international leg after the parcel has been packed and weighed. Two payments, two baskets, 2 totals, and the freight total does not exist at the moment you use the first one. A code bound to the item line is therefore spent on day 0 against a number that has nothing to do with what the parcel will cost to move.
The consequence is arithmetic rather than policy. On a 300-unit basket, the item stage offers a subtotal you can still edit and the freight stage offers a weight-driven number you cannot. A code attached to the editable side competes with a decision you still control, which is the cheaper place to spend it.
The reverse case is the one that burns people. If the code only attaches to freight, typing it at the item stage does nothing visible, and the natural response is to try it again in another form — which is how a single-use code gets marked as used without producing any reduction. When the terms do not say which line a code attaches to, ask before the first payment: 1 message now against 1 support ticket afterwards.
Item payment and freight payment are separate events with separate totals. Check which one a code attaches to before the earlier of the two, not after.
When five checks are not enough
Four situations fall outside the card, and each involves a step that moves value after the code has been consumed. A partial return that refunds 1 item from a 3-item order can reduce the subtotal the code was measured against; the code does not come back, and the refund is calculated on what you actually paid for that item.
- Merging a parcel after an item-stage code was used: the merge changes weight, never the item subtotal the code touched
- Partial returns that take the basket below a minimum spend written into the terms
- Cancelled orders, where the code went down with the order and only support can restore it
- Campaign windows with a start and an end printed in 2 different time zones
In each of those 4 cases the move is the same: 1 message, 1 question, and a written answer kept next to the order record. A reply that says the code will be restored is worth more than a second attempt at the field, because the second attempt is what marks it used.
The card is enough for a normal basket, and it is meant to take 2 minutes. It is not enough when a return or a merge is already in play, and there the honest answer is that the code question is smaller than the order question.
Flow dependency: item payment and freight payment are separate stages, so a code bound to the item basket is spent before the parcel weight — and therefore the freight total — exists. The five-check order on this card follows from that split, not from published code terms, and no code value is quoted.
This note explains the mechanics; the list is where the items are.