Does Toss Need a Delivery App?

May 17, 2026

A few days ago, I was paying at a neighborhood bakery near my home with Toss Pay when a simple question came to mind.

What exactly is Toss trying to build?

At first, the answer seemed obvious. Toss wants more offline payment acceptance. More merchants, more terminals, more transactions. That is the usual fintech interpretation.

But the more I thought about it, the less this looked like a payment story.

It looked like a local commerce infrastructure story.

A payment terminal is not just a terminal if it is connected to POS software. A POS is not just a cash register if it knows products, orders, coupons, customer visits, and inventory. A face-based payment method is not just a faster way to pay if it turns anonymous offline shoppers into identifiable repeat customers. And a pickup order is not just a convenience feature if it turns a neighborhood store into an orderable local node.

This is why Toss is becoming strategically interesting.

The question is not whether Toss will launch a delivery app. Korea already has powerful delivery apps. The more important question is whether Toss can build the operating layer underneath Korean local commerce.

In the U.S., this problem is being attacked by companies such as DoorDash, Toast, Instacart, Shopify, and Nash. But Korea is structurally different. The same strategic logic cannot simply be imported.

That difference is the opportunity.

The U.S. local commerce stack is fragmented

To understand why Toss matters, it helps to start with the U.S.

The U.S. local commerce market is not one integrated system. It is a stack of partially connected layers.

A restaurant may use Toast for POS, DoorDash or Uber Eats for marketplace demand, DoorDash Drive for first-party delivery, Square or Olo for ordering, Shopify for direct commerce, and another provider for local routing or fleet management.

Toast is no longer just a restaurant POS company. Its product surface includes POS, payment processing, mobile order and pay, loyalty, email marketing, gift cards, guest CRM, online ordering, branded mobile apps, delivery services, and third-party delivery integrations. In other words, Toast is trying to become the operating system for restaurants.

DoorDash, meanwhile, is no longer only a consumer-facing delivery marketplace. In 2024, it announced a Commerce Platform for merchants, explicitly aimed at helping merchants operate and grow their businesses on their own channels, both in-store and online. Its platform includes Drive On-Demand, online ordering, branded mobile apps, and business management tools.

DoorDash Drive On-Demand is especially important. It lets merchants offer delivery through their own app, website, or ordering channel, while DoorDash handles delivery execution. DoorDash describes it as a flat-fee delivery service, separate from marketplace commission logic. It also integrates with online ordering and POS providers such as Square, Toast, and Olo.

Instacart is moving in a similar direction from a grocery angle. Storefront Pro is a white-label commerce platform that gives grocers their own branded e-commerce experience while using Instacart’s marketplace infrastructure underneath. Instacart describes this as bringing web, app, in-store, personalization, retail media, and grocery-native fulfillment technology into one platform.

Shopify approaches the same problem from the merchant-owned commerce side. Its local delivery tools let merchants define local delivery zones, pricing rules, delivery radius, and fulfillment workflows; merchants can deliver themselves or use third-party delivery services. Shopify POS also supports in-store pickup workflows, where staff can prepare orders, notify customers, and mark pickup orders as completed.

Then there is Nash.

Nash exists because delivery execution is fragmented. Its platform is designed to route orders across owned fleets, contracted carriers, and gig providers, optimizing for cost, reliability, speed, service level, and fallback options.

Why We Built Nash AI — Source: https://www.nash.ai/blog/why-we-built-nash-ai

This is the American local commerce problem: merchants increasingly want to own their customer relationship, but they do not necessarily own delivery execution. That gap creates the need for orchestration.

The stack is fragmented. Therefore, software companies emerge to connect it.

Korea did not evolve this way

Korea’s local commerce market starts from a different operating history.

Before delivery apps became dominant, Korea already had phone ordering, store-level delivery, neighborhood delivery agencies, and dense motorcycle rider networks. The consumer habit of ordering prepared food to homes and offices was already deeply embedded.

Then Baemin, Yogiyo, and Coupang Eats layered software, payment, discovery, promotion, and logistics coordination on top of that behavior.

Today, Korea’s delivery app market remains concentrated around a few major players. A March 2026 report citing IGAWorks data described the delivery app market as maintaining a three-player structure, with Baemin at 54 percent share, Coupang Eats at 29 percent, and Yogiyo at 10 percent as of February. A separate April 2026 report citing WiseApp·Retail said the four major delivery apps — Baemin, Coupang Eats, Yogiyo, and Ddaengyeoyo — recorded estimated payments of 3.03 trillion won in March 2026.

Korea also has independent delivery agency infrastructure. Barogo describes itself as operating with more than 41,000 delivery riders and more than 1,800 hubs nationwide. Vroong promotes merchant-facing delivery services with one-click delivery request capability from delivery app orders, integrated control-center support, and a nationwide network around major metropolitan areas.

This matters because Korea’s local commerce problem is not the same as the U.S. problem.

In the U.S., a merchant may ask: “I have the customer order. Which delivery provider should I use?”

In Korea, many merchants have been trained by the market to ask a different question: “Which delivery app brings the order?”

That is a major structural difference.

Why Korea did not naturally produce a Nash

Nash-style orchestration makes sense when merchants or platforms must decide between multiple delivery execution options.

Should this order go to an owned driver, a contracted courier, Roadie, Uber, DoorDash, or another local fleet? What happens if one provider fails? How should cost be balanced against speed? How should service levels vary by category?

That is a real problem in the U.S.

But in Korea, the dominant delivery apps already package much of the consumer-facing transaction. For many restaurants, the main operational question is not how to orchestrate between multiple fleets. It is how to survive inside Baemin, Coupang Eats, and Yogiyo while managing commissions, promotions, reviews, and order flow.

This is why Korea has not produced an obvious Nash equivalent at scale.

The need exists, but it appears in a different place.

It does not begin as a broad merchant-side delivery orchestration problem. It begins as a merchant-owned order channel problem.

Before a merchant needs delivery orchestration, the merchant needs direct digital demand.

And this is where Toss becomes strategically interesting.

Toss is not just entering offline payment

Toss Place already looks more like a local commerce operating layer than a simple payment terminal company.

Toss POS can be downloaded across Windows, Android, iOS, and Mac. It supports QR table ordering, delivery app integration with Baemin, Coupang Eats, and Yogiyo, points and coupon issuance, product-level inventory management, sales analytics, order status management, and customized discounts.

That feature set is important. POS is where offline commerce becomes data.

The merchant’s product catalog enters the system. SKU-level sales enter the system. Discounts enter the system. Repeat customers enter the system. Delivery app sales can be connected. Pickup and dine-in orders can be managed in one workflow.

Toss Order extends this further. Toss Place describes Toss Order as a feature that lets customers order by mobile from outside the store and pick up the prepared product. When it launched officially in 2024, it moved from a limited pre-application test into availability for prepaid stores using Toss Place points.

Toss Place’s pickup order product page claims that pickup orders can increase orders by 57 percent and that merchants can use existing POS and kiosk menus for setup. Its order management tools also allow orders from dine-in, takeout, and delivery channels to accumulate in sequence and be handled from the POS screen.

The API layer matters as well. Toss Place’s Order API exposes order information including order history, product information, discount information, order source, order state, timestamps, line items, selected options, and applied discounts.

This is not a small detail. Once order, catalog, payment, discount, and customer interaction data become accessible through APIs, POS becomes a platform surface.

Then FacePay adds identity.

Toss FacePay has expanded rapidly. Aju Press reported in May 2026 that FacePay had reached 4.83 million subscribers and 330,000 offline merchants, and that Toss was linking Toss Place terminals with Toss Payments’ PG infrastructure. The same report said merchants already using Toss terminals can activate FacePay without replacing devices and without additional fees.

Now the strategic question changes.

If Toss knows the merchant, the SKU, the order, the payment, the coupon, the repeat customer, and eventually the customer’s local intent, is this still only payment?

Probably not.

It starts to look like a local commerce graph.

The pickup wedge is more important than delivery

If Toss tries to build a full delivery marketplace, it enters one of the most expensive competitive arenas in Korea.

It would need consumer demand, merchant supply, delivery execution, subsidy budgets, customer service, rider management, and a reason for consumers to open Toss instead of Baemin or Coupang Eats when they are hungry.

That is not impossible, but it is not the most natural path.

The more natural path is pickup.

Pickup does not require Toss to solve the hardest part of delivery execution on day one. It lets Toss start from the assets it already has:

POS penetration
merchant relationship
product catalog
payment
customer identity
coupons and points
order status
repeat purchase behavior
offline proximity

A March 2026 report said Toss Place was strengthening pickup order by allowing even first-time customers to order before visiting, and that Toss Place had added a map-based nearby store discovery service through changes to its location-based service terms. The same report said Toss Place had more than 300,000 merchants and was targeting 1 million merchants within the year.

This is the real signal.

A pickup order is not merely a pickup order. It is the first step toward making offline merchants searchable, orderable, payable, and repeatable inside a digital interface.

That is local commerce.

Delivery can come later.

The Korean path: from POS to orderable node

The American path to local commerce often begins from delivery.

DoorDash begins from delivery demand and then moves into merchant tools.

Toast begins from restaurant operations and then extends into ordering, payments, loyalty, and delivery services.

Instacart begins from grocery marketplace demand and then turns its infrastructure into white-label retailer software.

Shopify begins from merchant-owned e-commerce and adds local fulfillment options.

Toss may follow a different path:

Start with payment trust.
Enter the merchant through POS and terminals.
Add customer identity through Toss Pay and FacePay.
Add loyalty through points and coupons.
Add orderability through Toss Order and QR/table/pickup flows.
Add local discovery through maps and nearby pickup stores.
Add delivery only when direct merchant demand becomes meaningful enough to require execution routing.

That is not DoorDash.

That is not Toast.

It is closer to a Korean local commerce operating layer, built from finance identity and offline merchant infrastructure rather than from food delivery demand.

Why Toss should not copy DoorDash

The temptation is to ask whether Toss can build a Korean DoorDash.

But that may be the wrong comparison.

DoorDash became powerful because it aggregated consumer demand and delivery execution in a market where local commerce was fragmented. Its newer merchant platform strategy is a second layer built on top of that marketplace and logistics base.

Toss does not have that same origin.

Toss has financial identity, consumer trust, payments, offline merchant infrastructure, and increasingly POS-level operational data.

That gives Toss a different strategic option.

Instead of building a consumer delivery marketplace, Toss can become the infrastructure that lets merchants create direct transactions outside the dominant delivery apps.

This is subtle but important.

The enemy is not necessarily Baemin.

The enemy is unexecuted local intent.

A customer walks near a bakery but does not know the croissant is ready. A worker wants coffee before arriving at the office but does not want to wait in line. A regular customer would reorder if the merchant had a low-friction channel. A small restaurant wants repeat customers without depending entirely on delivery app advertising. A beauty salon, academy, clinic, flower shop, or small retailer wants identifiable customer relationships, not just one-time card payments.

These are not all delivery-app use cases.

They are local commerce use cases.

The execution layer, not the discovery layer

This is where Execution Theory becomes useful.

The previous era of commerce was dominated by discovery. Platforms won by aggregating attention: search, feed, ads, ranking, recommendations, and marketplaces.

But the next advantage increasingly sits in execution: the ability to make a transaction complete under real operating conditions.

In this frame, Toss is not interesting because it can make payment one second faster.

It is interesting because payment can become the identity and execution trigger for local commerce.

FacePay is not just a biometric payment feature. It may be a way to connect offline presence, customer identity, merchant data, and repeat commerce.

POS is not just a merchant tool. It may be the merchant-side execution terminal.

Toss Order is not just pickup. It may be the first consumer-facing order channel for a much larger local commerce network.

The strategic asset is not one product.

It is the connection between them.

The delivery question returns later

This does not mean delivery is irrelevant.

If Toss succeeds in creating merchant-owned demand through pickup, coupons, identity, and local discovery, delivery eventually becomes unavoidable.

Some orders will need to move.

At that point, Toss has three choices.

First, it can ignore delivery and remain a pickup/local order platform.

Second, it can partner with existing delivery agencies such as Barogo, Vroong, or regional operators.

Third, it can build an orchestration layer that routes orders across available delivery options, similar in logic to Nash but adapted to Korea.

The third path is the most ambitious, but it only becomes necessary after Toss creates enough direct order volume.

That is why a Nash comparison is useful but incomplete.

Nash is built for a fragmented delivery-provider environment. Toss would be building from a fragmented merchant-owned demand environment inside a market already dominated by delivery apps.

The problem sequence is different.

In the U.S.:

merchant demand first, delivery orchestration next.

In Korea:

platform demand dominates first, merchant-owned demand must be rebuilt, orchestration comes later.

That difference defines the strategy.

The risks are real

There are several risks.

The first is privacy. Biometric payment can be powerful, but face data is not like a password. It cannot simply be changed if compromised. Toss emphasizes security and regulatory review, but consumer trust will remain a strategic constraint as FacePay scales. Aju Press reported that Toss is the only domestic payment service provider to have passed the Personal Information Protection Commission’s preliminary review for facial recognition payment technology.

The second risk is merchant behavior. Small merchants may like POS tools, coupons, and pickup orders, but they may not want another operational dashboard. Toss must reduce workload, not add another channel to manage.

The third risk is consumer intent. Toss is a daily finance app, but that does not automatically mean users will open Toss to find lunch, coffee, flowers, medicine, or neighborhood services.

The fourth risk is conflict with existing delivery platforms. Toss POS currently integrates with Baemin, Coupang Eats, and Yogiyo. That makes Toss useful to merchants, but it also places Toss inside the operating environment of powerful platforms. If Toss becomes a direct order channel, the relationship may become more complicated.

The fifth risk is execution reliability. Delivery is not software alone. It requires rider availability, weather resilience, customer service, exception handling, refunds, and dispute resolution. Toss should avoid entering this layer too early unless it has a clear operational model.