Skip to main content
Selected Work

Fintech · A2A Payments · B2B SaaS · Merchant Experience · Payment Infrastructure

Kurense Merchant Solutions

Designing a modern account-to-account payment experience

Kurense Merchant Solutions explores how merchants could accept real-time account-to-account payments through a connected experience spanning Pay by Bank, Plaid-powered account connectivity, RTP and FedNow, and a centralized merchant portal.

This case study presents a product concept and interactive prototype. It has not shipped to production or been used by real merchants — see the note on scope below.

Insert a strong hero image representing the Merchant Solutions concept — e.g. a composed shot of the Pay by Bank checkout alongside the Merchant Dashboard.

/images/merchant-solutions/merchant-solutions-hero.png
Role
Product Design / Product Strategy
Domain
Payments · Fintech · B2B
Product
Buyer Checkout + Merchant Portal
Stage
Concept / Prototype
Focus
A2A Payments · Real-Time Payments · Merchant Operations

Introduction

Designing both sides of a payment

Payment experiences are rarely just a checkout screen. Behind a simple customer action sits an interconnected system of bank connectivity, payment authorization, settlement, transaction states, operational visibility, and reconciliation.

For Kurense Merchant Solutions, I explored how those pieces could come together as one coherent product experience — simple for buyers, but powerful enough for merchants to understand and manage money movement.

Context

The opportunity

The concept was informed by several payment-market and merchant experience challenges, rather than a formal primary research study of my own.

Merchant pain points

  • Delayed settlement timelines
  • Chargeback risk
  • Limited payment-status transparency
  • Growing demand for direct bank payment options

Market opportunity

  • Growth of real-time payment networks
  • Expansion of FedNow
  • Increasing familiarity with linked-bank payments
  • Growth of embedded finance

The opportunity space centered around these dynamics — not on findings from merchant interviews I personally conducted.

Design Objective

Make bank payments feel simple without hiding what merchants need to know.

Enable

Real-time merchant payments

Simplify

Buyer checkout

Centralize

Transaction visibility

Secure

Bank connectivity and payment interactions

Scale

A foundation for future embedded-finance capabilities

The System

Designing the experience as a connected system

I approached the product as four connected experience layers, sitting on top of an underlying banking layer I designed around rather than built.

Buyer

Selects Pay by Bank at checkout.

Plaid

Connects and verifies the buyer's bank account.

Payment Rails

RTP / FedNow support payment processing and settlement.

Merchant Portal

Provides visibility, transaction management, reporting, and fund operations.

Experience flow

  1. 01Buyer
  2. 02Plaid
  3. 03RTP / FedNow
  4. 04Merchant Portal

Underlying — Banking Layer

  • Sponsor relationship
  • Account structure
  • Settlement infrastructure

Understanding the underlying system helped me design experiences around realistic payment states, dependencies, and operational needs. This diagram represents the product experience architecture I designed around — not infrastructure I built or engineered.

My Role

My role

I translated the payment concept into an end-to-end product experience across both buyer and merchant journeys. My work included defining the experience architecture, mapping the payment flow, designing the Pay by Bank journey, creating the merchant portal experience, and connecting complex payment concepts to clear user-facing interactions.

My product management experience also helped me evaluate the concept through the lenses of business value, implementation dependencies, operational workflows, and product scalability.

Areas of contribution

  • Product concept development
  • Experience strategy
  • Information architecture
  • User flows
  • Buyer checkout design
  • Merchant portal design
  • Interaction design
  • High-fidelity prototyping
  • Payment-state UX
  • Dashboard and data visualization concepts
  • Cross-functional product thinking

Two Users, Two Very Different Needs

One payment system, two very different experiences

Buyer

  • A familiar checkout
  • Minimal manual entry
  • Confidence connecting a bank
  • Clear authorization
  • Clear payment confirmation
  • Low cognitive load

Design goal

Hide infrastructure complexity without reducing trust.

Merchant

  • Payment visibility
  • Transaction status
  • Balance visibility
  • Settlement information
  • Transaction history
  • Reconciliation support
  • Fund transfer
  • Reporting

Design goal

Surface enough complexity to support confident financial operations.

The buyer experience should make complexity disappear. The merchant experience should make complexity understandable.

Buyer Journey

Simplifying Pay by Bank

The design goal was to keep the customer focused on one decision at a time while providing enough context to build trust in an unfamiliar payment method.

  1. 01Select Pay by Bank
  2. 02Connect bank via Plaid
  3. 03Verify account / select account
  4. 04Authorize payment
  5. 05Payment processes through the real-time payment flow
  6. 06Receive confirmation

Buyer Design Principles

Principles behind the checkout experience

Familiarity

Use familiar ecommerce patterns even though the underlying payment mechanism differs from a card transaction.

Trust

Make bank connectivity, account selection, authorization, and confirmation explicit.

Progressive disclosure

Reveal payment complexity only when it is relevant to the buyer's next decision.

Buyer Prototype

The Pay by Bank flow

A closer look at the buyer-facing sequence, from checkout to confirmation.

Insert the checkout screen showing Pay by Bank as a payment option.

/images/merchant-solutions/buyer-pay-by-bank.png
Step 01

Select Pay by Bank

Presented alongside familiar payment options so choosing a bank payment feels like a normal checkout decision, not a departure from one.

Insert the screen where the buyer initiates bank connection via Plaid.

/images/merchant-solutions/buyer-plaid-connect.png
Step 02

Connect via Plaid

Hands off to a familiar bank-linking pattern rather than asking buyers to manually enter routing and account numbers.

Insert the bank authentication step within the Plaid connection flow.

/images/merchant-solutions/buyer-authenticate.png
Step 03

Authenticate bank

Authentication is clearly scoped to the buyer's bank, keeping a visible boundary between the Kurense experience and the third-party Plaid flow.

Insert the account-selection screen once the bank connection succeeds.

/images/merchant-solutions/buyer-select-account.png
Step 04

Select account

Surfaces only the information needed to choose the right account, reducing decision effort at a step where errors are costly.

Insert the final payment authorization/confirmation screen.

/images/merchant-solutions/buyer-confirm-payment.png
Step 05

Confirm payment

Authorization and confirmation are treated as distinct, explicit moments — the buyer always knows what they approved and that it went through.

Plaid / Bank Connectivity

Reducing friction in bank connectivity

Instead of asking buyers to manually enter routing and account information, the experience uses a familiar bank-linking pattern to reduce friction and errors while maintaining clear boundaries between the merchant experience and bank authentication.

  • Secure bank authentication
  • Account verification
  • Balance validation
  • Reduced manual account entry

Kurense's experience and Plaid's own authentication flow are kept visually and functionally distinct — the design does not represent or take credit for Plaid's underlying security implementation.

Merchant Experience

From payment acceptance to payment operations

Completing a payment is only the beginning of the merchant experience. Merchants also need to understand what happened, where their money is, what requires attention, and what they can do next.

Core merchant jobs

  • View incoming payments
  • Track payment status
  • Search transaction history
  • Understand balances
  • Review settlements
  • Transfer funds
  • Export data
  • Review statements

Merchant Portal Information Architecture

Organizing around merchant questions, not payment technology

I organized the product around the merchant's recurring operational questions rather than around the underlying payment technology.

  1. 01Dashboard
  2. 02Transactions
  3. 03Balance & Payout
  4. 04Statements
  5. 05Settings
What happened?Transactions
How much money is available?Balance & Payout
How is the business performing?Dashboard
What records do I need?Statements
How do I manage the account?Settings

Dashboard & Payment Visibility

Structuring the dashboard around what merchants ask first

Financial dashboards can become collections of numbers without hierarchy. I structured the dashboard around the questions merchants are most likely to ask first: what is available, what came in, what did it cost, and what happened recently?

Insert the Merchant Dashboard design.

/images/merchant-solutions/merchant-dashboard.png

The dashboard concept includes

  • Available balance
  • Gross revenue
  • Fees
  • Net earnings
  • Revenue trends
  • Transaction trends
  • Recent transactions

Transaction Management

Designing for scanability, not just data density

The challenge was not simply displaying transaction data. It was helping merchants identify the state and financial meaning of a payment quickly enough to take action.

Insert the transaction table/list design.

/images/merchant-solutions/transactions.png

Insert the transaction detail view design.

/images/merchant-solutions/transaction-detail.png

Merchants can

  • Search
  • Filter
  • Review transaction status
  • View gross amount
  • Understand fees
  • See net amount
  • Inspect buyer / bank information where appropriate
  • Access transaction records
  • Export transaction data

Payment status design

Payment products require states to be visually and linguistically distinct. The prototype represents statuses such as Paid, Pending, and a Failed/exception state — each designed with its own label, hierarchy, and treatment rather than color alone.

In both the transaction list and the transaction detail view, status is communicated with a text label alongside color, so meaning doesn't depend on color perception — consistent between list and detail so a merchant scanning quickly and a merchant investigating one payment see the same language.

Balance & Fund Movement

Giving money movement the hierarchy it needs

Money movement requires stronger confirmation and hierarchy than ordinary SaaS actions. I designed the experience so the current balance, destination account, transfer amount, and payout history remain visible within the same operational context.

Insert the Balance & Payout design.

/images/merchant-solutions/balance-payout.png
Available balance
What can the merchant access now?
Transfer action
How can the merchant move funds?
Destination
Where will the funds go?
Payout history
What has already happened?

Statements & Reporting

Reporting as part of the operational experience

Positioned as part of the ongoing operational experience rather than an afterthought.

Insert the Statements design.

/images/merchant-solutions/statements.png
  • Monthly statements
  • Gross payment activity
  • PDF export
  • CSV export

Settings & Linked Bank Accounts

Centralizing account relationships without overexposing them

Financial settings need to make important account relationships understandable without unnecessarily exposing backend complexity.

Insert the merchant Settings design.

/images/merchant-solutions/settings.png
  • Business information
  • Linked bank account
  • Notification preferences

Designing for Payment Complexity

Turning payment infrastructure into understandable product states

Infrastructure

RTP / FedNow

Connectivity

Plaid

Money Movement

Payment, balance, settlement, transfer

Operational Experience

Transactions, reporting, statements, settings

My role as a product designer was not to make merchants understand the payment infrastructure. It was to understand enough of that infrastructure myself to design clear states, actions, and information around it.

Technical Collaboration / Constraints

Designing around system dependencies

Payment-product design requires consideration of a wide range of dependencies, even when working from a concept rather than a live integration:

Bank connectivity

Third-party integrations

Payment states

Settlement

Account structures

Transaction data

Error / exception handling

Security

Operational workflows

The experience was designed with the understanding that UI behavior depends on the capabilities and states exposed by underlying systems.

Service Blueprint

Designing the experience as a connected flow

Buyer Experience

  1. Select Pay by Bank
  2. Connect bank
  3. Select account
  4. Authorize
  5. Confirmation

Payment / Platform Layer

  1. Plaid verification
  2. Payment processing
  3. RTP / FedNow
  4. Settlement / state

Merchant Experience

  1. Payment appears
  2. Status visible
  3. Balance updates
  4. Transaction detail
  5. Reporting / transfer

Simplified experience model — not a literal technical architecture diagram.

Design Decisions

Key design decisions

01

Separate buyer simplicity from merchant depth

The buyer sees only what is required to complete payment. The merchant receives richer operational information.

02

Design around payment states

Status and confirmation are treated as core parts of the product, not secondary UI details.

03

Organize merchant workflows around jobs

Transactions, balance, reporting, and settings are separated based on operational intent.

04

Treat visibility as part of the payment experience

A payment experience is incomplete if the merchant cannot understand what happened afterward.

What I Would Validate Next

What I would validate next

This work is a concept and prototype, not a validated, shipped product. These are the questions I'd want to answer before treating it as production-ready:

Buyer comprehension

Do customers understand Pay by Bank and feel comfortable connecting an account?

Checkout friction

Where do users hesitate or abandon the payment flow?

Merchant information hierarchy

Can merchants quickly identify payment status, available funds, and exceptions?

Transaction workflows

Can merchants efficiently find and investigate a payment?

Fund movement

Do merchants understand available balance, transfer destination, timing, and confirmation?

Reporting

Does the reporting structure match reconciliation and operational needs?

Accessibility

Can status and payment information be understood without relying only on color?

Where the Concept Landed

Where the concept landed

The work established a cohesive product direction for Kurense Merchant Solutions across both buyer and merchant experiences. The concept demonstrated how bank connectivity, real-time payment infrastructure, transaction visibility, fund movement, and reporting could be translated into one understandable product ecosystem.

Buyer

Low-friction Pay by Bank concept

Merchant

Centralized operations experience

Platform

Connected A2A payment model

Design

Reusable interaction patterns for financial workflows

These reflect the direction the concept established, not measured production outcomes.

What I Learned

What I learned

Payment UX extends far beyond checkout

Designing the merchant experience revealed how much of the user experience happens after authorization.

Transparency creates trust

Merchants need clear visibility into payment state and money movement.

Technical understanding improves design

Understanding the relationships between bank connectivity, payment rails, and merchant operations made the design more coherent.

Simplicity is audience-dependent

The right amount of complexity for a buyer is very different from the right amount for a merchant.

Note: This project is presented as a conceptual product-design case study. It has not launched, processed real transactions, or been used by real merchants or buyers. Certain details and visuals may be simplified or modified to protect confidential business information. All data shown is anonymized prototype information only.

Next Project

iPay Client Portal

A modern B2B payments platform helping client administrators manage cardholders, funding, payment activity, exceptions, reporting, and account operations.