On this page
A customer starts checkout before midnight and completes the order afterward. Another order is placed before the deadline but paid the next morning. A third appears to be exactly on the boundary when the timestamp is rounded for display. These cases cannot be resolved consistently until the reviewer identifies which event the offer uses to define the cutoff.
The task is to apply the timing condition already promised. Choosing a campaign duration, designing a time-storage system, and writing a complete set of promotional terms are different tasks. Here, the output is a defensible finding for a purchase near an existing boundary.
Find the controlling event in the published offer
Locate the offer version that applied to the customer. It should identify the relevant event, the period, and the timezone or another unambiguous timing basis. Possible events include placing an order or completing a specified payment condition. Beginning checkout is not automatically equivalent to either event.
For a hypothetical campaign, assume the approved wording requires an order to be placed before 00:00 UTC on 1 April. The wording makes the end boundary exclusive: an order at the boundary is outside this example’s period. This is a fictional rule used to illustrate the method, not a universal interpretation of promotional deadlines.
Write the rule in the review record before looking at individual cases. Doing so reduces the temptation to select whichever timestamp produces the preferred result. If the customer-facing wording instead uses an inclusive boundary or a named local timezone, the review must reflect that actual rule.
Shopify maintains different order-related statuses, as described in its order-status documentation. The practical consequence is to identify the specific event needed for the offer rather than choosing a convenient record merely because it belongs to the order.
If the offer says only “ends 31 March” and the available documentation does not establish timezone or boundary treatment, the reviewer has an interpretation issue. Preserve the ambiguity and seek a consistent authorized decision. Do not silently manufacture precision that the customer never received.
Compare boundary cases in one timezone
Normalize the comparison to the published basis while retaining the original evidence. For the example, all controlling-event times below are expressed in UTC. The relevant event is order placement, not checkout start or later payment capture.
| Case | Checkout began | Order placed | Timing result under the example rule | Reason |
|---|---|---|---|---|
| O-801 | 31 March, 23:40 UTC | 31 March, 23:58 UTC | Within period | Placement precedes the boundary |
| O-802 | 31 March, 23:59 UTC | 1 April, 00:02 UTC | Outside period | Starting checkout did not satisfy the stated event |
| O-803 | 31 March, 23:50 UTC | 1 April, 00:00 UTC exactly | Outside period | The example requires placement before the boundary |
| O-804 | 31 March, 22:30 UTC | 31 March, 22:35 UTC | Within period | Later payment timing does not change the placement finding |
| O-805 | Unknown | Display shows 1 April, 00:00 UTC, rounded | Unresolved | Exact event evidence is insufficient for a boundary conclusion |
The last row matters. A display rounded to the nearest minute may conceal seconds that determine the outcome. The reviewer should obtain the authoritative event detail available through the approved process rather than treating a rounded label as exact evidence.
For O-804, a timing pass is not a payment pass. If payment remains outstanding, the order can satisfy the campaign placement window while failing to meet another required condition yet. Record those results separately so one true statement does not accidentally become a complete qualification approval.
Timezones can create apparent contradictions. A customer’s receipt may display local time while the merchant’s review uses UTC. Preserve both values and the conversion basis in the case record. The goal is to explain that they refer to the same event, not to tell the customer that their receipt is wrong simply because its clock differs.
Preserve the decision for disputed timing
A completed case should identify the offer version, controlling event, boundary interpretation, source timestamp, timezone basis, and result. For O-802, the note could read: “Offer RB-TIME-04 requires order placement before 1 April, 00:00 UTC. The order placement record is 1 April, 00:02 UTC. Checkout began earlier, but checkout start is not the controlling event. Timing condition not met under the reviewed wording.”
If an authorized owner grants an exception, record it as an exception with its authority and scope. Do not alter the placement timestamp or pretend that the standard timing test passed. Keeping those findings separate preserves consistency for later cases and makes the customer remedy understandable.
A difficult case is a confirmed platform delay between the customer’s action and the recorded order event. The reviewer should preserve the available evidence and escalate the promise interpretation. It may be appropriate for an authorized owner to consider the circumstances, but a frontline reviewer should not invent a different event definition for one customer without a documented decision.
Another difficult case involves an edited or replacement order. A later administrative record may not represent a new customer purchase, or it may materially change the qualifying purchase. Establish the relationship before using the later timestamp. The order-version review addresses which purchase version is relevant; this timing review then applies the published boundary to the chosen event.
The final result should be reproducible without relying on memory or a screenshot of a rounded clock. It explains which event controlled, how the time was compared, and whether the evidence supports a pass, failure, or unresolved interpretation. That makes cutoff decisions consistent while preserving genuine uncertainty where the published promise or available evidence is incomplete.
Review campaign boundary cases before they reach your rebate approval queue.
Source references
This guide is general information, not financial, legal, tax or regulatory advice. Eligibility, card availability, permitted use and responsibilities depend on the applicable offer and card terms.
