FidelyHub.

A thesis platform that connects several loyalty programs behind one API and one wallet. Admins configure each provider from a backoffice, and users check balances, rewards and activity without switching apps.

Tech-stack I used here

Origin and purpose

  • The problem is fragmentation: Each program arrives with its own auth, payload and pagination, so every new provider meant new code and a new release.

  • A thesis with a product shape: The goal was the full path: admin configuration, identity, API gateway, backend services and a mobile wallet, not a CRUD demo.

  • The reusable asset is the layer: A single-brand wallet would repeat the same integration work for every program; the abstraction layer is what makes the thesis reusable.

Decisions

  • One contract, seven operations: Validate user, balance, rewards, debit, reverse, activity and product viability share the same contract for every provider.

  • Configuration over code: Programs, credentials, endpoints, placeholders, JSON path mappings and OFFSET or CURSOR pagination are data, not releases.

  • Security by design: Credentials are encrypted with AES-256-GCM and scrypt, never returned by the API, while Keycloak and KrakenD enforce identity and roles at the edge.

  • Failures stay isolated: Balances and activity fan out with Promise.allSettled, and batch checkout uses a Go errgroup capped at five, so one provider cannot sink the wallet.

  • Webhooks with idempotency: HMAC-SHA256 signatures, a five-minute replay window and a unique event ID keep duplicate events out of the system.

One contract, every provider

FidelyHub configuration and runtime architectureClients authenticate through Keycloak and enter through the KrakenD gateway; the integration service stores provider configuration, the wallet service executes the same contract through the shared client, and the Transactions service in Go handles batch checkout.FidelyHub platformBackoffice + appadmins configureusers consumeKeycloak + KrakenDOIDC · RS256roles · routingIntegration serviceprograms · endpointswebhooks · live testsPostgres · Supabaseconfig · linksauditWallet servicebalances · rewardsactivity · checkoutTransactions serviceGo · batch debitaudit trailProvider APIsloyalty programsauth · payloadpaginationairlinebankhotelsupermarketConfigure once,execute through one gateway,keep providers outside.

Results

  • Eight pieces, one product: Next.js backoffice, Expo app, two NestJS services, a Go service, a shared client, KrakenD and Keycloak.

  • A provider without a deploy: The backoffice creates programs, connections, endpoints and webhooks, then runs live tests against the provider API before activation.

  • One wallet across programs: Consolidated balances, cross-program activity and cart checkout return per-program results, including partial failures.

  • Redemptions you can audit: Every checkout attempt stores the request, response, status, external transaction ID and authorization code.

  • Quality where it matters: Unit tests cover validators, endpoint strategies, webhook mapping and the Go executor; CI is path-filtered and deploys use keyless auth.