P

Paypr

App

Digital receipts centralised, wired straight to the payment.

Role
Full-stack development
Category
App
Core stack
React Native · Next.js · Supabase
01The context

The paper receipt is vanishing, replaced by digital ones sent by email, by text, or locked inside each retailer's own app. The result is paradoxical: everything is digital, and nothing is findable. Claiming a warranty six months later turns into a treasure hunt.

02Problem, solution, outcome
The problem

Digital tickets and receipts get lost, quickly become unusable, and purchase information is scattered across apps and merchants.

The solution

An app that links receipts to the payment system to centralise them automatically, remove unusable ones, and keep every purchase detail in one place.

What it changes

The receipt is no longer something to file: it arrives on its own, attached to the payment, and is still there months later. No more photos of crumpled paper in the camera roll.

03The product, screen by screen
Playable mockup

My purchases

August 2026

AllUnder warrantyBusinessTo sort
DecathlonToday · card ••4264,90 €
Fnac12 Aug · 2-year warrantyWarranty329,00 €
Carrefour11 Aug · groceries87,12 €
Apple Store3 Aug · card ••42Warranty1 149,00 €
PurchasesWarrantySpendingProfile
01 / 04 · Wallet

Every purchase in one place, whoever the merchant is. Centralisation comes from the payment, not from one app per retailer.

Interactive mockup rebuilt for this portfolio. The values shown illustrate the interface — they are not production figures.

04The calls I made
01

Anchor on the payment, not the receipt

What every purchase shares isn't the merchant. It's the transaction. Anchoring on the payment makes centralisation automatic instead of depending on each retailer's goodwill.

02

Mobile first, properly

React Native to cover iOS and Android from one codebase without giving up the native feel. This is an app you open for thirty seconds, at the till or on the train.

03

A strict data foundation

Supabase with row-level security: each user can only ever see their own transactions, enforced by the database itself rather than by application code alone.

05The design board
// palette
#10B981
#0D9488
#0A0A0C
#F5F5F7
// type scale
AaDisplay · 600
AaHeading · 550
AaBody · 400
// visual calls
  • 01A trustworthy green rather than a banking blue: this app is about everyday purchases, not wealth management.
  • 02Amounts use tabular figures, right-aligned. A price column that dances is unreadable.
  • 03Every retailer gets a coloured chip derived from its name. Spotting a purchase should be instant, before you read anything.
  • 04The receipt is rebuilt typographically, never shown as a photo. It stays readable, selectable and translatable.
06Why this stack
React Native
One codebase for iOS and Android. Decisive on a product where mobile is the primary use.
Supabase
Managed PostgreSQL with auth and row-level security. Financial data demands that level of rigour.
Stripe
The reference for transaction reconciliation, with documentation that actually holds up.
TypeScript
In a financial domain, a type error is a money error. Strict typing isn't negotiable.
React NativeNext.jsSupabaseStripeTypeScript

Something similar in mind?

Describe your situation. I'll tell you what's realistic,
in what order, and what I'd do differently.

contact@amauryandrade.com