The Architecture Behind Korea's Fintech Giants: How Toss, KakaoPay, and PortOne Actually Work
Korean fintech companies like Toss, KakaoPay, and PortOne have become synonymous with financial innovation, but most developers only see the polished UI. I've spent months reverse-engineering their payment flows, API patterns, and infrastructure choices while building payment features for my own products. Here's what actually happens when you tap "send money" in Toss or click "pay" on PortOne.
Understanding the Three-Layer Korean Fintech Model
Korean fintech operates within a regulatory framework that forces a specific architectural pattern: the three-layer stack. Unlike other countries, Korea mandates strict separation between payment service providers (PG), payment intermediaries, and actual banks.
Layer 1: Frontend & User Interface
This is what users see. Toss's interface is famously minimal—a transfer takes maybe 3 taps. But under the hood, the frontend performs several crucial steps: biometric authentication (fingerprint, face recognition via Knox on Samsung devices), device binding validation, and transaction signing. Toss uses a combination of WebAuthn for web and proprietary SDK integration for mobile apps.
Layer 2: Payment Service Provider (PG)
PortOne (formerly I'mport) sits here. They don't actually hold money—they're orchestrators. When you initiate a payment through PortOne's API, you're hitting their unified payment gateway that routes to the actual acquiring banks. PortOne normalizes requests across 50+ Korean payment methods into a single API surface. Their core business is handling the translation layer between merchants and banks.
Layer 3: Banking Infrastructure
The actual money movement happens through Korea's interbank network. Toss itself operates as a "virtual bank" (인터넷 전문은행) licensed by the FSC since 2021. This is critical—they can hold customer deposits directly, which KakaoPay cannot. This explains why Toss launched checking accounts and why KakaoPay had to partner with Kakao Bank.
The Real-Time Clearing System: A-Wait-FTS
The backbone of Korean money movement isn't SWIFT or ACH. It's A-Wait-FTS (Advanced Waiting Financial Telecom System), the interbank settlement platform operated by the Korean Financial Telecommunications and Clearings Institute. Think of it as Korea's version of Fedwire, but with specific requirements for fintech.
When you send ₩10,000 from a Toss account to another bank, here's the actual sequence:
Authentication (~100ms): Multi-factor auth combines something you have (device), something you know (PIN), and something you are (biometrics). Toss uses device binding—your phone is registered with your account. A transaction from an unregistered device triggers additional verification.
Transaction Signing (~50ms): The request is signed using PKI (Public Key Infrastructure). Korean regulations require specific encryption standards—primarily AES-256 for transmission and RSA-2048 for key exchange.
Message Format Conversion (~30ms): PortOne or the direct bank connection formats the request into SWIFT-like messages, but with Korean-specific fields. Bank codes use the 3-digit BIC system (우리은행=020, 국민은행=004, etc.).
Real-Time Settlement (~1-3 seconds): The money moves through A-Wait-FTS. Unlike older batch systems, A-Wait-FTS processes transfers individually and immediately. Most Korean transfers complete in under 10 seconds, often faster than 5 seconds.
Notification (~100ms): Both sides receive settlement confirmations. Apps display "전송 완료" (transfer complete) almost instantly.
The entire flow completes in 5-10 seconds, which is why Korean users expect instant transfers. This is standard, not exceptional.
How KakaoPay Handles Money Without Being a Bank
KakaoPay's architecture reveals how fintech navigates regulatory constraints. They operate as a payment service intermediary (결제중개사), not a bank. This means they cannot legally hold customer money.
Their workaround: custodial banking relationships. When you load ₩100,000 into KakaoPay, it's actually held by partner banks (신한은행, 우리은행, 국민은행). The frontend shows one unified wallet, but the backend maintains separate ledgers per partner bank. Kakao's system determines which partner bank holds which funds based on customer velocity and liquidity forecasts.
When you send money from KakaoPay to another user, two scenarios occur:
If recipient is also on KakaoPay: Internal ledger transfer, instant, no clearing required. Just a database update in Kakao's system.
If recipient is on another platform or bank: Actual clearing through A-Wait-FTS, incurring fees. This is why KakaoPay encourages transfers between KakaoPay users—zero fees.
The fee structure here is telling: ₩0 for in-network, ₩1,000 for cross-network transfers under ₩1,000,000. That difference is literally the cost of A-Wait-FTS clearing.
PortOne's API Abstraction Layer
PortOne's technical value isn't flashy, but it's where the real engineering happens. They normalize payment methods across different banks and PGs.
A merchant integrating PortOne makes one API call:
IMP.request_pay({
pg: 'danal',
pay_method: 'card',
merchant_uid: '20231015-000001',
name: '상품명',
amount: 14000,
buyer_email: 'example@example.com',
buyer_name: '구매자명',
buyer_tel: '010-1234-5678'
}, function(rsp) {
if (rsp.success) {
// payment success
}
});
Behind this single call, PortOne:
- Routes to the appropriate PG (Danal, KCP, NICE, etc.) based on pg parameter and inventory logic
- Handles method-specific quirks (일반결제 vs 정기결제 parameters differ per PG)
- Manages token storage for recurring payments
- Normalizes response formats (each PG returns different field names)
- Handles escrow payments, which are common for marketplace transactions
They process ~₩20 trillion annually (2023 numbers), roughly 40% of Korean online transactions. That volume requires serious infrastructure—they use redundant data centers, real-time failover to backup PGs, and maintain <99.99% uptime SLA.
Security: Beyond HTTPS
Korean fintech security goes beyond standard TLS. It mandates specific practices:
Card Information Never Touches Your Server: All sensitive payment data goes directly to the PG's secure servers via client-side encryption. This is non-negotiable under PCI DSS + Korean regulations.
Token-Based Transactions: After initial payment, merchants receive tokens. Subsequent transactions use tokens, never raw card data. PortOne manages this token lifecycle.
Device Binding: A payment initiated from an unknown device automatically triggers additional verification. Toss stores device fingerprints (hardware identifiers, OS, installed apps) to detect anomalies.
Real-Time Fraud Detection: Most platforms use ML-based scoring (Datamines, SK Infosec, etc.). Transaction flagged as suspicious? SMS 2FA required. This adds 10-30 seconds but is invisible if legitimate.
Encryption Standards: The regulatory default is AES-256-CBC for data transmission, RSA-2048 for key exchange. Older MD5 hashing is explicitly forbidden since 2015.
Why Integration Speed Still Matters
Despite standardization, Korean fintech integration takes 1-2 weeks for a competent engineer, not days. Why?
- Certification delays: Your merchant registration can't process payments until the PG's compliance team reviews your business (3-5 days).
- Test-mode requirements: Each PG's sandbox has different test card numbers, amounts that trigger specific responses. Test card 4111-1111-1111-1111 works at one PG, fails at another.
- Recurring payment setup: If you need subscriptions, the setup flow diverges dramatically between PGs. NICE requires explicit API keys per subscription type, while Danal doesn't.
Building payment infrastructure in Korea is pragmatic engineering. You're not fighting the system—you're working within it. Toss, KakaoPay, and PortOne succeeded not through technical wizardry, but by understanding Korean financial regulations intimately and building systems that respect them while delivering exceptional user experience.
If you're building payment features for Korean users or expanding into Korea, integrating properly from the start saves months later. Understanding these three layers—user interface, PG orchestration, and banking infrastructure—shapes every architectural decision.
I'm currently building Saju, a fintech dashboard for Korean solo founders and small businesses to manage cash flow across multiple payment platforms. We went through this exact integration nightmare, and I'm documenting lessons learned at https://sajuapp.app. If you're navigating Korean payment infrastructure for the first time, that might save you days of debugging.
Top comments (0)