01Introduction

One receipt template for all transactions

Receipts are the last screen of every transaction in Tonik. I designed one receipt template for all six transaction types, used both right after a transaction and on the history page. I was the only designer, working with a UX writer and a PM. The head of design reviewed my work.

Payments
UX design
Information hierarchy

The new receipt in the Tonik app, "Money sent!", with the amount on top and the reference, recipient, sender, and channel with fee below

The problem

Tonik has six ways to send or pay money. They had 3 different endings, and the history page showed different details again. For a banking app, a receipt is proof of payment. Users send it to friends, merchants, and billers. If it looks different every time, it is harder to trust.

What users saw right after paying

Same action, 3 different endings.

Three old screens. QR InstaPay/Tonik: a 'Transaction Summary' receipt right away. InstaPay, etc.: a 'Working on it, luv' illustration first. Paybills: a 'Sit tight, luv!' illustration only, with no receipt.

Only the QR flows showed the receipt right away. They were added last, so they had the newest layout.
InstaPay, PESONet, and Tonik to Tonik showed an illustration first. The receipt was one more tap away.
Paybills showed a processing screen and nothing else. Users had no receipt to share.

The same transfer, two different screens

Users have two ways to see the transaction details: the receipt right after the transaction, and the transaction summary on the history page. But they show two different sets of information.

The old InstaPay receipt, 'Transaction details', with five rows: amount, fee, to, when, and reference number.

The old InstaPay history page, 'Transaction Summary', with eight rows in a receipt-style card, including bank, transfer channel, and status.

Differences between “Receipt, right after transaction” and “Transaction details in history”
What differs	Receipt, right after transaction		Transaction details in history
Title	“Transaction details”	vs	“Transaction Summary”
Rows	5 rows	vs	8 rows
Only on this screen	Fee	vs	Bank, channel, status
Layout	Plain card	vs	Receipt-style card

Neither screen had everything.

Why it happened

The design was not intended. Tonik added payment channels one at a time over the years, and each one kept the layout it launched with.

How the receipts grew apart

Channels added since 2020

InstaPay, PESONet, Tonik to Tonik (2020)Illustrated screen, then the receiptReceipt is one step away
Paybills (2021)Processing screen onlyNo receipt to share
QR InstaPay, QR Tonik to Tonik (2024)Newest layout, but built on the history pageReceipt and history do not match

3 different endings

QR was added last, so it had the most modern layout.

The team later saw that users need to see the receipt right away. But there was no time to update the older flows, so the differences stayed and became tech debt.

Changing the scope

The PM started this project to make the QR receipt and the QR history page consistent. I pushed for more. Fixing only QR would give us a seventh version.

So I proposed one receipt template for every transaction type.

Screens in scope

Screens in scope
	Right after transaction	History page
QR InstaPay	New templateUnchanged	New templateUnchanged
QR Tonik to Tonik	New templateUnchanged	New templateUnchanged
InstaPay	New templateUnchanged	New templateUnchanged
PESONet	New templateUnchanged	New templateUnchanged
Tonik to Tonik	New templateUnchanged	New templateUnchanged
Paybills	New templateUnchanged	New templateUnchanged

One template fixes the old tech debt, and new payment channels can use it later.

Mapping the information

I listed every field that each transaction type showed. Then I ranked them by what users need first:

Status
Did it work?
Amount
How much?
Reference number
What do I need if something goes wrong?
Recipient
Who received it?
Sender
Which account did it come from?
Channel and fee
How was it sent, and did it cost anything?

Then I grouped the fields into four blocks, so every receipt has the same shape even when the details change.

I owned the structure and hierarchy. The UX writer wrote the labels.

The template

Every receipt uses the same four blocks in the same order: reference, recipient, sender, and channel with fee.

The final receipt

The new receipt with notes: status and amount come first, masked name following BSP’s rule, copy the reference number in one tap, channel and fee in one block, share or save as proof of payment.

The amount is the biggest element, so users can check it at a glance.
The reference number has a copy button. Users paste it in chats and support tickets.
Names and account numbers are masked, following a new privacy rule from BSP.
Share and Save sit right below the receipt, because users send it as proof of payment.

All cases, one template

The layout stays the same. Only the status and the transaction details change. Users also see the same receipt on the history page.

Four receipts with the same layout. QR InstaPay, where the project started. Tonik to Tonik and other real time transfers. PESONet processing, which shows first for slow transfers. PESONet money sent: same receipt, status updated.

QR InstaPay, where the project started, looks the same as every other transaction type.
Tonik to Tonik (and QR Tonik to Tonik) and InstaPay transfers adhere to a consistent design template.
Slow transfers like PESONet and Paybills show “Processing” first.
The status changes to “Money sent!” when the transfer is complete.

What I learned

What the design did well

One template covers all six transaction types.
The history page uses the same layout, so users see the same details after paying and later.
New payment channels can use the template without a new design.

What I would do next

I’d measure:

Compare related support tickets from before and after the redesign
Do more users share or save their receipts?

Next time:

I will push for a scalable pattern early, before the differences become expensive to fix.