Skip to content
Programme project

Invoice Mini App

Building inside somebody else’s ecosystem means their APIs define your product’s edges.

The product interfaces on this page are compositions built from each platform’s real module structure. They are not screenshots of production systems — these are private client and commercial platforms.

Role
Frontend engineer
Year
2025
Status
Delivered · ITS programme
Category
Product

An invoice generation and payment mini app built in React inside the SuperQi fintech ecosystem, integrating platform APIs for authentication, document scanning, payment processing, PDF viewing and file downloads across a full invoice workflow.

The problem

A mini app cannot own its own authentication, payment rail or document handling — it must borrow all of them from the host platform, and behave correctly when the host says no.

The outcome

An end-to-end invoice workflow — creation, sending, payment, transaction history — running entirely on host-platform capabilities.

Stack

  • React
  • JavaScript
  • Axios
  • REST API
  • PDF rendering

Services

Back to all work

Building on borrowed foundations

A mini app is an unusual engineering position. You do not control identity, you do not control the payment rail, and you cannot fall back to your own implementation when something is unavailable. What you control is how honestly your interface reports the host’s state.

  1. 01

    Create

    An invoice is composed, optionally from a scanned document via the platform’s scanning API.

  2. 02

    Send

    The invoice is issued to the recipient and becomes a payable record.

  3. 03

    Pay

    Payment runs through the host platform’s processing rather than a payment integration of our own.

  4. 04

    Archive

    The invoice lands in transaction history, viewable as a PDF and downloadable.

The invoice workflow, end to end.

Integration discipline

  • Authentication, scanning, payment, PDF viewing and downloads are all host capabilities — the app treats each as something that can be unavailable.
  • Axios-based communication with structured state management keeps request lifecycle and UI state separate.
  • The workflow is complete rather than partial — a half-built invoice flow is not usable at all.

Where it came from

I built this during my work and training at Qi Card, inside the Iraq TechSchool programme delivered in collaboration with Qi Card, Digital Zone, Computiq and HUB200 — which is why the fintech and digital-payment workflow concepts in it come from the industry partners rather than from a textbook.

It is a training project and I read it as one. The build itself is small. What I took from it is narrower than the feature list, and more useful than it.

  • Working inside a closed environment — SuperQi’s — where I did not control the platform, the APIs, or the constraints. The edges were set before I arrived, and the work was building something correct inside them rather than arguing with them.
  • Working from documentation: reading it closely, and verifying behaviour against it rather than assuming what a call would do.
  • Programme

    Iraq TechSchool — 6-month software engineering programme

  • Ecosystem

    SuperQi

Next case study

Building something in this space?

I am available for a limited number of projects. Tell me what you are working on.

Start a project