Designing a Payment Review System for Accuracy, Trust, and Scale

In the early stages of Plumter's B2B platform, payment review was relatively simple. A reviewer could open a payment in a modal, inspect the submitted details, download the attached invoice, and either approve or decline the transaction. That worked while transaction volume was low and the operational process was still straightforward.

As Plumter grew, payment review became more complex. Reviewers were no longer only checking whether a payment had been submitted correctly. They needed to compare invoices against payment details, verify whether beneficiary information could be trusted, understand what the sender was actually allowed to make payments for, and consider previous issues or rejection history before deciding whether money should move.

Several limitations started becoming obvious:

• Payment review was still constrained to a modal.
• Invoices and payment details could not be viewed together.
• Important review context was fragmented across different surfaces.
• Reviewers had to download invoices or switch between views to compare information.
• Increasing operational complexity made the process harder to scale.

The review process had become more investigative, but the interface still treated it like a basic approval action.

To support this growing complexity, I moved payment review from a modal into a side panel. The goal was to keep the payment itself accessible while creating more room for the context reviewers needed to make a decision. This included actions, remarks, notes, attachments, review stage, beneficiary details, and other supporting information.

The side panel also allowed reviewers to remain inside the broader payment queue while investigating an individual transaction, rather than losing their place every time they opened one.

The interface became denser, but that was intentional. For Compliance and Operations, the priority was not keeping the interface visually minimal. It was making the right information available at the moment a financial decision was being made.

One of the clearest workflow problems came from how reviewers used invoices. The invoice was often the first thing they opened. Reviewers treated it as a source of truth, comparing it against the submitted payment amount, beneficiary information, invoice number, and purpose of payment.

But the product made that comparison unnecessarily difficult because reviewers had to first download or open the invoice separately, then switch between it and the payment details while mentally keeping track of what they were comparing.

I introduced a side by side invoice viewer so the invoice and payment details could remain visible together. This turned comparison from something reviewers had to manually orchestrate into a native part of the review experience.

It introduced more information on screen, but that was another deliberate tradeoff. In a financial review workflow, reducing the effort required to compare evidence was more important than preserving visual simplicity.

As payment volume increased, another problem became more important. Having information available was not enough. Reviewers also needed help understanding how much confidence to place in it.

A payment could contain every required field and still require deeper judgement. The sender's business context might not align with the payment, beneficiary details could be questionable, or an invoice could look materially different from previous invoices associated with the same beneficiary.

I began introducing trust signals directly into the review workflow:

• Business remarks helped reviewers understand what a sender had been approved to make payments for.
• Beneficiary confidence indicators gave reviewers more context on how reliable specific beneficiary details appeared.
• Invoice history and archetyping allowed new invoices to be compared against known examples from the same beneficiary.

This made payment review less dependent on memory, repeated manual checks, or the experience of an individual reviewer.

Not every payment could be resolved by one reviewer. Some required a second opinion, additional document review, or clarification from another member of Compliance or Operations.

Previously, those conversations could move into Slack, WhatsApp, or separate internal notes, separating the discussion from the transaction itself.

I introduced comments directly into the payment review. Reviewers could leave comments, tag teammates, and attach supporting files while keeping the conversation tied to the payment.

This meant anyone returning to the transaction later could understand what had been discussed, who had been involved, and what context influenced the eventual decision.

As more people became involved in review, preserving the history of each transaction also became important. I designed a transaction timeline that recorded key actions such as creation, updates, approvals, declines, and other changes, along with who performed them.

Reviewers could see:

• Important events across the life of the payment.
• Who performed each action.
• Changes that had been made.
• Supporting context such as declination messages.

This made the review process more transparent and auditable, while reducing the need to rely on memory or ask around to understand what had happened previously.

As Payment Review continued to grow, the side panel eventually reached its own limits. Comments, invoice history, rejection history, errors, declinations, AI checks, timelines, and other review tools were all competing for space around the same transaction.

Rather than continuing to stack more information into the panel, I evolved Payment Review into a full review workspace. Payment details remained the stable source of truth, while deeper review tools were separated into dedicated areas that could be opened when needed.

The new structure allowed:

• Core payment information to remain persistent.
• Contextual tools to live in a structured menu.
• Invoices, comments, AI checks, errors, logs, and declinations to open in dedicated views.
• New review capabilities to be added without continually expanding the primary information surface.

This gave the system room to continue growing without losing the payment at the centre of the review.

The new workspace also created room for AI assisted payment review. The goal was not to automate approval. Compliance still required human judgement, so AI was introduced as another source of evidence within the review process rather than a system making the final decision.

An AI check could run while the reviewer continued inspecting the payment. Once complete, it returned a structured review containing a summary, risk signals, score, and suggested verdict.

The reviewer could then compare those findings against their own investigation. That way, AI became another reviewer in the process, not the final authority over whether money should move.

Over time, Payment Review evolved from a simple approval interface into a structured system for understanding whether a transaction could be trusted enough to proceed.

Reviewers could compare invoices and payment details in context, understand beneficiary and business signals, investigate previous activity, collaborate around difficult cases, and preserve the history behind payment decisions without leaving the review workflow.

The system evolved alongside Plumter itself, supporting the platform as it scaled to $3.7B+ in total transaction volume, including $2.06B processed across 67,159 transactions in 2025.