Global Checkout Config & Payment Orchestration
A product exploration designing a merchant dashboard that abstracts the complexity of enabling 100+ local payment methods worldwide, recommending the right methods automatically and letting merchants preview exactly what each buyer sees.
↑ Concept: a merchant checkout that reconfigures itself per market, without a single line of merchant-side code.
The "local" cart abandonment crisis
When a US-based e-commerce business sells to a customer in the Netherlands, it typically offers global credit cards. But over 60% of Dutch consumers prefer iDEAL, a local bank-transfer system. In Brazil, it's PIX. In China, Alipay. If the checkout page doesn't offer the local payment method, the buyer simply abandons the cart.
Yet for a merchant, enabling these methods is its own nightmare, each has distinct fee structures, dispute risk, and settlement delays no small business has time to research market by market.
The Buyer
"I reached checkout, but they only accept Visa and Mastercard. I don't use credit cards, I only use my local bank app. I guess I'm not buying this."
The Merchant
"I want to sell in Europe, but I have no idea what 'Klarna' or 'Bancontact' means. Do they have chargebacks? When do I get the money in my US bank account?"
What this exploration covered
As an independent concept exploration, I owned the full arc, from checkout-flow research through interaction design and projected impact modeling, without a live production team to hand off to.
Checkout Flow Research
Analyzed 20 mid-market global merchants' live checkout flows to identify the dominant failure pattern.
Orchestration Design
Designed the Method Recommender and the merchant-facing rules engine for dynamic payment-method display.
Simulation Tooling
Designed the WYSIWYG Checkout Simulator that lets a merchant preview any market's checkout before publishing changes.
Impact Modeling
Modeled projected conversion lift per market based on published local-payment-method adoption data.
Three compounding failures in global checkout
The "Endless Accordion" anti-pattern
Merchants stacked 15+ payment methods into one long list. A buyer in Germany had to scroll past US-only options like Affirm or Venmo just to find Giropay, friction that reads as untrustworthy, not just slow.
Merchants aren't payment experts
Small merchants had no reasonable way to know that iDEAL matters in the Netherlands, or that Boleto matters in Brazil. Expecting them to research payment methods market-by-market was expecting the wrong expertise from the wrong team.
Fear of breaking checkout
There was no safe way to test a new rule (e.g. "only show Klarna over $50") without risking a broken checkout on a live site, so merchants avoided changing configuration at all, freezing them into their worst-performing default.
How might we let a merchant with zero payments expertise offer the right local payment method to every buyer, in every market, with full confidence in what it costs and when the money arrives?
If we replace a static, merchant-curated payment list with an algorithmic recommendation layer, plus a WYSIWYG simulator that shows exactly what each buyer would see before anything goes live, then merchants will confidently enable more local payment methods, and non-US conversion will rise.
Auditing 20 merchants before designing anything
To understand the friction points concretely, I analyzed the checkout flows of 20 mid-market global merchants. The dominant anti-pattern, the "Endless Accordion", showed up in the majority of them: every available method, everywhere, all the time, regardless of who was actually buying.
Checkout Flow Audit
Reviewed live checkout experiences across 20 mid-market global merchants, cataloguing how each surfaced (or buried) local payment methods.
A/B Testing & Funnel Analysis
Analyzed drop-off rates across the checkout funnel; the payment-method selection screen alone caused a 15% abandonment rate.
What the audit made obvious
More methods isn't the fix: the right method, surfaced first, is
Merchants weren't under-supplied with payment options. They were over-supplying the wrong ones to the wrong buyers, all at once.
Merchants need a recommendation, not a reference manual
Nobody was going to read a guide to European payment methods. They needed the system to just tell them what to turn on, and why.
Confidence to change configuration mattered as much as the configuration itself
Merchants avoided touching checkout settings entirely rather than risk breaking a live store, the biggest unlock wasn't a new feature, it was a safe place to test one.
The rules we designed by, and why
1 · Algorithm over guesswork
Merchants shouldn't guess what to enable, the platform recommends methods from customer geodata.
2 · WYSIWYG checkout preview
Show merchants exactly what a buyer in Berlin sees vs. a buyer in Tokyo, before anything ships.
3 · Transparent trade-offs
Clearly surface fee, dispute risk, and settlement timeline before any method is toggled on.
From audit to algorithm to safe simulation
Each stage built directly on what the previous one proved or disproved.
01 Iteration 01 · Diagnosis Auditing 20 Merchant Checkouts
Before proposing any solution, I catalogued exactly how 20 mid-market global merchants presented payment options today. The "Endless Accordion" pattern, every method, every market, all at once, was the clear, repeated failure mode worth solving structurally rather than patching case by case.
02 Iteration 02 · Algorithmic Concept Designing the Method Recommender
I designed a recommendation engine dashboard: when a merchant enters a new market, say, Brazil, the UI proactively suggests enabling PIX and Boleto, backed by published local-adoption data rather than the merchant's own guesswork. This reframed the merchant's job from "research payment methods" to "review a recommendation."
03 Iteration 03 · Safe Validation The WYSIWYG Checkout Simulator
To remove the "fear of breaking checkout," I designed a simulator built directly into the dashboard. Merchants change the mock buyer's IP location, currency, and cart value in a left-hand panel, and instantly see the exact checkout UI that buyer would see on the right, before publishing a single rule change.
The choices that shaped the concept
Decision 01 · Algorithmic recommendation vs. a static reference guide
Tension: A reference guide is simpler to build; an algorithm requires ongoing data and maintenance.
Choice & trade-off: I designed for an active recommendation engine. A guide nobody reads solves nothing, the whole point was removing the need for merchants to become payment experts.
Decision 02 · Full simulator vs. a simple preview screenshot
Tension: A static preview is far cheaper to build than an interactive, parameterized simulator.
Choice & trade-off: I chose the interactive simulator, the core problem was merchants' fear of the unknown, and a static screenshot can't answer "what if my buyer is in Brazil with a €40 cart?"
Decision 03 · Surfacing fee and settlement data upfront vs. after enablement
Tension: Showing every fee and settlement detail upfront adds visual density to an already complex dashboard.
Choice & trade-off: I surfaced it upfront anyway, the merchant interview data was clear that "no surprises on settlement day" mattered more to trust than a cleaner-looking toggle list.
Previewing the buyer's localized reality
The WYSIWYG Checkout Simulator lets a merchant change a mock buyer's location, cart value, and currency, and see the exact resulting checkout, before anything goes live.
Test Parameters
↑ The simulator's left panel drives the mock buyer context; the right panel renders the exact checkout that buyer would see, iDEAL surfaced first for a Netherlands-based cart.
How we arrived at the solution
A/B Testing & Funnel Analysis
Analyzed drop-off rates across the checkout funnel, identifying that the payment-method selection screen caused a 15% abandonment rate.
Checkout Friction Workshop
Brought together UX, Engineering, and Risk to brainstorm ways to reduce form fields without compromising fraud checks.
Illustration Placeholder
Prompt: A stylized illustration of an A/B testing and funnel-analysis workshop for an e-commerce checkout flow, conversion heatmaps on screens, in bright violet and white tones. Rendered as a clean illustration on a fully transparent background (no backdrop, scene, or color fill), so it displays cleanly on both light and dark page themes.
Projected outcomes of the concept
This is a concept exploration, not a shipped feature. Figures below are modeled from published local-payment-method adoption data and the checkout audit, not measured production results.
↑ Modeled conversion lift per market once the recommended local method is surfaced first, based on published adoption data for each method.
Honest reflections from the process
What Worked
Auditing real merchants before designing anything
Cataloguing 20 live checkouts first meant the "Endless Accordion" problem was documented, not assumed. That gave the whole concept a concrete failure mode to design against.
Treating "fear of breaking checkout" as a design problem, not a training problem
The obvious answer was "write better documentation." The simulator solved the actual problem, confidence, instead of asking merchants to read more.
What I'd Do Differently
Validate the recommendation engine with real merchant interviews, not just flow audits
As a concept exploration, this relied on checkout-flow analysis and public adoption data. Moderated sessions with the merchants themselves would sharpen whether "recommend and explain" is really enough, or whether some merchants want more manual control than the concept currently allows.
Design the dispute/chargeback edge cases as thoroughly as the happy path
The simulator is strong for previewing what a buyer sees, but a shipped version would need equally rigorous design for what happens when a local method's dispute process kicks in, that's where merchant trust would really be tested.