Cross-Border Payments Infrastructure
Designing an async payment system for Japan market entry: local payment methods, FX handling, reconciliation, and edge case logic for a K-beauty e-commerce platform.
Company
K-beauty e-commerce platform
Role
Product Manager
Market
US → Japan expansion
Scope
Payments · Async flows · Reconciliation
01 — My Contribution
What I Did as Product Manager
As an early team member, I owned end-to-end product definition for Japan market entry, from problem framing through launch. With no existing playbook for async flows, I drove alignment across engineering and finance on every design decision before a single line was written.
Problem Definition & Scoping
Identified the core incompatibility between Japan's async payment methods and our synchronous order system. Defined the full scope of what needed to be redesigned: inventory logic, order status communication, settlement handling, and reconciliation mapping.
Mockups & Flow Design
Built end-to-end payment state flows in Figma, covering every state (pending, confirmed, partial, expired, overpayment) with customer-facing communication and edge case logic at each stage.
PRD & Spec Writing
Wrote the PRD and payment state spec used by in-house engineering for implementation. Defined acceptance criteria and edge case coverage requirements including idempotency handling and partial payment resolution logic.
Cross-functional Alignment
Aligned with finance on reconciliation event schema at design time, mapping every state to a tagged finance event before engineering began, so there was no ambiguity at launch.
Early team member · In-house engineering · Direct collaboration with finance
02 — Background
Context & Problem
After stabilizing the US platform, we identified Japan as the next expansion target. K-beauty had a clear white space at our price point with no direct competitor. But entering Japan meant rethinking the payment experience from scratch.
The Core Problem
Our entire order system was built on synchronous payment confirmation. Konbini and bank transfer (Japan's dominant payment methods) break that assumption. Confirmation can take hours to days.
What this broke
Inventory logic: hold or not while waiting for async confirmation?
Order status communication: what do we tell the customer before payment clears?
Settlement timing: confirmation events needed idempotent handling to prevent duplicates
Reconciliation: every payment state needed a finance mapping
03 — System Design
Payment State Diagram
Every state a payment can reach, and what the system does at each one. Click any state to see system actions, customer communication, and edge case handling.
What we had to design for Japan
Payment confirmation is decoupled from order creation. The system must handle every possible outcome, including ones that never exist in a sync flow.
Entry
Order Created
Click any outcome to see system actions and edge cases
Konbini or bank transfer confirmed
System Actions
Inventory
Decremented atomically; fulfillment workflow triggered
CRM
Status updated to confirmed; shipping workflow initiated
Finance
AR settled; revenue recognized; CONFIRMED reconciliation event logged
Customer Communication
Payment confirmed + order confirmed + estimated shipping timeline.
Edge Cases
- →Duplicate webhook from provider; idempotency key prevents second fulfillment trigger
- →Confirmation arrives after expiry window: CS exception workflow, not auto-fulfilled
04 — Design Decisions
What I Designed
Five decisions that shaped the system. Toggle technical detail for the full engineering rationale.
Decision
What
Why
What
No hold, 2-day cancel window
Why
High LTV, high repeat-purchase segment: cancel rate data confirmed stockout collision risk was within acceptable range
Technical Detail
Our customer base turned over frequently: nail products weekly, skincare on short reorder cycles. Holding inventory pre-confirmation would have degraded the experience for our most loyal buyers. We validated with historical cancel rate data that the risk of a stockout collision (another buyer purchasing the held item before payment cleared) was low enough to accept. We also designed inventory release and order cancellation as a single atomic operation. If handled separately, the gap between cancellation and inventory release creates a phantom inventory state that can cause oversell on high-demand items.
What
3-stage customer touchpoints
Why
Pending is not broken: Japanese consumers are familiar with Konbini flows; silence after an order is the failure mode, not the wait
Technical Detail
The risk wasn't that customers would be confused by the payment method (Konbini is widely understood in Japan). The risk was silence after placing an order. We designed three explicit touchpoints: (1) immediate post-order confirmation with payment instructions and deadline, (2) 24-hour reminder if unpaid, (3) final warning 2 hours before expiry. Each message framed the pending state as intentional and informative. This pattern maps directly to ACH-based payment UX in the US, where delayed confirmation is expected and the PM's job is to make waiting feel designed, not broken.
What
Unique event ID per confirmation webhook
Why
Payment provider webhooks can fire more than once due to retries; a duplicate trigger without idempotency handling double-fulfills an order
Technical Detail
Konbini confirmation signals can be retried by the payment provider on network timeouts or delivery failures. Without idempotency handling, a duplicate confirmation event would trigger a second fulfillment cycle: inventory decremented twice, duplicate shipment created, two finance entries for the same revenue. Each confirmation event was assigned a unique identifier at the provider level; subsequent events with the same ID were silently ignored after first successful processing. This is standard in payments engineering: the PM's role was to specify the requirement explicitly, define the acceptance criteria, and ensure edge case coverage in QA.
What
State-based logic per edge case scenario
Why
Bank transfers rely on customers manually entering amounts; shortfalls are predictable, so defining handling upfront avoids ambiguity at resolution time
Technical Detail
Manual bank transfer creates a class of edge cases that card payments don't have: underpayments, overpayments, and transfers with no order reference. We defined handling logic for each scenario before launch in collaboration with finance: partial payment → notify customer + request remainder within a window, if unresolved → cancel + refund received amount. Overpayment → confirm order + refund excess. Unmatched transfer (no order ID) → amount-based matching attempt, then CS exception workflow. Pre-defining these cases meant no ambiguity at resolution time and no ad-hoc decisions under operational pressure.
What
All payment states mapped to reconciliation events
Why
Finance needs real-time AR visibility: post-launch manual cross-reference creates errors, delays, and audit risk
Technical Detail
Every state transition (pending, confirmed, expired, refunded, partial, overpaid) was mapped to a tagged reconciliation event that finance could query directly. Before this, end-of-month reconciliation required manual cross-reference between order records and bank statements. After mapping, finance could filter by state, drill into any order, and trace the full payment history in real time. Aligning on the event schema at design time (not post-launch) meant the data structure was correct from day one. Retroactively tagging historical records would have been expensive, error-prone, and incomplete.
05 — Domain Connection
Fintech Translation
The design challenge here is identical to core fintech problems: how do you build a reliable, customer-friendly system when payment confirmation isn't instant?
Async flows, settlement latency, idempotent event processing, and reconciliation logic designed here map directly to how fintech products handle ACH transfers and payment failure state management.
This project
Fintech equivalent
Konbini / bank transfer async flow
ACH transfer & delayed settlement
Idempotent webhook handling
Payment retry deduplication
Partial payment edge cases
Payment failure state management
Reconciliation event mapping
Real-time AR & ledger entries
06 — Trade-offs
Key Decisions
No Inventory Hold
Customer LTV > inventory efficiency. High repeat-purchase segment validated with cancel rate data that stockout collision risk was within acceptable range.
Automation + Human Fallback
Full automation breaks edge cases. Full manual doesn't scale. Designed automated happy path with explicit CS exception workflows for partial, expired, and unmatched transfers.
Reconciliation Mapped Upfront
Finance alignment at design time, not post-launch cleanup. Every state transition pre-defined as a reconciliation event, giving real-time AR visibility from day one.
07 — Results
Outcomes
Japan launched on schedule. The payment architecture has held without rework as the platform expanded to additional markets.
+25%
vs. revenue target
3 months post-launch
+30%
vs. penetration target
Japan market share