Industries · Fintech and payments

Payment platforms with compliance designed in.

A payments product whose data, access and audit decisions were made in sprint one, and an investor portal with documents per investor, offerings, commissions and an app, built and run in house for a group company.
Two financial products are written up here. Both carry requirements that are far cheaper to design for than to retrofit.
Case studies
1 project written up: PURPOSE PAYMENT.
Built for
Payment companies, investment firms, fund managers, lenders and fintech founders.
Typical scope
Secure web platforms, investor portals, admin consoles, mobile apps, controlled data access and audit trails.
Rated
4.7 / 5 from 23 Google reviews

In short

Financial products carry requirements that are cheap to design for and expensive to retrofit: where data lives, who may see it, and what has to be provable afterwards. Purpose Payment, a charity linked payments app, built its payment and charity rules into one API from the start. EIGHTClouds, an investor portal we built and run for a group company, carries documents per investor across a portal, an admin and an app.

What the sector asks of software

Three things every financial build has to get right.

Each one is drawn from a project on this site, not from a sector report.
01

Money rules belong in one place

On Purpose Payment, the payment, the charity share and the reward points are handled by one API that the customer app, the merchant portal and the admin console all share, so every screen shows the same numbers.

Purpose Payment

02

Investors want their documents, not a dashboard

EIGHTClouds gives each investor their portfolio, documents per investment and news, in a portal and a Flutter app, while the team manages offerings, agents, commissions, banks and brands from the admin.

EIGHTClouds

03

Every sensitive action has to be traceable

Who did what and when is recorded for every sensitive action, so an auditor or a regulator can be answered from the system rather than from memory.

EIGHTClouds

Case studies · Fintech and payments

The project behind this page.

Open any card for the brief, what we did and what changed for the people using it.

All case studies
01

Payments

PURPOSE PAYMENT

A payments app where every purchase at a participating store sends a share to a charity the customer picks, and earns points toward rewards.

Customers link their bank, scan the store's QR code, add a tip for the staff if they want to, and confirm. Part of the payment goes to their chosen charity, and the points they earn move them up tiers, unlock rewards and place them on a leaderboard.

View case

Sector notes

What building payments and investment platforms has taught us.

Two financial products, one a payments platform and one an investor portal, plus the payment flows inside our marketplaces and stores. These are the things we would say to a fintech founder or an investment firm before the first sprint.

01

Decide the hard things before the first screen

On Purpose Payment the hard questions were about how money moves: customers link a bank through Plaid, pay a store by scanning its QR code, and every order splits automatically between the store and a charity the customer chose. Those rules live in one API that the customer app, the merchant portal and the admin console all share, so a payment, its charity share and the points it earns are recorded together.

That is the lesson we take into every financial build: decide how money is split, stored and shown before the first screen, and keep that logic in one place. A payments product whose rules are scattered across its screens is a prototype, however good it looks.

02

Investors want their documents, not a dashboard

EIGHTClouds is an in house product built for a group company. Each investor sees their portfolio, the documents attached to each investment and the news that affects them, in a Laravel portal and a Flutter app that mirrors it. The team manages offerings, investors, agents, commissions, banks and brands from an admin, and a Next.js marketing site sits in front.

Running the product ourselves taught us what a portal is for. The dashboard is glanced at; the documents are what an investor downloads before a meeting with their accountant. Three surfaces, portal, admin and app, share one source of truth, so a document uploaded by the team is the document the investor opens on a phone.

03

Payments inside other products

Most of our payment work happens inside marketplaces, stores and subscription apps rather than in a standalone fintech product. Skills Sync uses Stripe setup intents so a customer saves a card once and rebooks without re-entering it. Teachers Lunch confirms card payments through webhooks and sends SMS and push updates as the order moves. Edsidera takes parent payments through Stripe on its own portal. Pioneer Auctions settles bids through PayTabs in English and Arabic.

The pattern is the same in every case: the payment provider confirms through a webhook, the API records the result, and the product never trusts a client's word that a payment happened. Subscriptions, plans and coupons live in the API, as on My Places and Brilliant Teaching, so billing does not run on support tickets.

04

The admin is where the money is actually run

On EIGHTClouds the public portal is the smaller half of the product. The admin is where the team creates offerings, onboards investors and agents, records commissions, manages banks and brands and uploads the documents that investors will later download. If that console is slow or incomplete, the finance team falls back to spreadsheets and the portal quietly stops being the source of truth.

So the admin is scoped with the same care as the investor facing screens, with roles that match how the team actually divides the work and a trail on every change. The same rule applied to Purpose Payment, whose admin console runs customers, merchants, charities, payouts and reports.

What we build

From the first sprint to the audit.

Each capability below has shipped for a payments or investment product, or inside the payment flows of our marketplaces.
Explain your project
  • Payment platforms

    Controlled data access, provable actions and a review that signs off rather than sends you back.

    The security review signs off instead of sending you back.

  • Investor portals and apps

    Portfolio, documents, offerings and news per investor, with the same data on web and mobile.

    Investors download the document they need before the meeting.

  • Back office and commissions

    Offerings, investors, agents, commissions, banks and brands managed from one admin.

    Offerings, agents and commissions managed in one admin, not a spreadsheet.

  • Payment integrations

    Stripe, PayTabs and card flows with webhook confirmation, used across our marketplaces and stores.

    Every payment is confirmed by the provider before the product trusts it.

  • Access control and audit

    Roles decided up front, every sensitive action logged with who and when.

    Any auditor is answered from the system, with who and when.

  • Subscriptions and billing

    Plans, tiers and saved cards handled inside the API, so finance does not run on support tickets.

    Plans, tiers and saved cards run without support tickets.

How it ships

How a payments or investment platform ships with us.

The path Purpose Payment and EIGHTClouds took, from the data model to launch.

Your briefPayments, investment or lending team

Discovery

  • Data, access and auditSprint oneStorage, roles and the audit trail written into the data model.
  • Map every surfacePortal, admin, appOne source of truth for investors, offerings and documents.

Build

  • Core platformLaravel or NestJS, controlled accessEvery sensitive action recorded with who and when.
  • Provider integrationStripe, PayTabs, webhooksMoney is confirmed by the provider, never by the client.
  • Portal and appNext.js, FlutterDocuments per investor on desktop and phone from one truth.
Delegated to
Backend engineerSecurity reviewerFlutter engineerQA lead

Quality

  • Security reviewA checkpoint, not a surpriseSigns off what was designed for, before launch rather than after.
  • Reconciliation testsWebhooks, payouts, statementsEvery payment path proven against the provider's record.
  1. ApprovedClient sign off per release
  2. ObserveTwo weeks of live use
  3. Live and handed overCode, cloud and docs are yours

Numbers from the work

What the financial projects delivered.

Taken from the case studies, not rounded up.

4

connected Purpose Payment products: customer app, merchant portal, admin console and API

39

Purpose Payment app screens designed, from sign up to rewards

3

EIGHTClouds surfaces: portal, admin and app

Every order

on Purpose Payment sends a share to the customer's chosen charity

Questions fintech and investment teams ask us

We design for it before writing screens.

Data storage, access rights and the audit trail are agreed in the first sprint, before any screen is designed, so a security review checks a design instead of discovering gaps.

Tell us what the business needs. We will tell you what to build first.

Schedule a free consultation and get a written recommendation, with costs, before you commit to anything.

Get in touch

PROVEN RESULTS

4.7 / 5from 23 Google reviews