Local Currency & seller disbursement for AWS Marketplace

Role: UX Designer

Timeline: 2024

Team: Product manager, UX, Developers, Local ops team

Skills: Fintech UX, Enterprise payments, Seller experience

AWS Marketplace Local Currency lets global enterprise buyers procure software and services in their preferred currency, EUR, GBP, CAD, AUD, or JPY removing the foreign exchange risk that comes with predictable invoicing. This project focused on the seller side of that system: banking and disbursement. Before this, sellers could only set up one disbursement method, a US-based bank account limited to USD which meant that even when a buyer paid in their local currency, AWS Marketplace had to convert it to USD before the seller ever saw it.

To comply with my non-disclosure agreement, any confidential information is omitted in this case study.

The problem

AWS Marketplace sellers could only get paid one way: a US ACH bank account, disbursed in USD. If a buyer paid in a non-USD currency, AWS converted that payment to USD before it ever reached the seller's payable balance exposing both sides of the transaction to foreign exchange risk they had no way to avoid.

For non-US sellers, the workaround was worse: register with an external partner, HyperWallet, to obtain a virtual ACH account, then hand those details back to AWS Marketplace. It worked, but it was a detour built on top of a system that was never designed for international sellers in the first place.

Project Local Currency set out to fix this at the source letting buyers pay in their currency of choice (EUR, GBP, CAD, AUD, JPY) and letting sellers receive disbursement in that same currency, with a new SWIFT-based payment method sitting alongside the existing US ACH option.

Who does this problem impact? (Personas)

• Seller - Financial Officer

  • Financial Officers will be delighted by the banking & disbursement experience considering their focuses on reporting the latest numbers to upper management by preparing timely latest disbursement reports with relevant KPIs.

Expanding the scope: from feature addition to full revamp

The original requirement documentation was to add SWIFT as a new payment method option to the existing US-based ACH banking and disbursement experience. But when I ran my own UX investigation into that existing experience before I started any UX work, I found a deeper problem. It wasn't just missing international support, the banking and disbursement experience was unclear in its information architecture, its interaction patterns, and how it communicated to sellers.

Layering more payment method, with its own form fields, validation rules, and processing flow, onto an already-confusing foundation would have compounded the problem rather than solved it. So I escalate the situation to the product team and we made the case to expand scope: not a patch, but a full revamp of the banking and disbursement experience, designed to scale cleanly across all three payment methods (ACH, SWIFT, HyperWallet).

Research & discovery

To support AWS Marketplace sellers in managing how they receive payments, I mapped the end-to-end user flow for the Payment Information experience within the AWS Marketplace Management Portal (AMMP) Settings page — covering everything from initial seller onboarding through tax information, bank account setup, disbursement preferences, and currency-specific KYC verification.

Mapping the End-to-End Flow

Starting from AWS customer onboarding through registering as a Marketplace seller, I traced how a seller lands on the Settings page and branches into the core sub-flows: updating seller profile information, managing payment information (tax information, bank accounts, and disbursement setup), bank verification, Know Your Customer (KYC) verification, notifications, and tags.

The most complex branch was Payment Information, which splits into two parallel paths:

• Bank account setup — sellers can add either a SWIFT account (supporting multiple currencies including AUD, GBP, CAD, EUR, JPY, and USD) or a US-based ACH account (USD only).

• Disbursement preference setup — sellers configure a disbursement method, name, and currency, then select a disbursement bank account and schedule.

A key decision point in the flow is whether bank account and KYC verification is required — this depends on the currency and region the seller operates in. Sellers selling in the US, Australia, or Japan don't need additional KYC verification, while sellers selling in the EU/UK or receiving payments from AWS EMEA are routed into Configure KYC and a verify bank information step before they gain the capability to publish offers in that currency.

Lo-fi Wireframe

I translated this flow into a lo-fi wireframe of the actual Settings — Payment Information page, showing:

• Account summary (legal business name, business location, account status)

• Tax information status (tax interview, DAC7 questionnaire, tax documents)

• Bank accounts table with add/edit/view actions

• Disbursement preference module, including the empty state ("No disbursement preference") and the call-to-action to add one

This wireframe let the team validate the information architecture and interaction patterns early — before investing in detailed visual design — ensuring the currency/KYC branching logic was clearly surfaced to sellers rather than buried in edge cases.

User testing with customers

I started to test the design with users from usertrsting.com to actual AWS Marketplace sellers. The core flow held up well overall, but three findings shaped the next round of design:

• One user wanted payment profile information surfaced directly on the settings page, rather than buried a click away.

• Two user got stuck adding a bank account for a disbursement preference with no unique naming convention, they couldn't tell which account he was actually selecting.

• The TrendMicro users weren't just testing the flow; they were trying to understand the system behind it who has visibility into which bank accounts, and whether a UK-based team could see US accounts. That question mattered enough that it needed to be answered in the design, not just in a support doc and we were able to catch these edge cases early to.

Designing the Geo-fencing & KYC verification flow

The most complex design challenge was regulatory, not visual. When a seller selects a SWIFT bank account signaling they'll receive payment in the UK or sell to EMEA-based buyers compliance requires them to complete Know Your Customer (KYC) verification on top of standard bank account verification. These aren't parallel steps; they're sequential and gated. A seller has to clear bank account verification before KYC even becomes available, and failure at either step puts them in a different state.

To design this well, I embedded with the engineering team through several working sessions to understand the geo-fencing logic itself: which countries trigger KYC, how the verification handoff works technically, and how the two verification steps interact. That gave me the conditional logic mapped out clearly enough to translate into a linear, understandable flow for sellers:

Seller — SWIFT selected → receive payment in the UK or EMEA → geo-fence detected → KYC → required bank verification — without exposing the technical machinery behind it. Sellers always know where they are in the process and what's required next, even when a regulatory requirement adds an unexpected step.

Final design

Impact

• AWS Marketplace Local Currency shipped in Nov, 2024

• It gave sellers a path to receive disbursement in the same currency their buyers pay in — eliminating FX risk that previously sat on both sides of every non-USD transaction.

• It has generated over $1 billion in Total Contract Value from non-U.S. customers and achieving 190% of the organization's 2025 revenue target.

Lessons learned

1. Challenge the scope when your own investigation reveals a deeper problem — don't just execute the brief. The original ask was to add international payment methods to an existing experience. My own investigation showed that experience was too broken to build on. I'm glad I advocated for the full revamp, but I could have gotten there faster with a heuristic evaluation of the existing experience up front — making the case for a redesign in week one instead of mid-project.

2. Embed with engineering early when regulatory logic drives the design. The geo-fencing and KYC flow had deep technical dependencies — sequential gates, country-based conditional logic — that fundamentally shaped the UX. Next time, I'd request a technical architecture walkthrough in the first sprint, mapping every conditional path and state transition before sketching a single screen.

3. Design for scalability from the start when the system is clearly growing. The project went from one payment method to three, each with unique fields, validation, and verification flows. I'd approach a project like this by designing a modular component system upfront, built to absorb the next payment method rather than requiring rework when it arrives.