Payment platform evaluation
Procured on assurances.
Launched on evidence.
A third-party payment platform was replacing more than 100 payment journeys across the organisation. As sole Product Designer on the evaluation, I established what could prevent people from paying independently, what needed fixing before launch, and what risk would remain.
Role
Period
Team
Scope
Supplier platform under evaluation
State 01
Valid quantity returned £0.00
State 02
Re-entering 1 produced 10 and £700, while the action remained blocked.
Because the issue prevented payment, fixing it became a condition of launch.
The situation
The platform was procured without design requirements
The procurement had focused on service requirements before design became involved. The supplier described the platform as accessible and ready, but could not provide an audit or evidence from user testing to support that.
We had intended to redesign the payment experience, but the fixed launch timeline removed that option, and moving to other work was a real option. The platform still couldn't launch without evidence people could use it, so I proposed an evaluation. Product and service leadership initially supported accessibility only.
because the boundary between accessibility and usability often breaks down in practice.
Product and leadership agreed.
I also flagged that we would be the first customer on this version, with no previous customer feedback to rely on. I focused the evaluation on whether users could complete essential payments and what had to change before go-live.
Decision 01
Testing followed shared patterns, not every journey
More than 100 payment journeys reused the same underlying flows. I mapped them to identify distinct patterns, then created a testing framework and used it to select representative examples. This covered every distinct journey type without repeating the same checks service by service.
Testing framework
01
Amount behaviour
Fixed / entered / editable balance
02
Quantity
Single / multiple items
03
Payment method
Card / saved card / Apple Pay
04
Outcome and recovery
Success / decline / timeout
05
Entry context
Service / direct link / account / email
06
Device and access
Desktop / mobile / keyboard / screen reader
Decision 02
Severity followed user consequence, not technical complexity
I defined successful payment around independent completion, clear confirmation, recovery from failure and avoiding incorrect or duplicate charges, including with assistive technology. For screen-reader users, there was often no reliable way to know whether a payment had succeeded. The severity model then turned each failure into a launch decision.
I built the issue database to keep each finding's context, evidence, severity, relevant accessibility criterion, supplier response and retest result together. After the first substantial batch of findings, the supplier began responding issue by issue and documenting fixes.
The supplier continued to change the configuration during the evaluation, altering behaviour and invalidating earlier checks. I escalated the need for a stable environment and reran affected scenarios. A supplier-owned blocker stayed open until I retested the changed build and confirmed the issue was resolved.
Verification record
Go-live blocker → Supplier marked fixed → Retest passed
Decision 03
Passing compliance didn’t mean people could pay
Accessibility requirements gave the review an enforceable baseline, but usability was also part of the agreed scope because compliance did not capture every way a payment could fail.
Users could complete the visible fields while Pay remained unavailable until they discovered an intermediate Add line step. I documented this before launch as a severe usability risk. Although it was within the agreed scope, the supplier prioritised issues it was legally required to fix, so it was not addressed before launch.
After launch, users reported the same inability to progress. Wording later changed to Add item, but the underlying interaction remained largely unchanged.
User needs show whether people can complete what they came to do.
Interaction reviewed before launch
"The pay button cannot be pressed and it has a red no entry type sign on it. The old system worked every time but you have changed it to a new company and it is broken."
Online feedback after launch
Outcome
Launch proceeded with verified fixes and documented risks
go-live blockers
fixed and passed retest before launch
Stripe-owned blockers
remained open and were documented in the accessibility statement
I kept the two Stripe issues classified as blockers. Because the supplier could not change the Stripe-owned components within the deadline, the Product Manager chose to proceed with those risks documented rather than treating them as resolved.
“HeyCentric would like you to know that your input made their product significantly better, and we have been the only customer to hold them to such a high level of accountability!”
Supplier feedback shared after the evaluation
View next case study