For years we have built short browser games for employees: marathons, onboarding, events for companies with thousands of people. The same engine works outside the company. A game can explain a product faster than a product page, and it can tell a bank something about a visitor before they ever fill in a form.
Here is one of those games: Cashback Run, built around a retail bank's cashback card. It's playable right here in the article, with sound, on a phone or a laptop.
It follows one rule. The game gives nothing away for free. The player earns points and levels, which cost the bank nothing, and sees an honest model of what the card would give back. Real rewards show up only where the bank makes money.
How can a bank use a short browser game to explain a cashback card and learn about a visitor before the application? Put the game where the decision happens, on the product page, and let people play before you ask them for anything.
The client
A retail bank or a neobank with four to six products: a cashback card, a savings account, investing, a loan, insurance. It has an acquisition budget and a separate problem with activation.
The problem
- The product page doesn't convert. People come to look at a card, read three paragraphs about cashback categories and leave. A benefit you have to calculate doesn't land when you just read about it.
- New customers don't use what they signed up for. They open the card, never turn on their categories and never hear about the savings account. The bank pays for acquisition and misses lifetime value.
- Traffic is expensive and bounces fast. The bank pays for the click and gets 40 seconds.
- Before the application, the bank knows nothing about the visitor except the UTM tag.
What we build
Four mini-games. Each one explains one product by letting people do it instead of reading about it. They sit right on the product page and play without sign-up. The first one is built and playable below. The other three are concepts.
| Game | Product | What the player does | What they take away |
|---|---|---|---|
| Cashback Run | Cashback card | Steers a bank card down a three-lane street, catching purchases: café, fuel, pharmacy, groceries. Everything pays 1%, and one category at a time pays 5%. The boosted category keeps changing. | Where the card pays more, and why choosing categories matters |
| The Cushion | Savings account | Life happens: the car breaks down, a vacation, a doctor's bill. The player splits money between spending and saving and sees if the month holds. | Why an emergency fund matters, without a word about interest rates |
| Hold the Line | Investing | The chart jumps around and the player has to resist selling on the dip. After 60 seconds it shows how sellers did against holders. | What volatility feels like, not just what it means |
| The Ladder | Premium package | Merges matching assets to climb a ladder of status levels. | How saving up works and what the next tier gives |
The lead game is Cashback Run. It's the most visual of the four and the closest to what banks actually sell.
Press Play. Swipe, tap the left or right side of the screen, or use the arrow keys.
How it plays
There's no timer. The run lasts until the first crash, and it gets harder the whole way.
- One category is boosted at any moment: 5% instead of 1%. It glows on the road and is named in the pill at the top, with a bar counting down to the next switch. The switch comes every 15 seconds at the start and every 8 seconds late in the run.
- The first collision ends the run.
- A clean streak multiplies points: ×2 after 10 purchases in a row, ×3 after 20. A trap purchase with zero cashback, the gray "0" coin, resets the streak.
| Time in the run | What shows up |
|---|---|
| 0–10 seconds | Single purchases, then the first barriers |
| 10–35 seconds | More barriers, and a delivery robot that blinks its turn signal and changes lanes |
| 35–75 seconds | Chains of purchases, double barriers, trap purchases, gate slaloms, and fog that cuts the visible road in half |
| 75 seconds and on | All of it, more often. The robot can cross the whole street |
Speed climbs until the third minute and then holds.
Two numbers, and why the game pays nothing
The player earns two different numbers, and keeping them apart is the main idea of the game.
- Points are the game currency: 10 for an ordinary purchase, 30 for one in the boosted category, times the streak. They add up across runs and raise the player's level, from Newcomer through Deal hunter, Category master and Cashback pro to Cashback legend.
- The cashback model is the small "Model $…" counter. It counts at the card's rates, 1% and 5%, and the streak doesn't touch it. The result screen says so in plain words: "A model at real card rates (1% and 5%), not a payout."
Our first version handed out $20 to $30 of cashback per minute of play. For a bank that's both untrue and a cost: cashback is paid out of the fee on a real purchase. So we split the two. The excitement lives in points and levels, which cost the bank nothing. The money is shown as an honest model at the card's rates. A flawless 40-second run comes to about $12 back on $379 of spending, an average rate of 3.2%.
The player's path
A visitor arrives from an ad and sees the game on the first screen. They play without signing up. At the end they get their points, their level, and a breakdown of what the card would give back on the way they just spent.
The demo above stops there, at the result screen and its two buttons. In a bank's version, this is where one question appears: want to see which card fits the way you spend? Only now does a contact field show up, after the player has already got something out of it. How someone plays shows which categories they chase, and that's the start of a personal breakdown.
The point of the design: people reach the product through their own behavior, not through a sales pitch. The breakdown at the end isn't an ad. It's the result of their own game.
Where a bank can use it
The same game fits several jobs. Four that we would start with:
1. A simulator on the product page. This is the path above: play first, then an offer to pick a card. It costs the bank nothing, because the game pays nothing. Measure time on page, the share who reach the result, and click-through to the application.
2. Picking categories in the app. Once a month a customer plays, and the result shows which purchases they caught most. The app offers to turn on those boosted categories with one tap. No cost beyond the cashback program the bank already runs, and it goes straight at the activation problem above: the customer who opened the card and never turned on their categories.
3. Partner prizes. For a good run the customer gets an offer from a partner instead of the bank's money: a free coffee at a café chain, a discount at a gas station, a pharmacy coupon.
- How it ties to the game. The four categories on the road are four partner slots. The boosted category of the moment can be sponsored: "Café 5%" with the chain's logo. The prize comes from the category where the player scored most.
- Who pays. The partner. It's buying attention and foot traffic. The prize costs the bank nothing.
- What the bank gets. The coupon redeems only when the customer pays with the bank's card, so every redemption is a transaction and a fee. Plus the partner's placement fee.
- What the partner gets. A customer who walked in and paid, and a report: impressions, coupons issued, coupons redeemed.
- What the customer gets. A reward they can use today, not half a percent someday.
- What it takes to launch. A pool of codes from the partner, or its API. Redemption tied to card payment by merchant ID. Limits per customer and per day. Partner rotation, so the game doesn't turn into an ad for one brand.
- Where it can go wrong. Weak prizes, and customers stop playing. A coupon that redeems without the bank's card, and the bank has no reason to run it.
4. The same game for employees. Tellers and call-center agents play it in training, so they can explain cashback categories to customers. That's a direct bridge to what we do every day: games for teams.
What makes it feel premium
This isn't pixel art. Retro works for employee events because it's nostalgic. On a bank's website it reads as cheap. Instead: clean 2.5D scenes, soft gradient light, a slight depth of field in the background, and the bank's own palette plus one accent. The mood of a calm, premium mobile game, not an arcade.
- No hard cuts. Every screen change is animated.
- Numbers count up instead of appearing. Score, cashback and balance tick up and slow down toward the final value.
- Easing everywhere. Objects have weight and inertia, and nothing moves in a straight line at constant speed.
- Every catch has feedback: particles, a slight camera squeeze, a tone that rises as the streak grows, and haptics on phones.
- 60 frames per second. Without it, nothing else on this list matters.
- An original score whose layers come in as the streak builds, not stock sound effects.
- The bank's own typography in a client build: the same fonts, corner radii and spacing as its website, so the game looks like part of the product and not a widget on top of it. The demo above uses system fonts and a made-up bank.
- The final screen is an infographic, not a "Game over". It's something the player wants to share.
What we measure
These are targets, not results we're reporting. Before launch we agree on them with the bank, then instrument every game and report how it performs against them.
| Metric | Typical product page | Target with the game |
|---|---|---|
| Time on page | 40–60 seconds | 3+ minutes |
| Reaching the result screen | Not measured | 60%+ of players |
| Click-through to application | 1–3% | 8–15% of players who reach the result |
| Contact left | Low single digits | 25–35% of players who reach the result |
| Return visits | Almost none | 2+ sessions per player |
| Played two or more games | — | 40%+ |
And one benefit worth saying out loud: for the first time, the bank gets behavioral data on a visitor before the application.
The game lives inside the bank's app
For a bank, the mobile app is the main channel and often the only one.
We don't build mobile apps. We don't make native apps, ship to the App Store or Google Play, or take over a client's release cycle. And none of that is needed. The game runs in the browser, so it opens inside the bank's app as a web view. There's nothing to download, no app-store release, and updating the game doesn't require an app update. We don't build you an app: we live inside the one you already have.
What we need from the bank:
- An entry point: a card on the home screen, a rewards tab or a push notification.
- A way to send the result back to the account the customer already has: their level, their points, the categories they chased.
- User identification, so the result reaches the person who played.
It's the same setup as plugging our employee games into a company portal. Outside, it's the bank's app. Inside a company, it's the intranet and the internal rewards store. We build it as one mechanism for both.
The bank in the game is made up. Rates and figures on the screens are examples.
We built a second consumer game on the same engine: a factory game for a snack brand, where a discount grows with the player's skill. And if you want to see how we build games around a specific job rather than from a catalog, read the four-departments case, or see how custom builds work.
Frequently Asked Questions
Do people need to download anything to play?
No. The game runs in the browser, the same way it runs in this article. On a website it sits right on the product page. In a mobile app it opens as a web view inside the app the customer already has, so there's nothing to install and no app-store release. Updating the game doesn't require an app update either.
Does the game pay out real cashback?
No. Cashback Run pays nothing. The player earns points and levels, which cost the bank nothing, and sees a model of what the card would give back at its real rates of 1% and 5%. Real rewards come only where the bank earns: a partner's coupon that redeems on a card payment, or boosted cashback on actual spending.
How do you know whether the game is working?
Before launch we agree on targets with the client: time on page, players reaching the result, click-through, contacts left, return visits. Every game is instrumented from day one, so the client sees each of those numbers against its target, along with the behavioral data from every session.
What does the game need from our existing systems?
Three things: an entry point (a page, an app card or a push), a way to credit the result to the user's account, and user identification so the result reaches the right person. If the app or loyalty program can't accept results from outside, we'll tell you on the first call what would need to change.