Designing Plumter's Cross-Border Payments Platform Processing $2B+ Annually

Customers needed to make cross border payments through a process affected by several things at once:

• Payments depended heavily on manual follow up
• Exchange rates changed constantly
• Pricing and fees were not always clear before commitment
• Different countries and banking systems required different information
• Incorrect payment or beneficiary information could create problems later in processing

The product needed to guide businesses through that complexity without requiring someone from Plumter to walk them through every transaction.

One of the earliest decisions was to start the payment flow with a SWIFT code or routing number.

That allowed the system to resolve the receiving bank and destination country before asking the user to complete the rest of the payment.

It also meant we could check whether a destination was supported early, rather than allowing a customer to complete an entire payment only to discover later that it could not be processed.

Once the destination was known, the payment form adapted to the requirements of that transaction.

Cross border payments are not uniform. Different countries and banking systems require different details, so a single static form would either ask users for unnecessary information or fail to collect something important.

The product adjusted required fields, validation rules, form structure, and supporting information based on the destination.

This turned what could have been one large generic payment form into a flow shaped by the payment the user was actually trying to make.

After the destination and bank details were confirmed, users were guided through beneficiary details, payment information, and supporting documents.

The goal was to prevent avoidable errors before submission.

Users were prompted to upload invoices or related documents that showed the purpose of payment, and were guided to ensure invoice details matched the beneficiary and payment information.

Where possible, validation was introduced early so users could correct issues before the payment entered processing.

The principle was that the product should help users submit better payments, not just collect payment requests.

Another important decision was when to show the exchange rate. Because rates fluctuated constantly, showing one too early could create an expectation that Plumter could not guarantee.

I designed the flow so the rate appeared at the review stage, once the user had entered the required information and was close to submitting the payment. At that point, they could review the rate, fees, final recipient amount, wallet being debited, beneficiary details, and supporting documents together.

But even then, the rate could still change before the wallet was actually debited. Rather than hiding that uncertainty, I made it explicit.

The interface explained that the displayed rate was real time and subject to change, and that the final amount would be determined when the debit happened.

The review screen became the moment where fragmented confirmations that previously happened through calls and messages came together into one financial decision.

The new payment flow helped move Plumter from manual coordination to a structured product experience.

It reduced pricing ambiguity, surfaced unsupported destinations earlier, helped prevent avoidable errors, and reduced repeated back and forth with Operations.

Most importantly, businesses could understand what they were paying, where the money was going, and what they were committing to without needing someone from Plumter to guide every step.

Users ignored important requests & issues across the product, including:

• Payment RFIs
• Compliance requests
• KYC updates
• Operational tasks

In many cases, users continued using the product as long as their immediate task was not blocked.

This created delays for operations and compliance teams, who still had to follow up manually through calls, messages, and emails.

The product needed to move beyond showing issues. It needed to help drive action.

For more critical issues, I introduced timed urgency.

Instead of only showing a static message like "19 issues require attention," the product could surface time sensitive warnings such as:

• Payment suspension in 02 days
• Account dormancy in 43 days

This helped users understand not only what needed attention, but also how urgent it was and what could happen if they did nothing.

The goal was to make the consequence of inaction visible before that consequence actually happened.

When multiple timed issues existed, the system prioritised the issue with the nearest deadline.

This prevented users from being overwhelmed by several competing requests and kept the most urgent action visible first.

The warning was also designed to remain persistent across the product and could not simply be dismissed like a normal notification.

If an issue had an operational or compliance consequence, the product needed to treat it differently from ordinary product messaging.

Users could still expand the warning to understand the issue in more detail, but the urgency remained visible wherever they moved within the product.

For unresolved critical issues, the system could eventually move an account into a restricted state.

In this state, key actions were disabled until the user completed the required steps.

This created a clear consequence for inaction and helped Plumter reduce repeated manual follow-ups.

The system was not designed to punish users immediately. It was designed to give them enough warning, context, and time to act before restrictions took effect.

The redesigned issues system helped turn passive alerts into actionable responsibilities.

It improved issue resolution by making urgent tasks harder to ignore, reduced repeated follow-ups from operations teams, and gave customers a clearer understanding of what needed to be done.

It also gave Plumter a scalable way to enforce important actions across payments, onboarding, compliance, and operations without relying entirely on manual communication.

The biggest shift was moving from awareness to accountability.

Users were not just being told that issues existed. They were being shown what mattered most, how much time they had, and what would happen if they did nothing.

Before the Vendor Platform, customers had limited visibility into what happened after they submitted a payment.

They had to rely on updates from the Plumter team to know whether a transaction was processing, completed, delayed, or needed action.

Internally, operations also needed a clearer way to track payment movement, manage changes, and keep customers aligned without repeating the same updates manually.

The problem was not only status visibility. It was the lack of a shared source of truth for every transaction.

I designed each payment as a persistent object with its own status, history, details, and available actions.

Instead of disappearing into an operational process after submission, a payment became something the user could return to, understand, and act on throughout its lifecycle.

Each transaction brought together the information needed to understand what was happening, including beneficiary and bank information, invoices, supporting documents, status, and available actions.

I also defined clear transaction states such as Pending Approval, Processing, Issues, Rejected, Pending Cancellation, Cancelled, Completed, and Failed.

Each state needed to communicate what was happening, whether the user needed to do anything, and what they could do next.

This reduced the ambiguity that previously came with waiting for manual updates from the Plumter team.

Many Plumter customers operated with internal teams, so payments often needed to be created by one person and approved by another.

To support this, I designed a maker-checker flow where payments could enter a pending approval state before being sent to Plumter for processing.

This helped businesses keep internal control over payment execution while reducing the risk of unauthorized or incorrect transactions.

To strengthen trust, users could copy a transaction reference and verify the payment externally through Plumter's document verification page.

This was especially important for customers who needed to confirm the authenticity or status of a payment outside the main product experience.

Users could also track payments inside the product, giving them both internal visibility and external verification when needed.

The Vendor Platform was not designed as a web product with a lighter mobile companion. Every major payment workflow was also available on mobile.

Users could create payments, track transaction states, view analytics, resolve issues, approve workflows, and manage transactions end-to-end from either platform.

This mattered because payment work does not always happen at a desk. The mobile experience gave users the same operational confidence wherever they accessed the product.

This lifecycle system replaced fragmented communication with a shared transaction record for every payment.

It gave users clearer visibility into payment progress, reduced the need for repeated support follow-ups, and helped internal teams stay aligned around the same transaction data.

It also made complex workflows such as approvals, amendments, cancellations, issue resolution, tracking, and verification easier to manage as transaction volume grew.

As Plumter scaled to tens of thousands of payments annually, this structure became critical to maintaining clarity, consistency, and trust across the platform.