The fragmentation
Same ecosystem. Different receipt logic.
As Mercado Pago expanded, receipts evolved independently across products — with different structures, hierarchies and ways of presenting essentially the same kinds of information.
The problem wasn't visual inconsistency. There was no shared model defining what a Mercado Pago receipt should contain or how that information should be prioritized.
Mapping the ecosystem
70+ transaction states.
5+ product squads.
I led a cross-product audit to understand how receipts were being used across the ecosystem.
More than 70 transaction states were consolidated into a single source of truth, exposing repeated patterns, structural differences and the decisions each product had been making independently.
The framework also needed to work across Latam markets while accommodating local and regulatory requirements.
The system didn't need one universal receipt. It needed a shared logic for deciding what mattered.
From audit to a decision model
What needs to matter most when the receipt becomes evidence?
Receipts serve different purposes depending on the transaction. Sometimes users need to prove who received the money. In others, they need evidence of who initiated the transaction.
That distinction became the rule behind two information architectures.
What is the most relevant information in this transaction?
Who or what company received the money.
e.g. service payments
Who initiated the transaction.
e.g. transfers
The framework
Three layers, one system.
Two information architectures, a shared structure with contextual rules, and a modular component system.
Layer 01
The same information. A different hierarchy.
Once the primary need was defined, the receipt hierarchy followed.
Destination-first receipts bring who received the money forward. Origin-first receipts prioritize who initiated the transaction.
The result wasn’t a different receipt for every product, but two shared architectures that could cover different transaction needs.
Layer 02
Every module had to answer a question.
Each architecture combines a fixed core with contextual modules. What changes isn’t arbitrary: each optional module is activated by a specific information need.
Instead of leaving those decisions to each product team, the framework defined when additional information should appear.
If the information didn’t help users understand, identify or resolve the transaction, it didn’t belong in the receipt.
Layer 03
Built to grow by composition, not replication.
In partnership with Content, I turned the structure into a reusable component system — navigation, title, date, amount, origin, destination and operation data — plus optional modules for transaction-specific and regulatory needs.
New receipts could be assembled by combining existing components instead of redesigning each one from scratch.
Less design effort. Less IT effort. Fewer places for the system to drift.
Getting teams to adopt it
Designing the system was only half the problem.
Squads agreed with the direction, but adoption meant changing existing implementations while IT teams were already balancing competing priorities.
I turned the framework into a Figma toolkit and integration workflow, defining what stayed standardized, what integrating teams could adapt, and clear ownership from experience definition through QA and production.
The goal was to make adoption feel less like rebuilding and more like assembling from an existing system.
Impact
From fragmented receipts to a shared system.
The framework replaced independently designed receipts with a shared model for deciding, building and maintaining transaction evidence across products.
What had been fragmented across teams became reusable infrastructure for the Mercado Pago experience.
Trust became part of the infrastructure.