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

Payments were:

• Payments were manually coordinated through Slack and WhatsApp, making the process slow and dependent on human follow-ups.
• Exchange rates fluctuated constantly, leaving businesses uncertain about the value they would receive.
• Pricing and fees lacked transparency, making it difficult to understand the true cost of a transaction.
• Users had to commit before they had clarity, reducing confidence in both the rates and the overall payment experience

Design a system that:

• Provides clear pricing and fees
• Handles FX volatility
• Reduces errors
• Creates a reliable moment of commitment

I designed the payment flow to begin with a SWIFT code or routing number.

This allowed the system to determine the beneficiary's country, identify the receiving bank, validate supported destinations, and check against prohibited or restricted regions.

This first step acted as an early compliance gate. Instead of allowing users to complete a payment only to discover later that the destination could not be supported, the product could prevent invalid transactions earlier in the process.

Once the bank and destination country were resolved, the payment form adapted to the requirements of that transaction.

This mattered because cross-border payments are not uniform. Different countries and banking systems require different details, so a static form would either ask for too much information or miss critical requirements.

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

This reduced user effort while helping operations and compliance get the information they needed.

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 simple: the product should help users submit better payments, not just collect payment requests.

One of the most important decisions was when to show exchange rates.

Because FX rates fluctuated constantly, showing them too early could create false expectations. To avoid this, I designed the flow so rates appeared at the review stage, when the user had entered the required details and was close to submission.

At this point, users could review the exchange rate, fees, final recipient amount, wallet to be debited, beneficiary details, and supporting documents.

This created a clearer moment of commitment. Users were not just submitting a form. They were making a financial decision with the relevant information in front of them.

Even at the review stage, rates could still change before the wallet was debited. Instead of hiding that uncertainty, I made it visible.

The review screen explained that the displayed exchange rate was real-time and subject to change, and that the actual amount would be determined when the wallet was debited.

The goal was not to pretend volatility did not exist. It was to help users understand it before they proceeded.

The review screen becomes a single point of validation, replacing fragmented confirmations across WhatsApp and calls.

This redesigned payment flow helped move Plumter from manual coordination to a structured product experience.

It reduced pricing ambiguity, prevented avoidable errors, surfaced compliance constraints earlier, and reduced repeated back-and-forth with operations.

Most importantly, it gave businesses a payment experience they could understand and trust without needing someone from Plumter to guide every step.

As transaction volume scaled, this structure became critical in maintaining consistency and reliability across thousands of payments.

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.

Design a lifecycle system that could:

• Provide clear visibility into payment progress
• Help users understand what each status meant
• Make required actions easy to find
• Support approvals, amendments, cancellations, and issue resolution
• Create a shared source of truth for customers and internal teams
• Work consistently across web and mobile

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

This meant a payment was no longer just a submitted request. It became something users could return to, understand, and act on throughout its lifecycle.

Each transaction detail view brought together the information users needed to make sense of the payment: amount, beneficiary details, bank information, supporting documents, invoice details, status, and available actions.

This created a single place for users to understand what was happening without reaching out to support.

Transactions could exist in states such as: Pending Approval, Processing, Issues, Rejected, Pending Cancellation, Cancelled, Completed, Failed.

Each state was designed to communicate three things:

• What was happening
• Whether action was required
• What the user could do next

This made the payment lifecycle easier to understand and helped reduce the ambiguity that previously came with manual updates.

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.

Users ignored important requests 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.

Design a system that could:

• Drive action across the product
• Communicate urgency clearly
• Reduce manual follow-ups from operations
• Support different issue types and severity levels
• Align user behavior with operational and compliance needs

I redesigned issues as a flexible system that could be triggered from the back office for any required customer action.

This made issues useful across:

• Payments
• Compliance
• Onboarding
• Operations

Instead of creating separate alert patterns for every workflow, the system gave Plumter one consistent way to communicate required actions to customers.

Some issues needed more than visibility. They needed urgency.

For these cases, I introduced timed issues.

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" or "Account dormancy in 43 days"

This helped users understand not only what needed attention, but what could happen if they did nothing.

When multiple timed issues existed, the system prioritized the issue with the most urgent deadline.

This prevented users from being overwhelmed by a long list of tasks and ensured that the most time-sensitive action stayed visible.

The banner remained persistent across the product, with the option to expand for more context.

The issues component was designed to be sticky, always visible, and not dismissible.

This was intentional. If an issue had operational or compliance consequences, the product could not treat it like a regular notification. Users needed to remain aware of it while moving through the platform.

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.