Primary topic Apps vs Web
South Korea’s app-market regulator has ordered Google and Apple to change practices that it says restrict developers’ payment choices, while also fining the companies a combined KRW 63.71 billion. The important part for mobile product teams is not the fines themselves. It is the distinction the decision draws between a nominal choice of payment processor and a purchase path that developers can realistically use.
On October 28, the Korea Media and Communications Commission, or KMCC, said Google and Apple had violated the country’s Telecommunications Business Act by effectively forcing particular payment methods, unfairly delaying some app reviews and, in Apple’s case, historically applying commissions differently to domestic and overseas developers. The regulator imposed a KRW 42.9 billion penalty on Google and KRW 20.81 billion on Apple and ordered both companies to improve relevant business procedures. The KMCC’s English-language announcement describes this as the first enforcement action under the 2021 amendments that added specific prohibitions for app-market operators.
For a publisher or app developer, however, “external payment” can describe several very different technical experiences. A developer might process payment with another provider while the customer remains inside the native app. The app might show a web checkout inside an embedded browser view. Or it might send the customer into the device’s normal browser to complete a purchase on the developer’s website. Those flows differ in implementation, platform rules, user experience, fees and responsibility for support.
The Korean decision should therefore not be read as a switch that suddenly enables every app to put a “Buy on our website” button wherever it wants. Current Google Play and App Store documentation still imposes region-specific rules, and some of the policies announced for South Korea have not yet reached their scheduled rollout dates.
Why the regulator rejected payment choice that existed mostly on paper
KMCC’s finding focuses on the difference between offering another payment mechanism in theory and making it a practical alternative.
According to the commission, Google and Apple had allowed their own in-app purchasing systems and third-party payment systems implemented by developers, but restricted other mechanisms such as external payments. KMCC also singled out arrangements under which developers choosing third-party in-app payment could still face a 26% commission while taking on additional work and costs themselves.
The commission said the two companies imposed conditions that reduced the usefulness of those alternatives. It cited Google restrictions involving the display of prices by payment method and Apple’s requirement for a separate app submission. Combined with the developer’s own payment-processing, settlement and engineering costs, KMCC concluded that these conditions could have the practical effect of steering developers back toward the platform’s own in-app purchase system.
That 26% figure needs careful interpretation. It describes the arrangements criticized in the enforcement decision; it is not a new commission that KMCC has ordered developers to pay for web checkout. The regulator’s release does not establish a new web-payment fee percentage, nor does it announce a deadline by which every external-link purchase flow must become available.
Third-party billing inside an app is not the same as buying on a website
This distinction is particularly clear in Apple’s current South Korean documentation.
Apple’s existing StoreKit External Purchase program for South Korea lets an eligible developer use another payment service provider for purchases inside an iOS or iPadOS app. But the developer must request an entitlement, submit a separate binary distributed only through the South Korean App Store and follow Apple’s required StoreKit flow.
The current documentation lists KCP, Inicis, Toss and NICE as pre-approved payment service providers, although Apple says another provider can be submitted for consideration. The entitlement is tied to a South Korea-specific app binary and cannot currently be used in that same app alongside Apple’s own in-app purchase system.
Most importantly for an app-to-web strategy, Apple’s documented Korean flow is primarily a third-party in-app payment flow. Apple says it must provide a native experience and may not run inside a web view. The customer may leave the app only when doing so is legally required to complete the purchase on a website or in another app.
That is very different from a general-purpose button that sends a customer to a conventional mobile checkout page in Safari.
Apple also requires a disclosure before the external payment flow. The notice tells users that purchases will be handled by the developer rather than Apple and that App Store features such as Apple-managed subscription management, Ask to Buy, Family Sharing and Apple-handled refund requests will not be available for those transactions.
The practical consequence is that changing the payment processor changes more than the checkout screen. It can move responsibility for subscription management, refunds, payment support, fraud handling and transaction records from the app store to the developer.
Google already documents a web-based option in South Korea, but it has specific constraints
Google Play’s current South Korean rules expose a somewhat different path.
Google says in its South Korea alternative-billing documentation that developers can offer an alternative billing system alongside Google Play Billing to mobile and tablet users in the country. Developers must enroll through Play Console, integrate Google’s alternative-billing APIs, meet trust and safety requirements and report authorized alternative transactions to Google within 24 hours.
The same documentation explicitly addresses web payments. Google says developers can link out within an app to present web-based payment as an alternative for South Korean users. However, its currently documented implementation requires that web payment option to be presented inside the app through an embedded web view rather than simply opening an unrestricted external browser flow.
So even though the checkout uses web technology, the user journey is still governed by the app-distribution program. From a product architecture perspective, that is closer to “web checkout embedded in an app-controlled purchase flow” than to “the app sends the user to the ordinary ecommerce site.”
Google’s present Korean program also retains a Play service fee. Its documentation says that when the user chooses alternative billing, the developer’s applicable Play service fee is reduced by four percentage points compared with the fee for the equivalent Google Play Billing transaction.
That, again, should not be confused with the 26% figure in KMCC’s enforcement announcement. The regulator was describing the conditions it investigated. Google’s currently published developer rules describe the program developers can actually enroll in today.
Google has announced another fee model for Korea, but it is not in force yet
There is an additional timing complication for teams planning changes now.
In March 2026, Google announced a broader restructuring of Play service fees and billing choice. Its current lower service fee documentation says the model is being introduced region by region rather than globally at once.
South Korea is scheduled for December 31, 2026. As of October 31, that date is still in the future.
Under the announced model, Google says service fees will apply whether a qualifying transaction uses Google Play Billing, alternative billing or an external web link, with different rates depending in part on whether the relevant Play install is considered new or existing. Google’s documentation also notes that details of the external-web-link program are still to be supplied for parts of this rollout.
That means a team making a Korean checkout decision today has to separate three states:
- What is available now: the existing South Korean alternative-billing program and its current implementation and reporting rules.
- What Google has announced: a broader billing-choice and service-fee model scheduled to reach South Korea on December 31, 2026.
- What KMCC has ordered: corrective changes to practices that the regulator found unlawfully restricted payment choice.
Those are related developments, but they are not interchangeable.
Apple’s present Korean program also still charges 26%
Apple’s current developer documentation shows why teams should verify live platform rules instead of assuming that the regulator’s order has already rewritten commercial terms.
Under Apple’s existing South Korea third-party payment entitlement, Apple says it charges a 26% commission on the price paid by the user, gross of value-added tax. Developers must report qualifying sales to Apple monthly and remain responsible for their own payment provider and customer support.
This is the same general arrangement that KMCC criticized when explaining why merely permitting third-party in-app processing did not necessarily provide meaningful payment choice.
The October 28 enforcement announcement says Apple has separately described voluntary improvements to the Korean app-market transaction environment, but KMCC’s release does not give enough implementation detail to treat those improvements as a new production-ready checkout policy. A team should therefore rely on the developer terms and entitlements that Apple has actually published for South Korea, then re-check them as Apple implements any changes resulting from the order.
An app-to-web checkout needs more than permission to show a link
For product teams, the technical question is usually framed too narrowly: “Are we allowed to send users to the web?” The more useful question is: “Can the user move from the app to a web transaction and back to a working account without losing context, trust or subscription state?”
A viable app-to-web flow has several independent pieces.
Identity must survive the channel change
If the user is signed into the app, the website needs a reliable way to identify the same account without creating an insecure token handoff or forcing the customer through an unexpected registration loop. A web payment that lands on the wrong account can be worse than no alternative payment option at all.
The purchase has to unlock the correct entitlement
A successful card authorization is not the end of the transaction. The developer’s backend needs to grant the purchased subscription, credits or digital feature to the account that the app will use. The app then needs a dependable way to refresh that entitlement.
This is especially important when one product can be purchased through several billing systems. The backend, not the visual checkout button, becomes the place where those parallel purchase histories have to converge.
Subscription management moves somewhere visible
If the platform no longer manages the transaction, users need a clear place to update a payment method, cancel, see renewal terms and request support. Both Apple and Google warn that alternative billing can remove some store-managed purchase features.
That changes UX copy inside the app. A “Manage subscription” control cannot blindly open the App Store or Google Play if the account might instead be billed directly by the developer.
Refunds and customer service must follow the payment path
A customer usually does not care which billing architecture a product team chose. The customer only knows that money was charged.
If some purchases are handled by Apple, some by Google and some by a developer’s web payment provider, support systems need to identify the transaction owner quickly. Otherwise, payment choice creates a support maze in which the app store sends the customer to the developer and the developer sends the customer back to the store.
Do not assume a normal website link and an embedded web checkout are equivalent
From a web-development perspective, both may ultimately render HTML, but the operational differences are substantial.
An embedded web view lives inside the native app’s process and navigation. It can be constrained by platform requirements, app-review rules and a platform-defined disclosure flow. A purchase opened in the device’s normal browser behaves more like an independent web session: it can use normal browser navigation, existing website authentication, saved web credentials and other browser capabilities.
Those differences affect analytics as well. A product team measuring an app-to-web funnel has to distinguish at least the app CTA, successful arrival at checkout, authenticated account, payment completion and successful entitlement delivery back to the app. Treating all of that as one “checkout conversion” obscures where users are actually dropping out.
It also matters for accessibility and reliability. A responsive checkout page that works well in Chrome or Safari is not automatically proven to work correctly in every embedded web view configuration a store program may require.
The app-review portion of the decision matters to release planning too
Payments were not the only issue in KMCC’s ruling.
The commission also found that both Google and Apple had unfairly delayed some app reviews by failing to provide sufficiently specific reasons for delays or clear answers about expected schedules when developers asked about them.
That matters because a new payment architecture often requires a new app submission, new entitlement configuration or both. Apple’s current Korean alternative-payment program, for example, requires a separate South Korea-only binary and review. Its own documentation notes that an incomplete submission or a payment provider that has not already been approved can delay review or result in rejection.
KMCC has ordered improvements to review procedures, but teams should not translate that into an assumption of instant or guaranteed approval. The practical change to watch is whether the stores provide clearer, more predictable review handling as they respond to the order.
Apple’s historical commission issue is a separate finding
The Korean decision also includes an Apple-specific violation that should not be mixed into the current external-payment debate.
KMCC found that from July 2015 through January 2023 Apple calculated its 30% commission differently for Korean and overseas developers. According to the regulator, overseas developers were charged based on the consumer price excluding value-added tax, while domestic developers were charged based on the final consumer price including VAT.
KMCC classified that as discriminatory treatment and ordered Apple to prevent a recurrence. It is a historical commission-calculation finding, not a statement that every current Apple transaction in Korea carries a 30% fee and not a new rule for web checkout.
What a team should verify before changing checkout
The Korean ruling makes payment choice more important, but it also makes precise implementation more important. Before shipping an app-to-web or alternative-billing flow, a team should verify the live rules for the exact storefront, platform and product rather than extrapolating from a regulatory headline.
- Confirm the user’s storefront and device scope. Google’s Korean rules refer to mobile and tablet users; Apple’s existing entitlement is specifically for iOS and iPadOS apps in the South Korean App Store.
- Identify the actual permitted flow. Determine whether the current program allows native third-party billing, an embedded web checkout, a link into the external browser, or some combination.
- Check whether platform billing must remain available. Current programs differ on whether the developer can combine the store’s payment system with another payment method.
- Verify current fees, not headline percentages. Google has a Korean model in effect now and another scheduled for December 31. Apple’s currently published Korean third-party payment entitlement still specifies a 26% commission.
- Map transaction reporting requirements. Alternative payments can still require reporting to the app marketplace even when the marketplace did not process the card payment.
- Test account, entitlement and cancellation flows. Payment completion is useful only if the customer can immediately use and later manage what was purchased.
- Plan customer support ownership. The developer may become responsible for refunds, subscription management and payment disputes that the store previously handled.
- Re-check policies before release. The October 28 order requires corrective changes, and Google already has a Korean policy transition scheduled for the end of 2026.
Payment choice is becoming a systems question, not just a checkout question
The South Korean decision is significant because the regulator is challenging not merely whether a button labeled “alternative payment” exists, but whether the commercial and procedural conditions around it leave developers with meaningful choice.
For mobile-web teams, that shifts attention toward the entire transaction path. A website can become the checkout layer for an app, but only when store rules permit the particular handoff and the developer has built the surrounding account, entitlement, support and reporting systems.
Google’s current Korean policy already recognizes a web-based payment path, albeit with a specifically controlled in-app web experience. Apple’s current Korean alternative-payment program remains structured around an approved third-party payment provider inside a South Korea-only app binary. Meanwhile, regulatory orders and already announced platform changes may alter those arrangements again.
The safest conclusion on October 31 is therefore not that Korean apps can now freely bypass app-store billing. It is that South Korea is pushing the platforms toward more substantive payment choice, while the exact app-to-web path still depends on the developer rules that are actually in force when a team ships.