Work · Benefits infrastructure / B2B platform
Fiyaka
Benefits, turned into infrastructure.
What it is
Fiyaka connects an audience — employees, dealers, partners or members — to discounts, perks and rewards through one infrastructure layer for eligibility, entitlements, fulfilment and verified usage.
Why it needed to exist
Every organisation runs benefits on a mix of negotiated deals, gift-card providers and spreadsheets, and none of those agree on who may claim what. Distributing benefits to different groups needs more than a catalogue.
What Idealink did
Idealink conceived Fiyaka in 2023, ran it as a product, and rebuilt it around the rules engine once it was clear where the value was. We design, build and operate the platform and its delivery modes.
- Status
- Live
- Relationship
- Idealink venture
- Industry
- Employee, dealer and member benefits
- Period
- 2023 — ongoing
- Platform
- Web platform · API · embedded
- Idealink role
- Concept, product, design, engineering, go-to-market
Thesis
A benefits catalogue is easy. Knowing who is eligible for what, how often, from which provider, and whether it was actually used — that is the product. Fiyaka is the platform evolution story: from an HR perk app to the layer underneath.
01
How the product changed
2023Perks for employees
Fiyaka launched as an employee motivation product: performance evaluations paired with gifts and discounts. Customers used the perks and ignored the evaluations.
2024 – 2025The rules underneath
Every customer brought their own benefit sources and their own idea of eligibility. The recurring work was normalising sources and encoding rules — so that became the product.
2026Infrastructure
Fiyaka is now delivered three ways — hosted, through a REST API with webhooks, or embedded inside a customer's own product — with merchant verification that works on a phone.
02
The core loop
Six stages every benefit passes through, whatever its origin.
Discover
A normalised catalog across the Fiyaka network, direct merchant agreements, a customer's own deals and external providers.
Target
Eligibility rules decide who can see and claim each benefit.
Control
Entitlements and limits: how often, at which tier, per order or per period.
Claim
Secure activation and fulfilment.
Verify
Merchants confirm usage through web, QR, a paired device, messaging or API/POS.
Measure
Claims, redemptions and utilisation per program.
03
Verification where benefits are used
Member QR, merchant channels and a merchant-verified redemption — the flow as shown on the product site.
04
Engineering
Multi-tenant: each program defines its own eligibility rules, entitlement limits and verification channels; a gym discount from the network and a fuel voucher from a customer's own agreement look identical to the program.
Provider adapters normalise gift cards, vouchers and digital rewards from external suppliers so no single supplier locks in a program.
API-first with webhooks, so platforms can run benefits inside their own software without leaving their brand. The hosted experience and the embedded experience share the same entitlement engine.
Sources, the eligibility–entitlement–verification core, and three delivery modes.
Outcome
Where it stands
The same entitlement system now supports hosted, API and embedded delivery, and one catalog serves employee, dealer, partner and member programs.
Operating Fiyaka is where Idealink learned how entitlement systems fail in practice — knowledge reused in payment, commerce and loyalty work for clients.
Stack and capabilities
Only what mattered
- Next.js
- TypeScript
- REST API
- Webhooks
- Multi-tenant architecture
- Provider adapters