Seatfrog gift cards
What ran in 2024, what it earned, why it was paused, and what we'd want to line up to bring it back for November.
Gift cards sold steadily in 2024 and carried a healthy margin — though 43% of vouchers were never redeemed, roughly 115 of the 268 sold, worth about £6,020. That unspent value is the largest single contributor to the net income. Worth confirming with Conor whether these are still the latest numbers, or whether he has anything more recent.
The proposition clearly has an audience. What it has never had is a proper redemption journey behind it — in 2024, activation ran through Customer Support adding credit to accounts by hand. It worked, but it might not be the route we'd want to take again, so the main thing to work through together is how we'd set it up this time, while there's still runway before November.
What actually happened
A gift card storefront ran on VoucherCart, a third-party platform, entirely outside Braze and outside the app. Creative was built in November 2024 and it traded across Black Friday and Christmas 2024.
The economics — two readings
Conor's model is on the left, exactly as posted in Slack. On the right is the same data with the commission applied only to vouchers that were actually redeemed. The note underneath explains the difference between the two.
| Total sales | £14,000 |
| Seatfrog commission @ 20% | £2,800 |
| Breakage @ 43% | £6,020 |
| Net income to Seatfrog | £8,820 |
| Margin | 63% |
| Total sales | £14,000 |
| Redeemed (57%) → commission @ 20% | £1,596 |
| Unredeemed (43%) → kept in full | £6,020 |
| Net income to Seatfrog | £7,616 |
| Margin | 54% |
The two arrive at different totals — £8,820 against £7,616 — and the difference comes down to how the 20% commission is applied.
The version on the left takes 20% of the full £14,000, including the 43% of vouchers that were never redeemed, and then counts that same unredeemed value again as breakage. The version on the right takes commission only on the 57% that were actually used, and keeps the unredeemed 43% in full.
Which one holds depends on what the 20% represents. If it's our margin on a redeemed upgrade, with the balance going to the operator, the right-hand version is the one that works. Quick one to check with Conor, as he knows the commercial terms — it's a difference of about £1,200 either way.
All 268 vouchers, under different redemption rates
| Scenario | Net income | Margin |
|---|---|---|
| If nobody redeemed | £14,000 | 100% |
| What actually happened — 43% unredeemed | £7,616 | 54% |
| If everybody redeemed | £2,800 | 20% |
- If every voucher had been redeemed, net income would have been around £2,800 rather than £7,616 — so a large share of the return came from vouchers going unused.
- Set against that, the average lifetime value of a customer who actually transacts is £153 (median £56 — marketing semantic layer,
AVERAGE_LIFETIME_VALUE). A gift recipient who redeems and goes on to buy is worth considerably more over time than the roughly £52 kept on a voucher that is never spent. - Do we know how many of these were new customers, and how many were already customers? I've found some data indicating the majority were already existing customers.
Who actually redeemed
The 153 redeemed gift cards were taken up by just 55 people — so most redeemers used more than one.
New customers from gift cards
Of those 55, 11 were new — no purchase before the voucher. 7 of them went on to transact, with an average lifetime value of £39.42, against a £153 average (median £56) for a transacting customer.
Existing customers who redeemed
The other 44 were already customers, and their average lifetime value is £948 — far above the £153 average (median £56) for a transacting customer. The median is £408, so it isn't one outlier pulling it up. Gift cards were being used by some of our most valuable existing customers, not by new ones.
The 115 that were never redeemed
I haven't been able to establish who bought these. It isn't possible to tell whether they were bought by new customers who couldn't work out how to redeem them, or were multiple purchases by customers who had already redeemed and simply never got round to the rest.
The redemption, customer and lifetime-value figures in this section were pulled and analysed by me directly from the warehouse. They have not come from an existing report and have not been validated by Analytics. The underlying credit records are tagged by hand in free text, and some of the groups are very small.
They should be reviewed properly by a data analyst to confirm the figures are accurate before any commercial decision is taken on them.
The creative that ran
Posted by Rob Sangar on 13 November 2024 as a VoucherCart storefront preview, with two voucher PDFs the following day. Note there is no gift card email anywhere — no campaign, template or send exists in Braze. All customer contact was handled by VoucherCart's own system.
class. Enjoy the upgrade!
Price points offered
Delivery: eVoucher, delivered instantly by email. An "Add as a gift" option let the buyer personalise it. Listed on the storefront under the category Special Offers.
Storefront copy, verbatim
The bad user journey everyone refers to is printed on the creative itself. A gift recipient has to download an app, create an account, then email customer support and wait for a human to credit them. It was highlighted in red on the original preview in November 2024 — a year before the campaign was dropped for exactly this reason.
It also explains the breakage. Two in three Black Friday vouchers went unredeemed, and this is almost certainly why.
Source files on Slack
- Voucher storefront preview — Rob Sangar, 13 Nov 2024 (the screenshot above is based on this)
- Gift card voucher PDF — afcca7 — 14 Nov 2024
- Gift card voucher PDF — e8668f — 14 Nov 2024
- The storefront itself — reported inactive as of Aug 2026
Why it was shelved
It was formally removed from the GTM calendar on 17 November 2025 by Sam Ayles:
Three months earlier, the same conclusion had been reached in the renewal thread. Sarah Conrad was supportive in principle but called it a pull, not a push: surface gift cards where people already look — website, app — and promote only at natural moments (Black Friday, Christmas, back to school). There was no bandwidth for a campaign, and she flagged it as product-marketing work. Sanderson's question in the same thread has never been answered:
What "requires ProdEng support" means
The GTM note does not itemise the work, so the following is assembled from the surrounding record rather than quoted from a spec. It is consistent across every thread.
- There is no gift card system. There never was. VoucherCart is a third-party storefront bolted on the side. Rob Sangar said in October 2024 that tracking who bought them and why would "factor into decisions on whether we build a real gift card system" — that decision was never taken.
- Redemption is manual, by a human, by email. The voucher tells the recipient to email support@seatfrog.com with their account email address and voucher code, and wait for someone to add the credit by hand. That instruction is printed on the creative itself.
- Codes were tracked in a spreadsheet, and it broke. In December 2024 codes went missing from the sheet, CS could not tell customers what their vouchers were worth, and Sanderson flagged that customer support did not have time to keep chasing.
- We do not own the interface. Ulrike: "we don't own the vouchercart UI and I'm not sure if we can add custom text." So the journey, the wording and the branding cannot be fixed from our side.
- There is no way in from the app. The gift card tile was removed at some point before July 2025 and customers were still emailing in asking how to buy. The storefront stayed live and unlinked.
- Product restrictions blunt the gift. A £3 platform fee is charged per seat on upgrades, and gift cards cannot be used on Secret Fare at all.
In December 2024 the VoucherCart merchant account in Adyen was found to be running on a weaker fraud profile than the main ecom account, and was being used to launder stolen cards through small voucher purchases. Scott Brown fixed it by copying two cardholder-name rules across. It was handled — but if the storefront is reactivated, confirm those rules are still applied before it takes a single payment.
Where it stands today
The subscription was renewed in August 2025 for a year, and the account is described as inactive as of last month. Is the VoucherCart contract still live, and is the storefront still able to take a payment? That single answer decides whether this conversation is about restarting something or rebuilding it.
Discussion points for a November relaunch
Not a list of blockers — these are the areas worth talking through and deciding how far we want to go on each. Some may be quick, some may not be worth doing at all this time round.
| Area | Why it's worth discussing | Who'd pick it up |
|---|---|---|
| Automatic redemption | The single biggest lever. Removes the email-support step, removes the spreadsheet, removes the CS load, and almost certainly cuts breakage — which is also the thing that makes the current margin look good, so decide deliberately. | Product & Engineering |
| An entry point in the app or on the website | Conor's own words in August 2025: it's "pretty hidden away". A pull strategy needs somewhere to pull from. | Product · Marketing |
| Confirm the storefront is live and the contract current | The account is reported inactive as of August 2026. | Conor |
| Re-verify the Adyen fraud rules | Two cardholder-name rules were added in Dec 2024 after the fraud episode. Confirm they survived the risk-profile work done in July 2025. | Engineering · Finance |
| Resolve the product restrictions | The £3 per-seat fee and the Secret Fare exclusion both make a gift feel less like a gift. | Product · Commercial |
| Decide who owns it | Sarah Conrad called it product-marketing work in Aug 2025. It has had no marketing owner since. | Sheran |
Questions to put to Conor
- Is the VoucherCart subscription still active, and can the storefront take payments today?Everything else follows from this.
- What does VoucherCart actually cost us, and what does it do for that?Sarah asked this in August 2025 and the thread moved on without an answer.
- Is there an automated redemption option on the platform we never turned on?If redemption can be fixed in VoucherCart rather than by ProdEng, the whole blocker changes shape.
- Can we confirm the redemption picture, and is there anything more recent?The figure I've been working from is 43% of vouchers unredeemed — around 115 of the 268, worth about £6,020. Is that still the best view, and have any redemptions come through since? One thing to be aware of either way: if we improve the redemption journey, the margin will look different.
The 2024 creative
What the gift card programme actually looked like to a customer. Assets from Drive, built September 2024.
The hero
“Give the gift of travel swagger.” Seatfrog green, the mark in sunglasses. Confident and on-brand — the selling half of this worked.
It's the three steps underneath that tell the real story.
The customer journey, as designed
What it could be spent on
Tickets, Upgrades and Train Swap. Worth noting the voucher creative also carried two restrictions in the small print: a £3 platform fee per seat on upgrades, and no use at all on Secret Fare.
Investigation phase
What we're looking into now, and the questions we still need answered.
Added 17 September, following conversations with Sam, Lisa and Harrison. Nothing here is decided.
Potential suppliers
Research in progress — to be filled in as we go.
| Supplier | Link | Notes |
|---|---|---|
| VoucherCart | vouchercart.com | The incumbent. Used in 2024; account reported inactive as of Aug 2026. Redemption was manual, and we couldn't customise their interface. Our storefront was at seatfrog.vouchercart.com. |
| Gift Up! | giftup.com | UK company, Bristol. No subscription, 3.49% per card sold. Free API, and a pre-provisioned option that would let us use our own discount codes with no engineering. |
| Voucherify | voucherify.io | Poland, Katowice. API-first redemption engine with no storefront — we would build the buying flow. Free tier, then roughly $170–599 a month. |
| Do it ourselves | — | Generate our own codes and take payment through our own site. No commission, no third party, codes natively ours and the landing page on our own domain. Needs three changes to the existing discount code system — see below. |
Whose codes are they? Everything else follows from that, and it is not yet decided.
If the supplier issues the codes, our app has to call out to them to check a code is valid and tell them it has been spent. That is an integration, and it is the thing that decides how quickly this can launch.
If we issue the codes ourselves, the supplier only has to take a payment and email a code. Redemption then needs no integration at all, because the code is already native to our app — the customer types it into the field that exists today and it simply works. That is the one area where our own codes are clearly better.
The trade is that we would take on the three build items in Option 4, and own the whole lifecycle ourselves. The options below should be read against that question rather than in isolation.
The four options at a glance
| Option | Based | Cost | Shop included? | How redemption would work |
|---|---|---|---|---|
| VoucherCart vouchercart.com | UK, Edinburgh | £25–75/mo, 17% off annual + commission from 4% | Yes, hosted | Dashboard, staff app, or API. We used the dashboard in 2024 and it was manual. |
| Gift Up! giftup.com | UK, Bristol | No subscription 3.49% per card sold | Yes, hosted or embedded | API: check code, apply, redeem full or partial. Or we supply our own codes. |
| Voucherify voucherify.io | Poland, Katowice | Free tier, then ~$170–599/mo | No — we build it | API only. Built for redeeming in an app. |
| Ourselves | — | Payment processing only | No — we build it | Native. No integration, because the code is already ours. |
Who creates the codes — the two routes
| How it works | Advantages | Disadvantages | |
|---|---|---|---|
| A · Supplier creates them | They generate and sell the codes. Our app must call their API to check a code is valid and tell them it has been spent. | Nothing to build on the code side. Balances, expiry and lifecycle are all handled by them. Partial balances come as standard. | Requires an integration before launch. Our discount field almost certainly only accepts codes from our own system today, so this is engineering work of unknown size. |
| B · We create them | We mint a batch and hand them over. The supplier only takes payment and emails the code. Both VoucherCart and Gift Up! support importing our codes. | No redemption integration at all — the code is native, so the existing field works as it stands. No dependency on a supplier's uptime. | Needs three changes to our code system (bulk minting, expiry, product restriction). Fixed denominations only. We own the whole lifecycle, including knowing what is unspent. |
The customer journey, by option
| VoucherCart | Gift Up! | Voucherify | Ourselves | |
|---|---|---|---|---|
| Where they buy | Their hosted page | Their page, or embedded on our site | Page we build | Page we build |
| Who takes payment | Our gateway, via them | Our processor, via them | We do | We do |
| Who emails the code | They do | They do | We do | We do |
| Whose domain | Theirs | Theirs or ours | Ours | Ours |
| Landing page to build? | No | No | Yes | Yes |
| Universal link risk | Avoided — their domain | Avoided if hosted by them | Needs care on our domain | Needs care on our domain |
On our own codes: whether we can mint them in bulk without a link click, whether they can carry an expiry, whether they can be restricted to upgrades, and how long any of that takes to build. The machinery exists but those three gaps are real and unmeasured.
On supplier codes: whether our discount field can accept a code that did not originate in our own system. It almost certainly cannot today, which is the whole integration question — but nobody has confirmed it either way.
On both: whether we can limit a code to one use per customer, and restrict it to upgrades, as Conor asked. These are questions for engineering, and the answers decide whether November is achievable.
| Plan | Pay monthly | Pay annually | Per year |
|---|---|---|---|
| Business — 1 sales page, 5 users | £25/mo | £20.83/mo | £300 → £250 |
| Pro — 10 locations, 25 users | £75/mo | £62.50/mo | £900 → £750 |
| Enterprise | Contact sales | ||
How redemption works on VoucherCart. There are three ways a voucher can be marked as used:
- Dashboard Redeem — a staff member logs into the VoucherCart admin and marks the voucher as used by hand.
- VoucherCart Redeem App — a mobile app for staff, with NFC readers and QR code scanners, so a voucher can be scanned in person.
- API Redeem — programmatic, through their REST API, with no human involved.
We used the first one in 2024 — and the "staff member" was our customer support team. API Redeem was available on every plan the whole time.
Why it ended up that way. VoucherCart is built for venues — restaurants, hotels, spas. Someone arrives holding a voucher, a member of staff scans or types it, and it's done. All three methods assume our side marks it redeemed.
Our case is different. A voucher has to become credit on an account inside an app, with no staff member present. That isn't the default shape of the product, which is why it fell to support to do by hand.
One feature worth knowing about. They offer Voucher Code Import, which lets us bring our own codes in rather than using theirs. That is potentially how we generate codes in whatever format our app's discount field expects, instead of hoping theirs happen to fit.
| Included on every plan | Why it matters to us |
|---|---|
| REST API + API Redeem | The route to automated redemption. It existed in 2024 and wasn't used. |
| Unredeemed Vouchers Report | Exactly the question nobody could answer — who bought the 115 that were never used. |
| Data export | Purchase-side visibility. None of this reached our warehouse last time. |
| Voucher Code Import | We could supply our own code format rather than taking theirs. |
| Payments via our own gateway | Explains the Seatfrog_VoucherCart account in Adyen. |
| Email promotions | Their sending engine — which is why no gift card email exists in Braze. |
So could it work? On paper it fixes the two things that broke in 2024 — redemption and data — provided the API can validate a code inside our app. It doesn't fix branding, since we couldn't customise their interface last time and there's no sign that's changed, and we'd still want Braze sending the emails rather than them. Cost isn't a deciding factor either way.
Not "can redemption be automated", because they will say yes and the API is on every plan. Ask instead:
When a customer types a VoucherCart code into our app's discount field, what has to happen for that to validate and apply credit? Does our backend call your Redeem API, and what does that integration actually involve?
This is an engineering question as much as a commercial one, so we should have engineering on the call before committing to a supplier. The answer decides whether this is a short build or a long one. Worth asking Conor separately whether the API was ever looked at in 2024.
| What you pay | Rate | Notes |
|---|---|---|
| Per gift card sold | 3.49% | Minimum $0.50 per card. Roughly £490 on 2024's volume. |
| Complimentary cards we issue ourselves | 1.99% | Staff gifts, compensation, goodwill. |
| Monthly subscription | £0 | No monthly fee, no setup fee, no contract. |
| Payment processing | 1.4–2.9% | Our own gateway, our own fees — same model as the Adyen account we already have. |
How redemption works. Three API calls:
- Get a gift card by code — validates the code exists and returns whether it can be redeemed, plus the remaining balance.
- We process the order, discounted by up to that balance.
- Redeem a gift card — full or partial, so a balance can be spent across several transactions.
Partial redemption matters for us: a £50 gift card against a £35 upgrade leaves £15 for next time. They also state that applying a balance against a customer account, rather than a single order, “follows the basic steps above and can be accommodated easily” — which is our credit model.
How this maps onto what we already have. Their integration guide says, almost word for word:
“To accept gift cards on your custom checkout all you need to do is have an input field (or use the existing typical ‘enter your promo code here…’ field) that asks for our 5 character alpha-numeric, unique gift card code.”
We already have that field — it is the discount code screen shown further down this section. The flow becomes: customer types the code, our backend checks it with Gift Up!, credit is applied, and we tell Gift Up! it has been spent. No support, no email, no spreadsheet.
Gift Up! also offer a pre-provisioned option: “You can upload codes to Gift Up! for set values (i.e. 10 codes for £100 each, 10 codes for £50 each) and we'll sell them for you. This approach assumes your app supports the ability to create discount codes in advance.”
Our app does. We generate a batch of our own discount codes, hand them to Gift Up!, they run the shop and sell them, and the customer types the code into the field that already exists — because it is a native Seatfrog code, not a third-party one.
That sidesteps the API question, the engineering question and the November timeline in one move. We would lose partial balances and be fixed to set denominations, but for a first seasonal campaign that may be a perfectly good trade.
What to check with them. Fees are quoted in dollars, so confirm GBP billing and UK contracting. Then three questions that come straight out of our own 2024 data: can our discount codes be restricted to upgrades only, as Conor asked; can they be limited to one use per customer; and are we comfortable with fixed denominations only on the pre-provisioned route, given the 2024 creative offered a custom amount.
What's different. Voucherify is a redemption engine, not a shop. It issues, validates and redeems codes through an API, but it does not give us a page where a customer buys a gift card — we would build that ourselves.
| Cost | Advantages | Disadvantages |
|---|---|---|
| Free tier (1,000 API calls a month), then roughly $170 / $399 / $599 a month by volume | Purpose-built for redemption in an app — sub-50ms validation, real-time balances, partial redemption. Handles coupons, referrals and loyalty in the same platform. | No storefront, so we would have to build the buying journey. Polish company, no UK entity or phone support. Most expensive of the three. |
Is it worth pursuing? It depends entirely on the question above. If we go with supplier-issued codes, this is the strongest option technically — it is built for exactly the redeem-in-an-app flow we need, where VoucherCart is built for staff redeeming at a till. If we issue our own codes, we do not need a code engine at all and this becomes redundant. Worth keeping on the table until that decision is made, and worth knowing it exists if incentives ever become a wider strategy beyond gift cards.
This is the other answer to the question above, and it is not a decision we have taken — it is an option to weigh against the three suppliers. If we issue the codes, a supplier only has to take a payment and email one. I have looked at what our discount code system already does, and the machinery largely exists.
What's already there. Codes work on a parent-child model: a campaign code seeds it and the backend mints a unique individual code per user. Around 22,750 distinct codes have been issued across 29,262 discounted sales, and 98.7% were redeemed exactly once. Per-code usage caps are configurable — an August 2026 batch used a limit of one — and fixed-value codes at £3, £5, £6 and £10 have all been issued. This is a pattern we already run, not something new.
What's missing. Three things, and each is a real gap rather than a detail:
- Codes are minted on demand, not in bulk. Today a code is generated when a customer clicks a link. A gift card campaign needs a batch pre-minted and handed over before anyone clicks anything.
- There is no expiry. No expiry or valid-until field exists anywhere in the code tables. Gift cards usually need one, for accounting as much as anything.
- There is no product restriction on the code. Conor wants redemption limited to upgrades to prevent abuse, and the code itself carries no product scope.
Worth adding that there is no code status table either — redemption is inferred from sale events rather than tracked against the code. Without that we would have the same blind spot as 2024 on which gift cards are still unspent.
This is three incremental changes to something that already works, not a new build. That is a much better question to take to Lewis, Rob or Harrison than “can we do gift cards”. Specifically:
We can already mint unique, fixed-value, single-use codes. What would it take to (a) generate them in a batch of, say, 300 without a link click, (b) add an expiry date, and (c) restrict them to upgrades only?
Lewis Putz wrote most of the Journey 4 backend and would know this system best. The answer to that question tells us whether a November campaign is achievable, and whether we need a supplier at all or simply a way to take payment and deliver a code.
In-app placement options
| Option | Who owns it | Pros | Cons |
|---|---|---|---|
| Content card | CRM / Braze | No design or engineering resource. Fully ours to run | Sits below the fold on the home screen, engagement is low. A supporting placement rather than a main channel |
| In-app pop-up | CRM / Braze | Much bigger reach, hard to miss | Interrupts the customer and could affect funnel metrics. Needs Product alignment and a small test first |
| Landing page | CRM, hosting TBC | The preferred route — used before and works well | Links sent from Braze can open the app instead of the page |
Where the landing page lives
| Supplier's page | Our WordPress page | |
|---|---|---|
| Universal link problem | Likely avoided — their domain, our app doesn't claim it | Avoided — Harrison's recommended fix |
| Branding and design | None. We get what they give us | Full control |
| Speed to launch | Fastest, already exists | Needs building |
| Tracking | Whatever they provide | Ours |
| Known risk | We couldn't customise VoucherCart's page at all last time | Build time, and ours to maintain |
Questions for suppliers — the customer journey
| Stage | What we need to know |
|---|---|
| Buying the voucher | Where does the customer land when they click our email or in-app link — their page, or one we control? Can we track that click through to purchase, and does the data come back to us? |
| After they've bought | What does the buyer receive — an email, a PDF, a code on screen? Can they forward it to the person they're gifting it to, or does the supplier email the recipient directly? |
| Redeeming it | Does the recipient have to go and open the app separately, or can we link them straight into it? Can we deep link from the voucher into the app with the code already applied? Does the code work with our existing in-app discount code entry, or does it still need support to apply it? |
| Controls | Can we restrict redemption to upgrades only? Can we limit it to one redemption per customer? |
The redemption chain. Last time the answer was "email support and wait", which is the most likely reason 43% of vouchers went unused. Whether a supplier's codes work with our existing in-app entry is the question that decides whether this is worth doing at all.
What exists in the app today
Conor confirmed the app now accepts a code directly, which removes the support step that broke the 2024 journey. It sits on the bid confirmation screen, and opens a modal to enter the code.
This is a discount code field. We are assuming a gift card or voucher code from a supplier will work through it — but that has not been confirmed, and it is not the same thing.
This needs to be established in the first conversation with any supplier. If their codes don't flow into this field, we are back to customer support redeeming by hand, and that is the one outcome we cannot repeat. Whatever the mechanism, it has to be automated.