PIX — Payment Flows

PIX launched in Brazil in November 2020 and became mandatory for regulated financial institutions almost immediately. For Banco Inter — one of the country's largest digital banks with millions of active users — implementing PIX wasn't just a feature request. It was a regulatory obligation with a hard deadline, a trust problem (users needed to feel safe moving money instantly), and a design challenge at scale.

The payment experience covered multiple distinct use cases that each required their own flow logic:

• QR code scanning: static QR codes with fixed values, and dynamic QR codes with expiration dates, interest rates, and late fees
• PIX copy-paste: users copying a PIX key from another app and pasting it into Inter
• High-value transfers (PF): individual accounts with limit verification, biometric authentication, and scheduled date selection
• High-value transfers (PJ with approval): business accounts where large transfers required a second-party approval workflow, constrained by business hours

The complexity wasn't just technical. It was about trust. PIX was instant and irreversible — users had zero tolerance for ambiguous confirmation flows or unclear error states.

"How do we design for irreversibility at scale, across use cases that range from 'scan and pay' to 'get your CFO to approve this transfer by end of day'?"

Working inside a team of 50+ designers at Banco Inter meant that briefing was a structured, multi-layer process — very different from the lean discovery I was used to. My involvement started after product and compliance had already scoped the feature at a high level. I received a briefing document with functional requirements and regulatory constraints from the Central Bank of Brazil, then participated in alignment sessions with product, engineering, and legal before any design work began.

The key design requirements from the briefing:

• QR flows: support all QR types defined by BACEN (static and dynamic), with dynamic QR supporting expiration, interest, and fines — all displayed clearly in the review screen
• Error handling for QR scanning: camera permission denied, expired QR, invalid QR, unreadable QR — each required a distinct state, not a generic error
• Pix copia e cola: the copy-paste key flow had to handle validation server-side and surface the result clearly, since the user couldn't see a QR code to trust
• High-value PF flow: biometric authentication required above a defined threshold, with limit display and a scheduled date option for transfers exceeding the daily limit
• High-value PJ flow: approval workflow required — the transfer initiator requests, an authorized approver (a second person in the company) approves or denies during business hours; out-of-hours requests had to be queued, not rejected

Design constraints were tight: Inter's design system needed to be followed precisely, screen density had to account for a wide range of device sizes, and the flows had to be production-ready in a compressed timeline because of the regulatory deadline.

With the scope defined and constraints clear, the exploration phase was faster and more focused than in a greenfield product. The regulatory framework from BACEN pre-defined much of the information hierarchy — the review screen content for dynamic QR codes, for example, was specified in regulation. What wasn't pre-defined was how to present it.

The key design questions I explored:

• For QR flows: how do you communicate the difference between static and dynamic QR to a user who doesn't know or care about the distinction? The answer was: you don't. The review screen adapts to show only the fields relevant to the QR type — expiration and late fee appear only when the QR contains them.
• For Bottomsheet usage: when and how to use the Bottomsheet pattern for confirmation and review steps without making the experience feel fragmented or modal-heavy.
• For error states in QR scanning: a camera-denied error looks very different from an expired QR — one is a permission problem the user can fix immediately, the other requires them to contact the payee. The error hierarchy needed to be visual AND instructional.
• For the PJ approval flow: how do you make a multi-party, asynchronous approval feel coherent inside a mobile experience? The initiator sends the request, then waits. The approver receives a notification. Both parties needed clear visibility into the status.
• For business hours constraint: what does the system do with a PJ transfer request that arrives outside business hours? Blocking it felt wrong; queuing it with a clear "your request will be reviewed when business opens" message was the answer.

Given the compressed deadline and team size, lo-fi testing at Banco Inter happened in a more structured way than at smaller companies. Test plans were submitted and approved, sessions were coordinated with the research team, and findings were documented in a shared repository for cross-team visibility.

I participated in testing focused on the QR code flows and the PJ approval workflow, which were the highest-risk scenarios in terms of user error and trust.

QR code testing findings:

• Users who scanned an expired QR expected the camera to show a visual indicator of the problem — they didn't look at the bottom of the screen where the error message appeared. The error needed to be surfaced in the camera viewport itself, or the camera needed to deactivate with a clear modal interruption.
• The dynamic QR review screen caused hesitation: users were uncertain whether "juros" (interest) and "multa" (late fee) were being charged to them now or were just informational fields. A label change from "juros" to "juros por atraso" (interest for late payment) significantly reduced this confusion.
• Pix copia e cola: users frequently pasted the key and immediately tapped "continuar" without reading the review screen. The payee name and institution needed to be visually prominent — not just listed in a form row.

PJ approval flow testing findings:

• The transfer initiator didn't understand that their request was pending until they navigated away and came back. A persistent "aguardando aprovação" (awaiting approval) state on the home screen was added as a result.
• The business hours constraint was misunderstood: users thought transfers during non-business hours were being rejected, not queued. The copy needed to be explicit: "sua solicitação será enviada ao aprovador no próximo dia útil" (your request will be sent to the approver on the next business day).
• Approvers receiving the notification expected more detail in the push notification itself — an amount and payee name — so they could decide whether to open the app immediately.

With test findings in hand, I revised the flows across both sections before the final design pass.

QR code flow changes

Error states redesigned — Expired and invalid QR errors were upgraded from bottom-screen messages to full-state screens with a clear action (go back and try again / contact payee). Camera-denied error retained a different treatment — a bottom sheet that deep-linked directly to device permissions, since the resolution was local.

Dynamic QR review screen relabeled — "Juros" became "Juros por atraso", "Multa" became "Multa por atraso". All fields that only appeared in dynamic QR were marked as conditionally displayed in the spec.

Revisão QR com valor definido — A distinct review screen variation for QRs where the value was pre-set by the payee (not editable by the payer). The edit value affordance was hidden for these QRs, and the lock state was made explicit with a visual indicator.

Editar valor flow — Added as a separate sub-flow for static QR codes without a fixed value: the user could modify the amount before confirmation, with a persistent review step after editing.

Bottomsheet component — Confirmed as the right pattern for mid-flow confirmations (not full-page interruptions). Applied consistently across QR and copy-paste flows.

High-value flow changes

PF biometric step refined — The biometric authentication screen was repositioned in the flow to occur after the review step (not before), so users could see what they were authenticating before being asked to confirm biometrically.

PF date selection — The scheduled date picker was scoped to cases where the daily limit would be exceeded; it didn't appear otherwise. Clear feedback when the selected date was outside allowed range.

PJ approval — queued state — The "out of business hours" scenario was redesigned from a blocking error to a queued state with an estimated send time. The initiator's home screen showed a persistent pending transfer card.

PJ approval — approver experience — The approver's screen (the "aprovação" step) showed the full transfer detail, the initiator's name, and two clear actions: approve (green) and reject (red), with a required reason field on rejection.

Final hi-fi covered both sections in full, following Inter's design system tokens and component library across iOS and Android.

QR Code & PIX Copia e Cola

Main flows:

• Revisão padrão - QR estático: standard review for a static QR with amount, payee, and institution. Editable amount when QR type allows.
• QR dinâmico com vencimento: review screen adding expiration date, interest rate, and late fee fields. Fields conditionally visible based on QR content.
• QR dinâmico com vencimento - juros e multas: full dynamic QR with all conditional fields active.
• Revisão QR com valor definido: non-editable review for pre-set-value QR codes.
• Revisão QR com valor definido - mensagem: variant including an optional message field.
• Editar valor: sub-flow for amount editing before confirmation.
• Bottomsheet: confirmation and sub-action patterns used across QR and copy-paste flows.
• PIX copia e cola: full flow from paste to review to confirmation.

Error states (cenários de erro na leitura):

• Camera permission denied (with deep-link to device settings)
• Expired QR (full-state error screen)
• Invalid / unreadable QR (full-state error screen)
• Network error mid-flow

High-Value PIX

PF flow:

• Limit verification screen (showing used vs. available PIX limit)
• Biometric authentication step (post-review)
• Scheduled date selection (conditional on limit exceeded)
• Confirmation with date and amount

PJ with approval flow:

• Valor a pagar / Definir valor: value input and payee selection (list-based, from company contact list)
• Revisão: full transfer review screen for PJ context (CNPJ fields, company names)
• Horário comercial: out-of-business-hours queued state with expected send time
• Aprovação: approver-side screen with full transfer detail, approve/reject actions, and rejection reason field

At Banco Inter, handoff was a team-level process. Finished flows went into a shared handoff section of the design file, annotated and linked to a specs document. I presented my flows in a dedicated handoff session with the frontend engineering squad assigned to PIX, and a second session with the QA team.

Design QA at Inter happened in a dedicated QA round — not just my own review. A QA analyst tested the implementation against the design spec and filed a formal report. I reviewed the findings with the product manager and prioritized fixes before the release candidate was signed off.

Key issues found in QA:

• Dynamic QR review screen: conditional fields appearing even when QR contained no interest/fee data — filtering logic not implemented correctly
• PJ approval: the approver notification deep-link opened the app home instead of the pending approval screen
• PJ out-of-hours: the queued state timer showed UTC time instead of local time (Brasília)
• QR error states: the camera-denied state triggered on first open before the OS permission dialog had appeared, creating a false error

All issues were resolved before the PIX launch.

I designed these flows as a pleno UX designer. Looking back now, as a senior, there are specific things I would do differently — not because the output was wrong, but because of how I worked and what I prioritized.

What I'd change in the process:

At the time, I accepted the briefing document as the source of truth and moved into design execution quickly. Today I'd push back earlier on assumptions embedded in the brief — specifically around the PJ approval flow. The business hours constraint was a product decision that came from compliance, but it created a poor user experience (queuing requests silently). As a senior, I'd raise that earlier and propose alternatives: async push notification approval that works outside business hours, or a different time-window definition. The constraint may have been real, but design should be advocating for users at the brief stage, not just executing around constraints.

What I'd change in the testing approach:

Lo-fi testing was done on a schedule defined by the research team, not by the risk level of individual flows. Today I'd argue for front-loading testing on the highest-trust moments: the review screens (where irreversible decisions happen) and the error states (where users lose confidence in the product). Instead, we tested the flows in their entirety, which diluted the focus.

What I'd change in cross-team alignment:

Working in a 50-person design team meant there were dependencies I didn't always surface proactively. The PIX flows touched the design system team (component behavior), the notifications team (approver push notification content), and the home screen team (pending transfer card). I flagged these as handoff items rather than tracking them as design dependencies. Today I'd treat cross-team touchpoints as first-class items in the flow — not footnotes.

What held up well:

The error state hierarchy for QR flows aged well. The decision to make camera-denied, expired, and invalid QR into distinct states (rather than a generic error) was the right call, and it was validated in testing. That instinct to treat error scenarios as first-class design objects — not edge cases to polish later — is something I carried forward into every project since.