What one OTP really costs in Korea: KakaoTalk AlimTalk vs SMS

When teams compare ways to send verification codes in Korea, they usually compare the price of one message. That number matters, but it is only one part of what a code costs you. This post walks through the other parts: what happens when a message does not arrive, and the code that turns "send a message" into "verify a phone number". It also covers how a phone OTP differs from Korean mobile identity verification, which has a different cost structure.

The message itself: AlimTalk and SMS

There are two common ways to get a code onto a Korean phone:

• KakaoTalk AlimTalk: an informational message from a business's KakaoTalk channel, sent from a template reviewed in advance. It arrives in KakaoTalk, which is where many Korean users already read their messages.
• SMS: a text message from a sender number. In Korea, the sender number has to be registered in advance.

Korean messaging providers publish per-message prices of roughly ten to a few tens of won, excluding VAT, with discounts at higher volumes. AlimTalk is often priced below SMS. Prices differ between providers and change over time, so check current lists before you decide.

If you send AlimTalk yourself, there is setup before the first message: a KakaoTalk channel, a sender profile with a messaging provider, and templates that pass review. If you send SMS yourself, you register a sender number.

When the message does not arrive

AlimTalk is not delivered to everyone: a recipient may not use KakaoTalk, or a message may fail for other reasons. A login screen cannot simply stop there, so most setups send the code again by SMS when AlimTalk fails.

With a messaging provider, that fallback SMS is a second message and is usually billed at the SMS price. Your real per-code cost is then a blend: the AlimTalk price for most users plus the SMS price for the share that falls back. Users who never get a code also cost you: they retry, they contact support, or they leave the sign-up.

The code you build around the message

A message API sends text. Verifying a phone number needs more than that, and each of these is code you write, test and keep running:

1. Code generation and storage. A random 6-digit code from a secure random source, stored as a hash rather than in plain text.
2. Expiry and attempt limits. A code that works for a few minutes and locks after a few wrong tries, so it cannot be guessed.
3. Replacement. When the user asks for a new code, the old one must stop working.
4. Idempotency. When your request times out, you do not know whether the message went out. Retrying blindly can send a second message and pay for it twice; never retrying leaves users without a code. You need a key per send attempt and a way to replay the first result.
5. Rate limits. Limits per phone number, per IP and per key, so a script cannot use your sign-up form to send messages in bulk at your expense.
6. Delivery tracking. Knowing whether a code was delivered, failed or is still unknown, to decide what the user sees and when to offer a resend.
7. Personal data. Phone numbers in logs, databases and provider records, and how long you keep them.
8. Testing. A way to run the whole flow in CI without sending real messages.

None of this is hard on its own, but it is easily a few days to build properly and some ongoing attention after that. A bug in steps 4 or 5 shows up directly on your messaging bill.

A fair way to compare

Instead of the price of one message, compare the cost of one completed verification:

• the message price, blended across AlimTalk and fallback SMS,
• plus messages that bought nothing (duplicates from retries, abuse that slipped through, codes that never arrived),
• plus the engineering time to build and maintain the parts above, spread over your volume.

At very high volume, with the logic already built and a messaging contract in place, the per-message price dominates and a direct provider contract can be the cheaper choice. At small and medium volume, or when you would rather not build and maintain the OTP logic yourself, the other two lines matter more.

Not the same as identity verification

Checks that use a phone come in two kinds, and they confirm different things.

Mobile identity verification (휴대폰 본인확인) is one of the methods for confirming who someone is without using their resident registration number. Under Article 23-3 of the Network Act, only identity verification agencies (본인확인기관) designated by Korea's communications regulator (방송미디어통신위원회) may provide it, and designated mobile carriers are among them (Article 23-2 of the same Act). According to KISA's identity verification portal, 23 agencies were designated as of June 2026. After a check, the service receives result data such as name and date of birth, plus connecting information (CI) and duplicate-registration information (DI) (glossary).

A phone OTP from K-OTP confirms that the user can receive a code sent to that phone number, that is, that they are using it now. It neither collects nor returns real-name data such as name, date of birth or CI. K-OTP is not an identity verification agency, and a verified code is not identity verification.

• What it proves: identity verification proves who the user is and returns result data with CI and DI; a phone OTP proves the number reaches them and returns only whether the code was verified.
• Setup and cost: KISA's guide for businesses has you decide whether you need it, choose a method and sign a contract with an agency; fees and terms come from that contract. K-OTP needs an API key and costs 1 credit per send.
• Personal data: store only the result data you need, with consent, and delete it once its purpose is met (same guide). A service that receives CI must also keep it separate from resident registration numbers and protect it (Article 23-6 of the Network Act).
• User flow: in the mobile method KISA describes, the user enters their phone details in a verification window, then types a code from a text message or confirms in an app with a fingerprint or PIN. With a phone OTP, they enter their number and the 6-digit code from KakaoTalk.

When a law requires identity or age verification, use the methods it specifies. A phone OTP confirms neither age nor identity, so on its own it does not meet such a requirement. For example, anyone providing media harmful to minors must check the other party's age and identity (Youth Protection Act, Article 16), and online games within the scope set by the Enforcement Decree must confirm real name and age at sign-up (Game Industry Promotion Act, Article 12-3). Financial institutions must verify a customer's identity, for example when opening a new account (Specified Financial Transaction Information Act, Article 5-2). Collecting resident registration numbers yourself is allowed only in limited cases, such as when a law provides for it; and even then users must be able to sign up on a website without one (Personal Information Protection Act, Article 24-2).

When you only need to know that the person really uses the number, as in sign-up and login, confirming contact details, a second step before a sensitive action, or keeping out unused or borrowed numbers, a phone OTP can be enough. KISA's guide for businesses also advises against asking for identity verification you do not need. Many services use both: identity verification once at sign-up where the law requires it, and a phone OTP for later logins or a change of number.

Whether your service needs identity verification depends on your industry and what you offer. This post is not legal advice; check the applicable law and the responsible authority for your case.

How K-OTP prices a send

K-OTP is an OTP API: you call issue with a phone number and verify with the code the user typed. Codes are delivered by KakaoTalk AlimTalk. If AlimTalk cannot deliver a code, K-OTP sends the same code by SMS automatically; this fallback is part of the AlimTalk send, not a separate product.

• 1 credit per send, fallback included. A send costs 1 credit whether AlimTalk delivers the code or the SMS fallback does. Verify calls are free.
• No double charge on retries. Retrying with the same idempotency key returns the first result without sending or charging again.
• Failures are returned. A send the messaging provider does not accept releases its credit. If delivery is confirmed as failed, or no delivery result arrives within the tracking window, the credit is returned, unless the code was verified (which proves it arrived).
• The OTP logic is included. Code generation, hashing, expiry (3 minutes by default), attempt limits (5 by default), replacement, idempotency, rate limits and delivery tracking are part of the API.
• Free test mode. sk_test_ and pk_test_ keys send nothing and use no credits.

Credits come in prepaid packs with no subscription. As of October 24, 2026 the packs work out to about $0.0128 to $0.0196 per credit, excluding tax; the pricing page has the current packs and prices, and how credits are reserved, debited and returned is described in Credits and billing.

Summary

• The per-message price is real, but it is not the whole cost of a verification code.
• Fallback to SMS, failed and duplicate sends, abuse, and the logic around the message all add to it.
• Compare the cost per completed verification, including your own engineering time.
• A phone OTP confirms that the user is using the number; mobile identity verification confirms who they are. Where a law requires identity verification, a phone OTP alone does not meet it.

If you want to see what the integration looks like, the quickstart takes two API calls, and test keys let you try the whole flow for free.