Payment System Stabilization
An idempotent asynchronous payment architecture and customer recovery workflow that turned failed payments into measurable operational and revenue outcomes.
Primary outcome
Reduced the batch from roughly 3 hours to about 10 minutes and recovered approximately KRW 330M in overdue receivables by February 2025.
The problem
A synchronous bulk-payment process took roughly three hours, exposed duplicate-payment risk, and allowed failed payments to become revenue leakage.
Constraints
- Payment retries had to remain idempotent and auditable.
- The team needed a fast recovery path without destabilizing the subscription service.
- Customer-facing payment recovery required coordination across a small cross-functional team.
Approach and key decisions
- 01
Replaced synchronous bulk processing with a Django and Celery asynchronous queue.
- 02
Added idempotency keys and exponential-backoff Smart Retry to prevent duplicate charges and recover transient failures.
- 03
Built a customer self-service flow for finding and paying overdue balances.
- 04
Coordinated product, design, frontend, backend, and operations around one measurable recovery workflow.
Outcomes
- Reduced batch-payment processing time from roughly three hours to about ten minutes.
- Created duplicate-payment protection and a repeatable recovery path for transient failures.
- Released the overdue-balance self-service flow in roughly two weeks and recovered approximately KRW 330M by February 2025.
Technology and methods
Evidence and disclosure scope
Processing time and recovered receivables are owner-reported portfolio figures. KRW 330M is the cumulative amount reported as of February 2025 and has not been independently audited for this website.
See the full resume context