Online Payment Platform
Online Payment Platform
From Black Box to Revenue Protection and Merchant Trust
From Black Box to Revenue Protection and Merchant Trust
One of the world's largest online payment platforms was losing market share to more agile competitors. It's clients processed extremely high volumes of transactions daily, but had no way to check real-time payment status. Industry standard is unforgiving: at the first sign of trouble, clients redirect traffic to competitors — and repeated incidents mean permanently lost volume, and revenue.
One of the world's largest online payment platforms was losing market share to more agile competitors. It's clients processed extremely high volumes of transactions daily, but had no way to check real-time payment status. Industry standard is unforgiving: at the first sign of trouble, clients redirect traffic to competitors — and repeated incidents mean permanently lost volume, and revenue.
The Business Context
The Business Context
Processing several million transactions daily, across dozens of countries
Operating on thin per-transaction margins, typical for the payments industry
Experiencing a measurable, ongoing decline in market share
Customers switched to competitors at the first perceived sign of instability
Processing several million transactions daily, across dozens of countries
Operating on thin per-transaction margins, typical for the payments industry
Experiencing a measurable, ongoing decline in market share
Customers switched to competitors at the first perceived sign of instability
A Trust Crisis
A Trust Crisis
The real problem wasn't technology — it was trust.
Merchants typically use multiple payment providers simultaneously. The moment one payment platform showes any sign of trouble, they redirect traffic to competitors.
Without transparency and visibility, the platform couldn't compete, no matter how good the underlying technology and processes were.
The real problem wasn't technology — it was trust.
Merchants typically use multiple payment providers simultaneously. The moment one payment platform showes any sign of trouble, they redirect traffic to competitors.
Without transparency and visibility, the platform couldn't compete, no matter how good the underlying technology and processes were.
My contribution
My contribution
I turned a black-box payment platform into a transparent, trust-restoring merchant experience. As Service Designer, UX Strategist and UI Designer, I:
I turned a black-box payment platform into a transparent, trust-restoring merchant experience. As Service Designer, UX Strategist and UI Designer, I:
designed an intelligent failure-categorisation system that separated actionable issues from noise,
built a layered real-time monitoring platform, from health overview down to transaction-level detail,
gave merchants a smart filtering system where they could easily build their own filters instead of having to rely on a limited predefined set,
introduced baseline comparison and incident-summary features that turned raw data into context.
designed an intelligent failure-categorisation system that separated actionable issues from noise,
built a layered real-time monitoring platform, from health overview down to transaction-level detail,
gave merchants a smart filtering system where they could easily build their own filters instead of having to rely on a limited predefined set,
introduced baseline comparison and incident-summary features that turned raw data into context.
Results achieved
Results achieved
Due to an NDA, I'm unable to share specific figures or client details. I left the organisation before the platform's full rollout, so the outcomes below reflect what was validated during the beta pilot, not post-launch performance.
Due to an NDA, I'm unable to share specific figures or client details. I left the organisation before the platform's full rollout, so the outcomes below reflect what was validated during the beta pilot, not post-launch performance.
Project overview
Project overview
My role
My role
Service Designer • UI Designer
Service Designer • UI Designer
Duration
Duration
6 months
6 months
team
team
1 Project owner
1 Project owner
3 Back-end Developers
3 Back-end Developers
2 Front-end Developers
2 Front-end Developers
1 Compliance Officer
1 Compliance Officer
Scope
Scope
Monitoring dashboard for API payment traffic and webhook deliveries;
Error-code intelligence — turning raw failure codes into something a non-technical merchant could act on;
API key and integration health overview;
Drill-down from summary metrics to detailed logs
Monitoring dashboard for API payment traffic and webhook deliveries;
Error-code intelligence — turning raw failure codes into something a non-technical merchant could act on;
API key and integration health overview;
Drill-down from summary metrics to detailed logs
Research
Research
Before designing anything, I conducted thorough diagnostics:
Before designing anything, I conducted thorough diagnostics:
In-depth interviews with international merchants (e-commerce, fintech, travel);
Interviews with internal operations and engineering teams;
Review of existing monitoring tools, both internal and competitors';
Analysis of transaction logs and incident reports;
Review of existing monitoring tools, both internal and competitors;
Qualitative research into how merchants diagnosed problems;
Stakeholder interviews with compliance, IT and management to understand constraints upstream and downstream of the visible workflow
In-depth interviews with international merchants (e-commerce, fintech, travel);
Interviews with internal operations and engineering teams;
Review of existing monitoring tools, both internal and competitors';
Analysis of transaction logs and incident reports;
Review of existing monitoring tools, both internal and competitors;
Qualitative research into how merchants diagnosed problems;
Stakeholder interviews with compliance, IT and management to understand constraints upstream and downstream of the visible workflow
Root cause analysis
Root cause analysis
Three Areas of Failure:
3 Areas of Failure:
01.
01.
The "Black Box" Problem: No Visibility
The "Black Box" Problem: No Visibility
02.
02.
Lack of Actionable Intelligence
Lack of Actionable Intelligence
03.
03.
Trust Erosion Through Opacity
Trust Erosion Through Opacity
03.
Trust Erosion Through Opacity
root cause analysis
root cause analysis
01.
01.
The "Black Box" Problem: No Insight
The "Black Box" Problem: No Insight
Payment integrations rely on two separate signals: the API request a merchant's system sends to initiate a payment, and the webhook — an automatic status update the platform sends back afterward, often used to confirm the payment and trigger order fulfilment. Merchants had no way of looking into either one. All they saw was:
Payment integrations rely on two separate signals: the API request a merchant's system sends to initiate a payment, and the webhook — an automatic status update the platform sends back afterward, often used to confirm the payment and trigger order fulfilment. Merchants had no way of looking into either one. All they saw was:
Input: they sent a payment request;
Output: success or failure , if and when it arrived.
Input: they sent a payment request;
Output: success or failure , if and when it arrived.
Everything in between was a black hole — and critically, this applied twice over. A merchant could eventually find out why a payment had failed. But there was no equivalent way to check whether a webhook had been delivered, delayed, or dropped. Several merchants only discovered webhook problems when a customer complained that a paid order had never shipped — the payment itself had succeeded, but the notification telling the merchant's own system to act on it never arrived.
Everything in between was a black hole — and critically, this applied twice over. A merchant could eventually find out why a payment had failed. But there was no equivalent way to check whether a webhook had been delivered, delayed, or dropped.
Several merchants only discovered webhook problems when a customer complained that a paid order had never shipped — the payment itself had succeeded, but the notification telling the merchant's own system to act on it never arrived.
Everything in between was a black hole.
Everything in between was a black hole.
We suddenly saw more failed payments. We had no idea if it was us, them, or external factors. Within minutes we'd redirected a large share of our traffic elsewhere. Turned out later it was just a batch of expired credit cards — completely normal."
We suddenly saw more failed payments. We had no idea if it was us, them, or external factors. Within minutes we'd redirected a large share of our traffic elsewhere. Turned out later it was just a batch of expired credit cards — completely normal."
This kept happening. Merchants couldn't quickly distinguish between customer-side issues (expired cards, insufficient funds), merchant-side issues (configuration, API integration), provider-side issues (gateway failures, outages), and external issues (network, processor downtime). Making this distinction cost precious time — by then, merchants had already redirected traffic.
This kept happening.
Merchants couldn't quickly distinguish between customer-side issues (expired cards, insufficient funds), merchant-side issues (configuration, API integration), provider-side issues (gateway failures, outages), and external issues (network, processor downtime). Finding out cost precious time — by then, merchants had already redirected traffic.
root cause analysis
root cause analysis
02.
02.
Lack of Actionable Intelligence
Lack of Actionable Intelligence
insight
insight
Not all payment failures were actionable by the merchant. Merchants can't do anything about expired cards or insufficient funds — but they still spent time investigating them. This created decision fatigue: "Is this my problem, or theirs?"
Not all payment failures were actionable by the merchant. Merchants can't do anything about expired cards or insufficient funds — but they still spent time investigating them. This created decision fatigue: "Is this my problem, or theirs?"
Not all payment failures were actionable by the merchant. Merchants can't do anything about expired cards or insufficient funds — but they still spent time investigating them. This created decision fatigue: "Is this my problem, or theirs?"
Log analysis confirmed the pattern: a substantial share of failures were non-actionable (cards, currency, external blocks), a smaller share were merchant-actionable (config, integration), and a smaller share still were provider-actionable. Merchants had no way to filter these out — they had to investigate everything.
Log analysis confirmed the pattern: a substantial share of failures were non-actionable (cards, currency, external blocks), a smaller share were merchant-actionable (config, integration), and a smaller share still were provider-actionable. Merchants had no way to filter these out — they had to investigate everything.
root cause analysis
root cause analysis
03.
03.
Trust Erosion Through Opacity
Trust Erosion Through Opacity
This was subtle but critical. Merchants said:
This was subtle but critical. Merchants said:
I can tolerate failures. I cannot tolerate uncertainty."
I can tolerate failures. I cannot tolerate uncertainty."
A provider who says "Yes, we had an outage, this was the root cause, that is the fix" — that merchant stays. A provider who stays silent looses traffic immediately.
The old monitoring tools showed numbers, but no context. A failure rate on its own meant nothing to a merchant with no sense of what was normal, alarming, or catastrophic.
A provider who says "Yes, we had an outage, this was the root cause, that is the fix" — that merchant stays. A provider who stays silent looses traffic immediately.
The old monitoring tools showed numbers, but no context. A failure rate on its own meant nothing to a merchant with no sense of what was normal, alarming, or catastrophic.
ServiceTransformation Strategy
Service
Transformation Strategy
Instead of isolated UI fixes, I designed a complete real-time intelligence platform built on five principles.
Instead of isolated UI fixes, I designed a complete real-time intelligence platform built on five principles.
01.
01.
Real-Time Visibility
Real-Time Visibility
Intelligent File Handling
Intelligent File Handling
02.
02.
Error Intelligence:
Error Intelligence:
Actionable vs. Noise
Actionable vs. Noise
03.
03.
Smart Filtering
Smart Filtering
From Many Dimensions to Usability
From Many Dimensions to Usability
04.
04.
Drill-Down
Drill-Down
From Overview to Transaction Detail
From Overview to Transaction Detail
05.
05.
Reliability
Reliability
Showing expiry dates
Showing expiry dates
05.
Reliability
Showing expiry dates
Service transformation Strategy
Service transformation Strategy
01.
01.
Real-time Visibility: Intelligent File Handling
Real-time Visibility: Intelligent File Handling
Core Problem
Merchants need data on a sub-second basis, not retrospectively.
The research had surfaced two separate blind spots, not one: the payment request itself, and the webhook confirming it afterward. Merchants needed one place to answer “is it us, is it a customer, or is it the platform?” for both.
Merchants need data on a sub-second basis, not retrospectively.
The research had surfaced two separate blind spots, not one: the payment request itself, and the webhook confirming it afterward. Merchants needed one place to answer “is it us, is it a customer, or is it the platform?” for both.
My Approach
My Approach: Real-time Transaction Stream of Requests and Deliveries
Real-time Transaction Stream of Requests and Deliveries
Instead of reports, I designed a living transaction stream — every transaction visible near-instantly, with volume trends and failure spikes shown in real time.
All in a single dashboard split into an API Requests section and a Webhooks section, each showing the same core shape — total volume, a success/fail split, and a percentage breakdown — so merchants could read both with the same mental model instead of learning two different tools.
Instead of reports, I designed a living transaction stream — every transaction visible near-instantly, with volume trends and failure spikes shown in real time.
All in a single dashboard split into an API Requests section and a Webhooks section, each showing the same core shape — total volume, a success/fail split, and a percentage breakdown — so merchants could read both with the same mental model instead of learning two different tools.
Design Choice:
Design Choice:
Total requests, successful, failed, and a split between client-type errors and server-type errors sit in a single summary row at the top, before any chart. A merchant glancing at the screen for five seconds gets the health check without reading a graph.
Total requests, successful, failed, and a split between client-type errors and server-type errors sit in a single summary row at the top, before any chart. A merchant glancing at the screen for five seconds gets the health check without reading a graph.
This gave merchants both benefits at once: real-time data and performance.
This gave merchants both benefits at once: real-time data and performance.
Image: Traffic Overview at a glance
Image: Traffic Overview at a glance
Service transformation Strategy
Service transformation Strategy
02.
02.
Error Intelligence: Actionable vs. Noise
Error Intelligence: Actionable vs. Noise
This was the strategic heart of the platform.
This was the strategic heart of the platform.
critical insight
Critical Insight
Merchants didn't want a raw list of HTTP codes. They wanted to know, in plain terms, whether a spike was expected noise or something to investigate.
Merchants didn't want a raw list of HTTP codes.
They wanted to know, in plain terms, whether a spike was expected noise or something to investigate.
My Approach: intelligent categorisation
My Approach: intelligent categorisation
I designed an intelligent filtering system that automatically categorises failures:
I designed an intelligent filtering system that automatically categorises failures:
Non-Actionable (Expected Noise): expired cards, insufficient funds, customer cancels, card blocked by bank
Merchant-Actionable: configuration errors, API integration issues, merchant-side timeouts, invalid request formats
Provider-Actionable: payment gateway failures, internal system errors, network infrastructure issues, processing bottlenecks
Non-Actionable (Expected Noise): expired cards, insufficient funds, customer cancels, card blocked by bank
Merchant-Actionable: configuration errors, API integration issues, merchant-side timeouts, invalid request formats
Provider-Actionable: payment gateway failures, internal system errors, network infrastructure issues, processing bottlenecks
I grouped errors at two levels. At the top level, failures are split into 4xx (problems with the request itself — often traceable to the customer or merchant side) versus 5xx (problems on the platform side). Underneath that, each specific error code — payment required, bad request, conflict, not found, too many requests, forbidden — is broken out individually with its own count, so a merchant can see exactly which failure type is driving a spike.
I grouped errors at two levels. At the top level, failures are split into 4xx (problems with the request itself — often traceable to the customer or merchant side) versus 5xx (problems on the platform side). Underneath that, each specific error code — payment required, bad request, conflict, not found, too many requests, forbidden — is broken out individually with its own count, so a merchant can see exactly which failure type is driving a spike.
Challenge: How to show this without overwhelming the user?
Challenge: How to show this without overwhelming the user?
My first prototypes showed three separate failure graphs. Some said: "I get three graphs at once. I don't know where to look."
My iteration: Allow for an overview of all failures, but also provide tabs dedicated to only one type of failure.
My first prototypes showed three separate failure graphs. Some said: "I get three graphs at once. I don't know where to look."
My iteration: Allow for an overview of all failures, but also provide tabs dedicated to only one type of failure.
Service transformation Strategy
03.
Smart Filtering: From Many Dimensions to Usability
Merchants could filter by country/region, payment method, error type, time window, and individual transaction attributes — dozens of filterable dimensions in total.
Prototype problem: a UI exposing all of them looked like an aeroplane cockpit. Compiling filters themselves also felt intimidating for merchants.
Prototype problem
An UI exposing all of them looked like an aeroplane cockpit.
Research into which filters merchants actually used showed a clear pattern: payment method and error category were used far more often than the rest, with geography, specific error code and customer segment trailing behind.
My Approach: Visual Guidance
Since building these filters at times felt for some merchants like 'programming' I opted to guide users step by step through the process:
Make clear where to start and after completing it show the next steps one step at a time. This prove to be the way merchants more easily configured filters since it appeared less daunting.
The user starts by selecting a field from a dropdown — in this case "Error" — with an info icon offering a short explanation of what that field represents, for merchants unfamiliar with the underlying data.
Once a field is chosen, the interface presents the relevant operators as a row of selectable pills rather than a second dropdown: is, is not, is one of, is not one of, exists, does not exist. Keeping them visible as one row (instead of nesting them in another menu) lets merchants see all their filtering options at a glance and compare them before choosing.
After selecting an operator (here, "is"), a value input appears with live autocomplete — typing "Inva" immediately surfaces matching values from the dataset, such as "Invalid authorization" and "Invalid value," with the matched characters bolded. This does two things at once: it saves the merchant from having to know or guess the exact error string, and it prevents invalid filters by only offering values that actually exist in the data.
Together, the three steps (field → operator → value) build toward a single filter condition, which — based on the "+ Create filter" pattern — merchants can likely stack to build more advanced, multi-condition queries all to their own needs.
Clicking 'Create filter' opens a popover containing a field selector, a segmented control for the operator, and an autocomplete input for the value in sequential steps
Service transformation Strategy
03.
Smart Filtering: From Many Dimensions to Usability
Merchants could filter by country/region, payment method, error type, time window, and individual transaction attributes — dozens of filterable dimensions in total.
Prototype problem: a UI exposing all of them looked like an aeroplane cockpit. Compiling filters themselves also felt intimidating for merchants.
Prototype problem
An UI exposing all of them looked like an aeroplane cockpit.
Research into which filters merchants actually used showed a clear pattern: payment method and error category were used far more often than the rest, with geography, specific error code and customer segment trailing behind.
My Approach: Visual Guidance
Since building these filters at times felt for some merchants like 'programming' I opted to guide users step by step through the process:
Make clear where to start and after completing it show the next steps one step at a time. This prove to be the way merchants more easily configured filters since it appeared less daunting.
The user starts by selecting a field from a dropdown — in this case "Error" — with an info icon offering a short explanation of what that field represents, for merchants unfamiliar with the underlying data.
Once a field is chosen, the interface presents the relevant operators as a row of selectable pills rather than a second dropdown: is, is not, is one of, is not one of, exists, does not exist. Keeping them visible as one row (instead of nesting them in another menu) lets merchants see all their filtering options at a glance and compare them before choosing.
After selecting an operator (here, "is"), a value input appears with live autocomplete — typing "Inva" immediately surfaces matching values from the dataset, such as "Invalid authorization" and "Invalid value," with the matched characters bolded. This does two things at once: it saves the merchant from having to know or guess the exact error string, and it prevents invalid filters by only offering values that actually exist in the data.
Together, the three steps (field → operator → value) build toward a single filter condition, which — based on the "+ Create filter" pattern — merchants can likely stack to build more advanced, multi-condition queries all to their own needs.
Clicking 'Create filter' opens a popover containing a field selector, a segmented control for the operator, and an autocomplete input for the value in sequential steps
Service transformation Strategy
Service transformation Strategy
04.
04.
Drill-down: From Overview to Transaction Detail
Drill-down: From Overview to Transaction Detail
Merchants needed to move fluidly between levels:
Merchants needed to move fluidly between levels:
Level 1 — Health Overview (a few seconds): overall success/failure rates, trend indicators, active alerts locked by bank
Level 2 — Pattern Detection (tens of seconds): failure rates by payment method, region, error category; time-series charts; anomaly highlights
Level 3 — Diagnostic Detail (minutes): individual transaction logs, full error messages, API request/response payloads, processing-time breakdowns
Level 4 — Root-Cause Analysis (deep dive): cross-dimensional correlation, comparison against historical baselines, related incident patterns
Level 1 — Health Overview (a few seconds): overall success/failure rates, trend indicators, active alerts locked by bank
Level 2 — Pattern Detection (tens of seconds): failure rates by payment method, region, error category; time-series charts; anomaly highlights
Level 3 — Diagnostic Detail (minutes): individual transaction logs, full error messages, API request/response payloads, processing-time breakdowns
Level 4 — Root-Cause Analysis (deep dive): cross-dimensional correlation, comparison against historical baselines, related incident patterns
A dashboard that only summarises is only half useful — merchants investigating a specific incident eventually need the underlying log entry.
A dashboard that only summarises is only half useful — merchants investigating a specific incident eventually need the underlying log entry.
My Approach
My Approach
Every chart selection carries through to a “view selection in logs” action, taking the merchant from the visual summary straight into the filtered, detailed API or webhook log for that exact time window and error type — no need to re-enter filters manually.
Every chart selection carries through to a “view selection in logs” action, taking the merchant from the visual summary straight into the filtered, detailed API or webhook log for that exact time window and error type — no need to re-enter filters manually.
Service transformation Strategy
Service transformation Strategy
05.
05.
Reliability: Showing expiry dates
Drill-down: From Overview to Transaction Detail
Two failure sources didn't show up in the error-code breakdown at all, and research showed they caused real incidents: expiring API keys, and webhooks that kept failing to deliver.
Two failure sources didn't show up in the error-code breakdown at all, and research showed they caused real incidents: expiring API keys, and webhooks that kept failing to deliver.
My Approach
My Approach
An API key table showing every key's expiry date, when it was last used, and its traffic trend, with an explicit warning when a key is close to expiring — turning a silent future outage into something visible weeks in advance. For webhooks, a parallel summary shows total delivery attempts, how many succeeded, the average number of attempts per event, and how many events failed after exhausting all retries, so merchants can tell a slow-but-recovering integration from one that's actually broken.
An API key table showing every key's expiry date, when it was last used, and its traffic trend, with an explicit warning when a key is close to expiring — turning a silent future outage into something visible weeks in advance. For webhooks, a parallel summary shows total delivery attempts, how many succeeded, the average number of attempts per event, and how many events failed after exhausting all retries, so merchants can tell a slow-but-recovering integration from one that's actually broken.
Design Process
Design Process
Discovery & Research
Discovery & Research
I mapped the complete request/response flow for both payment API calls and webhook deliveries, and identified where failures could originate — customer input, merchant integration, platform processing, and downstream delivery — so the categorisation logic in the dashboard was grounded in the actual flow
I mapped the complete request/response flow for both payment API calls and webhook deliveries, and identified where failures could originate — customer input, merchant integration, platform processing, and downstream delivery — so the categorisation logic in the dashboard was grounded in the actual flow
Ideation & Prototyping
Ideation & Prototyping
I explored three fundamentally different approaches to presenting error data:
I explored three fundamentally different approaches to presenting error data:
Alert-only
Alert-only
Surface only anomalies and thresholds breached, hide the rest. Testing: merchants distrusted a dashboard that hid the underlying numbers — they wanted to verify an alert against the raw data themselves.
Surface only anomalies and thresholds breached, hide the rest. Testing: merchants distrusted a dashboard that hid the underlying numbers — they wanted to verify an alert against the raw data themselves.
Full Log Table
Full Log Table
A dense, filterable table of every request. Testing: powerful for deep investigation, but far too slow as a first stop — merchants had to scroll and filter before getting any sense of overall health.
A dense, filterable table of every request. Testing: powerful for deep investigation, but far too slow as a first stop — merchants had to scroll and filter before getting any sense of overall health.
Layered Summary-to-Detail (chosen direction)
Layered Summary-to-Detail (chosen direction)
Headline metrics, then charts, then error-code breakdown, then a link into the full log. Testing: this matched how merchants actually investigated — a glance, then a look, then a deep-dive only when something looked wrong.
Headline metrics, then charts, then error-code breakdown, then a link into the full log. Testing: this matched how merchants actually investigated — a glance, then a look, then a deep-dive only when something looked wrong.
Key Learning
Merchants didn't want less data than the full log offered — they wanted the same data organised by urgency, with the raw detail always one click away rather than the default view.
Merchants didn't want less data than the full log offered — they wanted the same data organised by urgency, with the raw detail always one click away rather than the default view.
Consistent Pattern Across Sections
The API Requests and Webhooks sections deliberately mirror each other's layout — summary row, two charts, side panel — so a merchant who has learned to read one already knows how to read the other.
Visual Design
Visual Design
Legibility Under Time Pressure
Legibility Under Time Pressure
Operations and finance teams frequently checked this dashboard during an active incident, often on a shared screen. Numbers needed to be readable at a glance, so headline metrics use a larger scale than supporting chart labels.
Operations and finance teams frequently checked this dashboard during an active incident, often on a shared screen. Numbers needed to be readable at a glance, so headline metrics use a larger scale than supporting chart labels.
Colour as Signal
Colour as Signal
Success is shown in a consistent green, failures in red, with 4xx and 5xx kept visually distinct so a merchant can tell “request problem” from “platform problem” without reading the label.
Success is shown in a consistent green, failures in red, with 4xx and 5xx kept visually distinct so a merchant can tell “request problem” from “platform problem” without reading the label.
Consistent Pattern Across Sections
Consistent Pattern Across Sections
The API Requests and Webhooks sections deliberately mirror each other's layout — summary row, two charts, side panel — so a merchant who has learned to read one already knows how to read the other.
The API Requests and Webhooks sections deliberately mirror each other's layout — summary row, two charts, side panel — so a merchant who has learned to read one already knows how to read the other.
Consistent Pattern Across Sections
The API Requests and Webhooks sections deliberately mirror each other's layout — summary row, two charts, side panel — so a merchant who has learned to read one already knows how to read the other.
Critical Learnings
Critical Learnings
Learning
Learning
01.
01.
Merchants Read the Error-Code Panel First, Not the Chart.
Merchants Read the Error-Code Panel First, Not the Chart.
Early layouts led with the trend chart and put the per-code breakdown in a side panel below it. Pilot users consistently looked for “what's actually failing” before “when.” I moved the error-code list higher and made it visible without scrolling.
Early layouts led with the trend chart and put the per-code breakdown in a side panel below it. Pilot users consistently looked for “what's actually failing” before “when.” I moved the error-code list higher and made it visible without scrolling.
Learning
Learning
02.
02.
The 4xx/5xx Split Needed to Be the Default View, Not a Toggle Option Merchants Had to Find
The 4xx/5xx Split Needed to Be the Default View, Not a Toggle Option Merchants Had to Find
Initially this was buried in a filter menu. Once it became one of three default chart tabs, alongside the combined view, usage of the split view increased sharply and merchants reported diagnosing issues faster.
Initially this was buried in a filter menu. Once it became one of three default chart tabs, alongside the combined view, usage of the split view increased sharply and merchants reported diagnosing issues faster.
Learning
Learning
03.
03.
Expiring API Keys Were an Invisible Failure Mode
Expiring API Keys Were an Invisible Failure Mode
Several pilot merchants had experienced an outage caused by an API key expiring without warning, something the original error dashboard couldn't have shown since it wasn't a request failure at all. Adding the expiry warning to the key table came directly out of this finding.
Several pilot merchants had experienced an outage caused by an API key expiring without warning, something the original error dashboard couldn't have shown since it wasn't a request failure at all. Adding the expiry warning to the key table came directly out of this finding.
Learning
Learning
04.
04.
Webhook Health Needed Its Own Section, Not a Footnote
Webhook Health Needed Its Own Section, Not a Footnote
Merchants initially assumed webhook reliability was covered by the API error breakdown. It isn't — a webhook can fail to deliver for reasons that have nothing to do with the original payment API call. Giving webhooks a parallel, equally prominent section — rather than folding it into the API view — matched how merchants actually thought about their integration.
Merchants initially assumed webhook reliability was covered by the API error breakdown. It isn't — a webhook can fail to deliver for reasons that have nothing to do with the original payment API call. Giving webhooks a parallel, equally prominent section — rather than folding it into the API view — matched how merchants actually thought about their integration.
Early beta users double-checked automatic conversions — converting files manually, then uploading them, defeating the purpose of the automation entirely.
Early beta users double-checked automatic conversions — converting files manually, then uploading them, defeating the purpose of the automation entirely.
Root Cause
Root Cause
Versions of the service had made errors, and that history didn't disappear just because the system changed.
Versions of the service had made errors, and that history didn't disappear just because the system changed.
My Solution
My Solution
A "View Processing Details" feature — underneath every conversion, a clickable link to the processing log, showing exactly what the service had done on the user's behalf.
A "View Processing Details" feature — underneath every conversion, a clickable link to the processing log, showing exactly what the service had done on the user's behalf.
After staff had verified accuracy 2-3 times, they stopped double-checking. Trust in a service is earned incrementally, not declared.
After staff had verified accuracy 2-3 times, they stopped double-checking. Trust in a service is earned incrementally, not declared.
Conclusion
Conclusion
This project reinforced that in high-stakes, transactional environments, clarity beats density. Merchants weren't losing trust because of failures — they were losing it because they couldn't tell their own problem from the platform's.
By translating raw error codes into merchant-actionable categories, and by surfacing failure modes merchants couldn't previously see at all, I helped shift the conversation from “more data” to “transparency as a competitive strategy” — a case I believe in, even though I moved on before seeing it through to full launch.
The lesson: Transparency is strategy.
This project reinforced that in high-stakes, transactional environments, clarity beats density. Merchants weren't losing trust because of failures — they were losing it because they couldn't tell their own problem from the platform's.
By translating raw error codes into merchant-actionable categories, and by surfacing failure modes merchants couldn't previously see at all, I helped shift the conversation from “more data” to “transparency as a competitive strategy” — a case I believe in, even though I moved on before seeing it through to full launch.
The lesson: Transparency is strategy.
The tool
The tool
Every organisation has its own version of this complexity. Let's solve yours.
Every organisation has its own version of this complexity. Let's solve yours.