Employee Benefits Card

In Spain, companies can give employees pre-tax money for meals and transport. The catch is it has to go through a special card that only works at approved merchants. Most small businesses skipped the benefit entirely because existing providers made it painful: paper vouchers, doing the maths by hand every month, months of wait before any tax savings.

Factorial already had an employee expense card. The obvious move was to add benefits onto it. But that card was a live product with its own payment infrastructure, and changing how it worked meant risky changes to something people already depended on. I made the opposite call: build the benefits card as its own separate thing. Cheaper to build, faster to launch, and safe to test without touching the expense product.

The same three problems showed up in every interview, no matter the company size.

HR was drowning in admin. Vouchers and reimbursements got processed by hand every month in a spreadsheet.

Employees barely noticed the benefit. Reimbursements showed up in payroll a month after they spent the money. By then it felt like nothing.

Compliance was all manual. Someone had to check each merchant category code to confirm the spend qualified for the tax exemption. Every receipt was an audit risk.

We talked to HR managers and employees in Spain, Portugal, and Italy. Spain and Portugal share most of the same rules. Italy was different enough that we left it out of the first version and prepared a clean way to add it later.

With the engineers and the legal team, we set up the benefits card as its own payment programme through Stripe, separate from the expense card. The card only works at approved merchants, has spending limits, and tracks individual budgets per employee. All of that is handled by the card provider, not by our app.

I designed the transaction screen focused on three things: showing the employee what happened right away at the shop, clear explanations when a payment gets declined, and one report HR could download the day after each month ends. We tested it with HR teams and employees, then launched what worked.

The card goes through six stages: discovering it in the benefits section, signing up, setting up the account and verifying the company, getting the card, using it and tracking spending, and exporting everything to payroll.

Payments go through automatically at approved merchants. The employee taps, and that same day they see a transaction line they actually understand. HR gets a live spending chart, can adjust budgets on the fly, and downloads a payroll-ready file at the end of the month.

The hardest screen was the decline reason. A confusing message at the shop counter is the moment that kills trust in the whole benefit. We rewrote the standard decline codes into four reasons the employee can actually understand, each with a one-tap fix.

HR admin work dropped 40% in the first month.

A quarter of employees started using the card in the first three months.

EUR 220k in new revenue over the first five months. This was a feature that had been completely absent from the platform.

This first version also became the foundation for four new benefit types we launched later. The spending tab that came out of this project is the same one running Health Insurance, Childcare, Training, and Wellness today.

Decline reasons are a design problem, not a translation problem. Every rejection at a till is a chance to keep or lose trust in the whole product. The cheapest moment to fix that is the copy.

Compliance speeds you up if you bring them in early. Half the speed we shipped at came from running flows past compliance during wireframing, not waiting for legal review.

The card is an activation strategy, not a product strategy. It makes the benefit visible. Whatever lives on the card is what people actually use.