Jul 2022 - Jan 2023
Pay By Account
Mastercard's new payment method enabling customers to pay directly from their bank account at checkout.
Fintech
UX UI
Overview
Mastercard was launching Pay by Account - a new payment method enabling customers to pay directly from their bank account at checkout. To support the product's rollout, a suite of portals was needed: one for resellers (banks), one for merchants, and one for customers. These portals would serve as the operational backbone of the product - handling transaction overviews, dispute management, merchant onboarding and offboarding, and financial reporting.
My Role
I'm one of two UX/UI designers on the project, responsible for designing the reseller and merchant portals end to end.
Working alongside a design lead, I was responsible for understanding the distinct needs of each user type and translating them into flows, wireframes, and high-fidelity prototypes. I collaborated within a team of 10 that included business analysts, developers, and members of the Mastercard client team - managing stakeholder input at every stage from discovery through to prototype sign-off.
Problem
Pay by Account was a new product entering a competitive market. Launching it without a purpose-built admin portal wasn't an option - resellers and merchants needed a reliable, intuitive interface to manage their operations from day one.
The challenge was that the portal had to serve meaningfully different user types under one consistent system. Customers needed to review transactions and raise disputes. Merchants needed financial summaries to inform business decisions. Resellers - the banks distributing the product - had the most complex role of all: they were responsible for overseeing merchant accounts, onboarding and offboarding merchants, managing contacts, and reviewing financial performance across their portfolio.
Building for all three in parallel, within a fixed timeline and to MVP scope, required sharp prioritisation from the outset.
Goals
Create a seamless experience that users quickly understand and adopt.
Ship an MVP fast enough to stay competitive - include only what was essential for launch, defer everything else
Design clear, trustworthy navigation across all three portals - critical for a financial product where user confidence is non-negotiable
Enable resellers to carry out their full operational responsibilities: merchant onboarding, offboarding, profile management, and financial oversight
Give merchants actionable financial summaries to support day-to-day business decisions
Maintain a consistent experience across all three portals through a shared design system and interaction patterns
Outcomes
Comprehendible production ready designs
The high-fidelity Figma prototypes were well received by the Mastercard client team, and all design deadlines were met. Stakeholder testing showed users could navigate the portals and complete key tasks without friction. Completed flows included reviewing merchant accounts, onboarding and offboarding merchants, dispute management, and API key generation. The experience across all three portals was reviewed and confirmed as consistent.
The project was later scoped down or cancelled on the client side - a decision driven by factors beyond the design team's remit. The design work itself was signed off and production-ready.
Process
Process - Discover
I began with a round of stakeholder interviews - both internal team members and external stakeholders from the client side - to establish a clear picture of reseller needs, pain points, and operational responsibilities. This was particularly important for the merchant portal, where the workflows were complex and unfamiliar territory for the design team.
These interviews grounded every subsequent decision in real operational context rather than assumption.
Following a collaborative workshop to align on MVP scope, I mapped out the user flows and information architecture for both the reseller and merchant portals. This step was the backbone of the project - getting the structure right before touching a single screen meant the wireframing phase was efficient and purposeful, with each page's role clearly defined before design began.
Process - Develop
Stakeholder input reshaped the IA
After presenting the initial information architecture and early screens, two significant changes were made based on stakeholder feedback.
First, the Settlements feature - intended to help resellers track earnings per merchant - was pushed to a later phase. It was still conceptually underdeveloped, and including it in MVP would have added complexity without delivering reliable value.
Second, during testing, stakeholders didn't intuitively expect API key generation to live separately from the merchant profile. We relocated this action to sit within individual merchant pages, where users were already operating in that merchant's context.
Simplifying the onboarding flow
The original onboarding and offboarding flows required sign-off from three separate admins - a verification process that reflected a thorough internal model but proved too complex to build within the project's time constraints. Working closely with the backend developers, we reduced the verification to a single confirmation email. The resulting flow was faster to build, easier for resellers to action, and no less secure for MVP purposes.
Figure 1. Original onboarding flow that involved 3 admins to fully onboard a new merchant.
Figure 2. Original information architecture
Prototype testing with stakeholders validated the core flows. Users moved through merchant review, onboarding, offboarding, and API key generation without significant friction. No major structural issues were raised — the iterative changes made during the define phase had pre-empted most of the navigation and discoverability concerns before they reached testing.
Figure 3. The revised information architecture
Figure 4. The revised merchant onboard flow
Learnings
Financial products demand structural clarity above all else
When users are managing disputes, onboarding merchants, or reviewing financial summaries, ambiguity in navigation isn't a minor UX issue - it's a trust issue. Getting the information architecture right early was the single most important investment on this project.
MVP discipline is a design skill
With a complex, interlocking product and a fixed timeline, every feature decision had downstream consequences for development. Learning to advocate for deferral - as with Settlements - rather than trying to design everything at once, was a critical part of delivering something coherent and on time.
Backend constraints are design constraints
The simplification of the onboarding flow from a three-admin to a single-admin process wasn't a compromise - it was the right call given the build complexity. Involving developers early in flow reviews, rather than presenting finished designs for sign-off, saved significant rework.
Stakeholder testing surfaces IA problems that wireframe reviews don't
The API key placement issue only emerged when real users were navigating the prototype with a task in mind. It was a quick fix, but a reminder that even well-reasoned structural decisions need to be validated in context
Next Steps
The foundation is in place. Future phases of the portal should prioritise building out the Settlements feature for resellers, richer dispute tracking with full stage history and audit logs, and more granular analytics for merchants — moving the portal from an operational tool to a genuine business intelligence resource.
More works
Jul 2022 - Jan 2023
Pay By Account
Mastercard's new payment method enabling customers to pay directly from their bank account at checkout.
Fintech
UX UI
Overview
Mastercard was launching Pay by Account - a new payment method enabling customers to pay directly from their bank account at checkout. To support the product's rollout, a suite of portals was needed: one for resellers (banks), one for merchants, and one for customers. These portals would serve as the operational backbone of the product - handling transaction overviews, dispute management, merchant onboarding and offboarding, and financial reporting.
My Role
I'm one of two UX/UI designers on the project, responsible for designing the reseller and merchant portals end to end.
Working alongside a design lead, I was responsible for understanding the distinct needs of each user type and translating them into flows, wireframes, and high-fidelity prototypes. I collaborated within a team of 10 that included business analysts, developers, and members of the Mastercard client team - managing stakeholder input at every stage from discovery through to prototype sign-off.
Problem
Pay by Account was a new product entering a competitive market. Launching it without a purpose-built admin portal wasn't an option - resellers and merchants needed a reliable, intuitive interface to manage their operations from day one.
The challenge was that the portal had to serve meaningfully different user types under one consistent system. Customers needed to review transactions and raise disputes. Merchants needed financial summaries to inform business decisions. Resellers - the banks distributing the product - had the most complex role of all: they were responsible for overseeing merchant accounts, onboarding and offboarding merchants, managing contacts, and reviewing financial performance across their portfolio.
Building for all three in parallel, within a fixed timeline and to MVP scope, required sharp prioritisation from the outset.
Goals
Create a seamless experience that users quickly understand and adopt.
Ship an MVP fast enough to stay competitive - include only what was essential for launch, defer everything else
Design clear, trustworthy navigation across all three portals - critical for a financial product where user confidence is non-negotiable
Enable resellers to carry out their full operational responsibilities: merchant onboarding, offboarding, profile management, and financial oversight
Give merchants actionable financial summaries to support day-to-day business decisions
Maintain a consistent experience across all three portals through a shared design system and interaction patterns
Outcomes
Comprehendible production ready designs
The high-fidelity Figma prototypes were well received by the Mastercard client team, and all design deadlines were met. Stakeholder testing showed users could navigate the portals and complete key tasks without friction. Completed flows included reviewing merchant accounts, onboarding and offboarding merchants, dispute management, and API key generation. The experience across all three portals was reviewed and confirmed as consistent.
The project was later scoped down or cancelled on the client side - a decision driven by factors beyond the design team's remit. The design work itself was signed off and production-ready.
Process
Process - Discover
I began with a round of stakeholder interviews - both internal team members and external stakeholders from the client side - to establish a clear picture of reseller needs, pain points, and operational responsibilities. This was particularly important for the merchant portal, where the workflows were complex and unfamiliar territory for the design team.
These interviews grounded every subsequent decision in real operational context rather than assumption.
Following a collaborative workshop to align on MVP scope, I mapped out the user flows and information architecture for both the reseller and merchant portals. This step was the backbone of the project - getting the structure right before touching a single screen meant the wireframing phase was efficient and purposeful, with each page's role clearly defined before design began.
Process - Develop
Stakeholder input reshaped the IA
After presenting the initial information architecture and early screens, two significant changes were made based on stakeholder feedback.
First, the Settlements feature - intended to help resellers track earnings per merchant - was pushed to a later phase. It was still conceptually underdeveloped, and including it in MVP would have added complexity without delivering reliable value.
Second, during testing, stakeholders didn't intuitively expect API key generation to live separately from the merchant profile. We relocated this action to sit within individual merchant pages, where users were already operating in that merchant's context.
Simplifying the onboarding flow
The original onboarding and offboarding flows required sign-off from three separate admins - a verification process that reflected a thorough internal model but proved too complex to build within the project's time constraints. Working closely with the backend developers, we reduced the verification to a single confirmation email. The resulting flow was faster to build, easier for resellers to action, and no less secure for MVP purposes.
Figure 1. Original onboarding flow that involved 3 admins to fully onboard a new merchant.
Figure 2. Original information architecture
Prototype testing with stakeholders validated the core flows. Users moved through merchant review, onboarding, offboarding, and API key generation without significant friction. No major structural issues were raised — the iterative changes made during the define phase had pre-empted most of the navigation and discoverability concerns before they reached testing.
Figure 3. The revised information architecture
Figure 4. The revised merchant onboard flow
Learnings
Financial products demand structural clarity above all else
When users are managing disputes, onboarding merchants, or reviewing financial summaries, ambiguity in navigation isn't a minor UX issue - it's a trust issue. Getting the information architecture right early was the single most important investment on this project.
MVP discipline is a design skill
With a complex, interlocking product and a fixed timeline, every feature decision had downstream consequences for development. Learning to advocate for deferral - as with Settlements - rather than trying to design everything at once, was a critical part of delivering something coherent and on time.
Backend constraints are design constraints
The simplification of the onboarding flow from a three-admin to a single-admin process wasn't a compromise - it was the right call given the build complexity. Involving developers early in flow reviews, rather than presenting finished designs for sign-off, saved significant rework.
Stakeholder testing surfaces IA problems that wireframe reviews don't
The API key placement issue only emerged when real users were navigating the prototype with a task in mind. It was a quick fix, but a reminder that even well-reasoned structural decisions need to be validated in context
Next Steps
The foundation is in place. Future phases of the portal should prioritise building out the Settlements feature for resellers, richer dispute tracking with full stage history and audit logs, and more granular analytics for merchants — moving the portal from an operational tool to a genuine business intelligence resource.
More works
Jul 2022 - Jan 2023
Pay By Account
Mastercard's new payment method enabling customers to pay directly from their bank account at checkout.
Fintech
UX UI
Overview
Mastercard was launching Pay by Account - a new payment method enabling customers to pay directly from their bank account at checkout. To support the product's rollout, a suite of portals was needed: one for resellers (banks), one for merchants, and one for customers. These portals would serve as the operational backbone of the product - handling transaction overviews, dispute management, merchant onboarding and offboarding, and financial reporting.
My Role
I'm one of two UX/UI designers on the project, responsible for designing the reseller and merchant portals end to end.
Working alongside a design lead, I was responsible for understanding the distinct needs of each user type and translating them into flows, wireframes, and high-fidelity prototypes. I collaborated within a team of 10 that included business analysts, developers, and members of the Mastercard client team - managing stakeholder input at every stage from discovery through to prototype sign-off.
Problem
Pay by Account was a new product entering a competitive market. Launching it without a purpose-built admin portal wasn't an option - resellers and merchants needed a reliable, intuitive interface to manage their operations from day one.
The challenge was that the portal had to serve meaningfully different user types under one consistent system. Customers needed to review transactions and raise disputes. Merchants needed financial summaries to inform business decisions. Resellers - the banks distributing the product - had the most complex role of all: they were responsible for overseeing merchant accounts, onboarding and offboarding merchants, managing contacts, and reviewing financial performance across their portfolio.
Building for all three in parallel, within a fixed timeline and to MVP scope, required sharp prioritisation from the outset.
Goals
Create a seamless experience that users quickly understand and adopt.
Ship an MVP fast enough to stay competitive - include only what was essential for launch, defer everything else
Design clear, trustworthy navigation across all three portals - critical for a financial product where user confidence is non-negotiable
Enable resellers to carry out their full operational responsibilities: merchant onboarding, offboarding, profile management, and financial oversight
Give merchants actionable financial summaries to support day-to-day business decisions
Maintain a consistent experience across all three portals through a shared design system and interaction patterns
Outcomes
Comprehendible production ready designs
The high-fidelity Figma prototypes were well received by the Mastercard client team, and all design deadlines were met. Stakeholder testing showed users could navigate the portals and complete key tasks without friction. Completed flows included reviewing merchant accounts, onboarding and offboarding merchants, dispute management, and API key generation. The experience across all three portals was reviewed and confirmed as consistent.
The project was later scoped down or cancelled on the client side - a decision driven by factors beyond the design team's remit. The design work itself was signed off and production-ready.
Process
Process - Discover
I began with a round of stakeholder interviews - both internal team members and external stakeholders from the client side - to establish a clear picture of reseller needs, pain points, and operational responsibilities. This was particularly important for the merchant portal, where the workflows were complex and unfamiliar territory for the design team.
These interviews grounded every subsequent decision in real operational context rather than assumption.
Following a collaborative workshop to align on MVP scope, I mapped out the user flows and information architecture for both the reseller and merchant portals. This step was the backbone of the project - getting the structure right before touching a single screen meant the wireframing phase was efficient and purposeful, with each page's role clearly defined before design began.
Process - Develop
Stakeholder input reshaped the IA
After presenting the initial information architecture and early screens, two significant changes were made based on stakeholder feedback.
First, the Settlements feature - intended to help resellers track earnings per merchant - was pushed to a later phase. It was still conceptually underdeveloped, and including it in MVP would have added complexity without delivering reliable value.
Second, during testing, stakeholders didn't intuitively expect API key generation to live separately from the merchant profile. We relocated this action to sit within individual merchant pages, where users were already operating in that merchant's context.
Simplifying the onboarding flow
The original onboarding and offboarding flows required sign-off from three separate admins - a verification process that reflected a thorough internal model but proved too complex to build within the project's time constraints. Working closely with the backend developers, we reduced the verification to a single confirmation email. The resulting flow was faster to build, easier for resellers to action, and no less secure for MVP purposes.
Figure 1. Original onboarding flow that involved 3 admins to fully onboard a new merchant.
Figure 2. Original information architecture
Prototype testing with stakeholders validated the core flows. Users moved through merchant review, onboarding, offboarding, and API key generation without significant friction. No major structural issues were raised — the iterative changes made during the define phase had pre-empted most of the navigation and discoverability concerns before they reached testing.
Figure 3. The revised information architecture
Figure 4. The revised merchant onboard flow
Learnings
Financial products demand structural clarity above all else
When users are managing disputes, onboarding merchants, or reviewing financial summaries, ambiguity in navigation isn't a minor UX issue - it's a trust issue. Getting the information architecture right early was the single most important investment on this project.
MVP discipline is a design skill
With a complex, interlocking product and a fixed timeline, every feature decision had downstream consequences for development. Learning to advocate for deferral - as with Settlements - rather than trying to design everything at once, was a critical part of delivering something coherent and on time.
Backend constraints are design constraints
The simplification of the onboarding flow from a three-admin to a single-admin process wasn't a compromise - it was the right call given the build complexity. Involving developers early in flow reviews, rather than presenting finished designs for sign-off, saved significant rework.
Stakeholder testing surfaces IA problems that wireframe reviews don't
The API key placement issue only emerged when real users were navigating the prototype with a task in mind. It was a quick fix, but a reminder that even well-reasoned structural decisions need to be validated in context
Next Steps
The foundation is in place. Future phases of the portal should prioritise building out the Settlements feature for resellers, richer dispute tracking with full stage history and audit logs, and more granular analytics for merchants — moving the portal from an operational tool to a genuine business intelligence resource.
More works