What Voucher Expiry Dates Mean in Pixalink
What Voucher Expiry Dates Mean in Pixalink
What Is This?
Pixalink uses three different expiry dates across the reward system. They live on three different things: the reward itself, the voucher code you upload, and the voucher your customer claims. Each one controls something different — this article explains which date does what, and what to put in the Expired At column when you upload third-party voucher codes.
How It Works
Pixalink rewards come in two flavours. Most rewards run without a voucher pool — Pixalink just hands out a fresh voucher to each customer. Third-party rewards (Shopify, WooCommerce, partner promo codes) run with a voucher pool that you upload upfront. Both flows are below.
Flow 1 — Standard reward (no voucher pool)
This is how about 7 out of 10 rewards work. The merchant sets the rules. The customer claims. Pixalink creates a fresh voucher on the spot.
sequenceDiagram
actor M as Merchant
participant R as Reward
participant V as Customer Voucher
actor C as Customer
rect rgb(219, 234, 254)
Note over M,R: Setup time (you do this once)
M->>R: Set End Date and Custom Valid Days
end
rect rgb(191, 219, 254)
Note over C,V: Claim time (per customer)
C->>R: Claim the reward
R->>V: Pixalink calculates Expired At<br/>from the reward's rules
V->>C: Voucher delivered
end
rect rgb(147, 197, 253)
Note over C,V: Use time (before Expired At)
C->>V: Redeem at outlet
end
Flow 2 — Third-party voucher reward (with voucher pool)
This is for partner promo codes. The merchant uploads a pool of pre-made codes. When the customer claims, Pixalink picks one from the pool — but still calculates the customer's Expired At from the reward's rules, not from the pool code's date.
sequenceDiagram
actor M as Merchant
participant R as Reward
participant P as Voucher Pool
participant V as Customer Voucher
actor C as Customer
rect rgb(219, 234, 254)
Note over M,P: Setup time (you do this once)
M->>R: Set End Date and Custom Valid Days
M->>P: Upload 3rd-party codes<br/>(Expired At per code, optional)
end
rect rgb(191, 219, 254)
Note over C,V: Claim time (per customer)
C->>P: Claim a code
P->>R: Read the rules<br/>(pool code's Expired At ignored)
R->>V: Pixalink calculates fresh Expired At
V->>C: Voucher delivered with the partner code
end
rect rgb(147, 197, 253)
Note over C,V: Use time (before Expired At)
C->>V: Redeem the partner code
end
The key difference: in Flow 2, the pool code carries its own Expired At, but Pixalink ignores it when creating the customer's voucher — it always recalculates from the reward's rules.
How Pixalink Picks the Customer's Expired At
flowchart TD
Start(["Customer claims a code"]) --> Q1{"Custom Valid Days<br/>toggle on?"}
Q1 -->|"No"| UseEnd["Use the reward's<br/>End Date"]
Q1 -->|"Yes"| Q2{"Reward has<br/>an End Date?"}
Q2 -->|"No"| UseDays["Use today + Valid Days"]
Q2 -->|"Yes"| Compare{"Which is earlier?"}
Compare -->|"today + Valid Days"| UseDays
Compare -->|"End Date"| UseEnd
UseEnd --> EOD["Set time to 23:59:59"]
UseDays --> EOD
EOD --> Done(["Save as Customer<br/>Voucher Expired At"])
style Start fill:#3b82f6,stroke:#1e3a8a,color:#ffffff
style Done fill:#3b82f6,stroke:#1e3a8a,color:#ffffff
style Q1 fill:#fef3c7,stroke:#92400e,color:#78350f
style Q2 fill:#fef3c7,stroke:#92400e,color:#78350f
style Compare fill:#fef3c7,stroke:#92400e,color:#78350f
style UseEnd fill:#bfdbfe,stroke:#1e3a8a,color:#1e3a8a
style UseDays fill:#bfdbfe,stroke:#1e3a8a,color:#1e3a8a
style EOD fill:#bfdbfe,stroke:#1e3a8a,color:#1e3a8a
Layer 1 — The Reward (your campaign)
The reward is the campaign itself. It has two date settings, no "Expired At" of its own:
- End Date — when the whole campaign closes.
- Valid Days — only used if you turn on the Custom Valid Days toggle. When on, it sets how many days each customer gets to use their voucher after claiming.
If the Custom Valid Days toggle is off, Valid Days is ignored — even if a number is saved.
Layer 2 — The Voucher Code (your uploaded pool)
When you upload a list of third-party codes (Shopify, WooCommerce, partner codes), each code sits in a pool waiting to be claimed.
Each code can have its own Expired At, but this field is optional — it's only there for third-party uploads. If you leave the column blank, Pixalink fills it in for you using the reward's rules. If you do set it, the code stops being claimable after that date, even if nobody has used it.
Layer 3 — The Customer's Voucher (what they hold)
When a customer claims a code, Pixalink calculates the voucher's Expired At fresh. It does not copy the pool code's date. Here's how it works, step by step:
- Start with the reward's End Date.
- Is the Custom Valid Days toggle on? If no, stop — the voucher expires on End Date.
- If yes, also calculate today + Valid Days. Use whichever date comes first (the earlier one wins).
- Always set the time to the end of that day (23:59:59).
If the reward has no End Date but Custom Valid Days is on, the voucher just gets today + Valid Days.
Real-Life Examples
Pixalink rewards use one of three expiry setups. We've ranked them from most common to least common based on how merchants actually configure their rewards.
Most common: Rolling expiry (no End Date)
Around 7 out of 10 rewards work this way — evergreen rewards like welcome gifts, birthday treats, and tier perks.
Aishah runs a cafe in Bangsar. She sets up a welcome reward with no End Date and Custom Valid Days 30. Every new customer's clock starts when they claim:
- Wei Lin signs up 5 December → his voucher expires 4 January.
- Siti signs up 28 December → hers expires 27 January.
There's no campaign close date — the reward just keeps running.
Common: Fixed campaign (End Date only)
About 1 in 4 rewards work this way — short campaigns where everyone gets the same deadline.
Ahmad runs a bakery and launches a Hari Raya promotion with End Date 30 April and Custom Valid Days off. Every customer who claims, no matter when, gets the same expiry:
- Priya claims 10 April → expires 30 April.
- Farah claims 29 April → also expires 30 April.
Simple and predictable for time-bound events.
Less common: Capped campaign (End Date + Valid Days)
Only about 3 out of 100 rewards use both — usually third-party voucher campaigns where the merchant wants a usage window inside a fixed campaign.
Wei Lin runs a bubble tea chain. He uploads 500 partner promo codes with End Date 31 December and Custom Valid Days 14:
- Aishah claims 5 December → her voucher expires 19 December (5 Dec + 14 days).
- Siti claims 27 December → hers expires 31 December (the campaign end caps it).
What to Set When Uploading Third-Party Vouchers
The Expired At column in the upload CSV is optional. You have two choices:
- Leave it blank (recommended for most cases) — Pixalink uses the reward's rules to fill it in.
- Type the campaign End Date — keeps every code claimable until the campaign closes.
If your partner's codes truly expire earlier (for example, "these only work until 15 December"), use that date instead.
Good to Know
- The customer's voucher expiry is locked in at claim time — editing the reward later doesn't change it.
- The pool code's Expired At is never copied to the customer's voucher (except for one case below).
- If you pre-assign a code to a customer during import by adding their phone number to the CSV, that customer's voucher does copy the pool code's Expired At directly.
- Customer vouchers always expire at the end of the day (23:59:59).
- Codes that expire while still in the pool are ignored — no customer ever sees them.
Need Help?
If you're not sure what date to put on your voucher upload, contact the Pixalink support team — they can check your reward setup with you.