Mobile
Pay Credit Card via Open Banking
Role: UX Manager (Lead Designer)
Team: Product Manager, Engineering Lead, Compliance, Legal, Copywriting
Platform: iOS & Android (Native)
Project Overview
As UX Manager on the Santander mobile app team (OneApp), I led the design of a new feature that allows customers to pay their credit card using external third-party bank accounts, leveraging Open Banking technology. I was responsible for the end-to-end design strategy, collaborating with product, engineering, legal, and compliance teams to deliver a seamless and compliant user experience.
The Challenge
Business Problem
Santander faced three critical challenges:
No in-app payment option for credit card-only customers - Using the mobile app is the primary way for customers to interact with their accounts, yet those with only a credit card had no way to make payments within the app, forcing them to use external methods or call customer service.
Significant cost burden - Payments made via debit cards were costing the bank approximately £1M annually in processing fees. Introducing Open Banking payments presented an opportunity to convert these costs into substantial savings.
Competitive disadvantage - Santander was lagging behind competitors in feature parity, particularly affecting our ability to attract and retain younger customers who gravitate towards banks with more innovative payment methods.
User Problem
Credit card-only customers were unable to manage their finances effectively within the app, creating friction in their banking experience and reducing engagement with our digital channels.
Research & Discovery
Identifying the Opportunity
I initiated and facilitated a cross-functional workshop with the product team to identify high-value opportunities for Open Banking integration across the app. Pay via Open Banking emerged as one of the highest-impact features, addressing both user needs and business objectives.
Competitive Analysis
I conducted comprehensive competitor analysis to understand the existing landscape and establish best practices. Key findings included:
Native implementation standard: Competitors kept users within their own app environments throughout the payment journey, maintaining a consistent in-app experience
External redirect for bank authorisation: The only external navigation happened when users needed to authenticate with their external bank (the third-party Open Banking provider)
Inconsistent terminology: No market standard existed for naming Open Banking features, though most referenced variants of "Easy Pay with a Bank"
Security messaging: Most journeys emphasised how Open Banking works and highlighted security measures, suggesting user concern in this area
Key Insights
These findings established a baseline for our approach and confirmed that maintaining a native experience was the industry standard. This insight proved crucial when the web view approach was initially proposed. I could reference competitor implementations to demonstrate that a native solution was not only feasible but expected in the market.
Design Process
Initial Journey Mapping
I began by mapping the end-to-end user journey, leveraging our existing design system components to rapidly create high-fidelity prototypes. This involved:
Deep-diving into technical documentation from our third-party Open Banking provider
Collaborating with the copywriting team to ensure alignment with our new tone of voice
Regular sync meetings with engineering to surface technical constraints early
Partnering with legal and compliance to secure necessary approvals at each stage
Critical Design Decision: Native vs. Web View
A pivotal moment in the project came when stakeholders initially decided to implement the journey using a white-label web view provided by our third-party partner. The rationale was clear: lower development costs and faster time-to-market to meet an aggressive deadline.
However, I had significant concerns with this approach:
Premature exit from app environment - Users would be navigated out of the app early in the journey, potentially increasing anxiety around security for this new payment method
Fraud risk precedent - Executing payments outside the Santander app could normalize external payment flows, potentially increasing vulnerability to fraud
Session timeout issues - Short security timeouts in the native app created risk of locking out customers mid-payment
Limited future integration - A web view approach would constrain our ability to tightly integrate other planned Open Banking features on the roadmap
Advocating for Change
Rather than accepting this decision, I took a strategic approach to challenge it:
Built evidence base - Designed and conducted user testing specifically to validate my concerns
Quantified risks - Documented potential impact on conversion rates, fraud, and customer trust
Presented business case - Demonstrated how native implementation would enable future features and reduce long-term technical debt
Stakeholder alignment - Presented findings to cross-functional leadership, securing buy-in for the native approach
The user testing confirmed security concerns and drop-off risks with external redirects. Armed with this data, I successfully influenced stakeholders to pivot to a fully native implementation.
Balancing Convenience and Trust
User research revealed a delicate balance: customers wanted convenience and speed, but also needed reassurance about the safety of this new payment method. I addressed this through:
Progressive disclosure - Providing security information at key decision points without overwhelming the initial flow
Clear mental models - Using familiar patterns from existing payment journeys while introducing new Open Banking elements
Trust indicators - Strategic placement of security messaging and regulatory logos (FCA authorisation)
Streamlined authentication - Minimising friction while maintaining robust security standards
Copy as a Security Tool
I leveraged microcopy strategically to build trust throughout the journey:
Descriptive CTAs - Button labels clearly communicated what users were agreeing to at each step
Setting expectations - Each screen prepared users for what would happen next, reducing anxiety about the unfamiliar process
Plain language explanations - Translated complex Open Banking regulations into clear, user-friendly language in collaboration with the copywriting team
This approach ensured users felt informed and in control, even as they navigated a new payment method for the first time.
The Solution
Final Design Approach
The final solution delivered a fully native experience that kept users within the Santander app environment throughout the entire payment journey:
Key Features:
Seamless account linking from multiple UK banks
One-time setup with saved bank accounts for future payments
Real-time payment confirmation
Clear, transparent communication about each step
Consistent visual language with existing Santander patterns
Design Principles Established:
Security through familiarity - Maintain Santander's trusted interface while introducing new functionality
Progressive transparency - Reveal complexity only when necessary
Reduced cognitive load - Minimise steps and decisions while maintaining control
Future-proof flexibility - Design patterns scalable for other Open Banking features
Information Architecture
The journey was structured in three main phases:
Setup & Selection - Choose payment amount and link external bank account
Authorisation - Authenticate with external bank (via secure API)
Confirmation - Real-time payment status and receipt
Impact & Outcomes
Scaling Design Patterns Across Teams
A significant outcome emerged during the design process: while liaising with the Financial Crime team and other departments, I discovered multiple teams were independently working on features that could leverage Open Banking.
Recognising this fragmentation risk, I took initiative to:
Share research findings and design patterns across teams
Facilitate alignment on common Open Banking patterns
Establish a shared approach to ensure consistency across the app
This cross-team collaboration prevented duplicated effort and created a unified Open Banking experience for customers across different features.
Launch & Performance
The feature launched in a phased rollout:
Phase 1: Android customers
Phase 2: iOS customers onboarded
Key Results:
Payment inflows: £[XX] processed through Open Banking, significantly exceeding initial projections
Cost savings: [XX]
Adoption rate: [X% of eligible customers activated Open Banking payments]
Post-Launch Optimisation
Following launch, I continued to refine the experience:
Iterated on copy based on customer feedback and support queries
Addressed edge case scenarios that emerged in production
Documented learnings and patterns for future implementation
Explored the architecture of our payment features to work towards simplifying how these are presented to users
Foundation for Future Features
This project established the blueprint for subsequent Open Banking initiatives, including my next project: funding Current Accounts and Savings accounts via Open Banking. The patterns, research, and technical foundation created here accelerated delivery of future features across the platform.
Key Learnings & Reflections
What Worked Well
Challenging assumptions early - My decision to question the web view approach, backed by research, prevented a suboptimal solution from going to market. This reinforced the importance of designers advocating for user needs even when facing business pressure.
Cross-functional collaboration - Building strong relationships with legal, compliance, and engineering early in the process meant fewer surprises and faster approvals later.
Strategic research application - Using user testing not just for design validation but as evidence for strategic decisions proved crucial in influencing stakeholder direction.
What I'd Do Differently
Earlier engineering involvement - While we had regular syncs, involving developers in the initial workshop phase would have surfaced technical constraints even sooner.
Pilot program consideration - A phased rollout with a smaller user segment could have provided real-world data to optimise the experience before full launch.
More comprehensive metrics framework - Establishing clearer success metrics at the project outset would have made impact measurement more robust.
Broader Implications
This project taught me that effective UX leadership isn't just about creating great designs—it's about building conviction in your team and stakeholders through evidence, articulating the long-term implications of technical decisions, and having the courage to push back on short-term thinking when user experience and business goals are at stake.
The native vs. web view decision became a case study within Santander for how thoughtful design advocacy can drive better technical architecture and business outcomes.
Skills Demonstrated
Strategic UX leadership and stakeholder influence
End-to-end journey design for complex financial products
Regulatory and compliance navigation (FCA, Open Banking standards)
User research and usability testing
Cross-functional collaboration (Product, Engineering, Legal, Compliance, Financial Crime)
Design systems application and pattern establishment
Technical documentation interpretation
Business case development and presentation
Cross-team design systems evangelism
Tools Used
Figma - Design and prototyping
UserZoom - User research and testing
JIRA/Confluence - Project management and documentation