The checkout screen is a legal document
The checkout screen is the most regulated screen in a food delivery app, and most feature lists treat it as a design problem. That's the thing I'd change first about how people plan these apps.
Here's why. Between July 2024 and January 2026, California rewrote how prices must be shown, New York City rewrote how much platforms can charge restaurants, and New York City again told apps where and how the tip prompt has to appear. None of that is on the typical "must-have features" list you find when you search this topic.
So this is a features article, but every feature comes with the rule that shapes it, checked live on September 30, 2026. Where a rule does not apply (and one famous one does not), I say so.
To be clear, I'm not a lawyer, and nothing here is legal advice. It's what a senior product team needs to know before scoping, so the lawyer conversation starts from the right place.
If you want the broader build picture first, our guide to food and restaurant app development covers scope and platform choices. This piece stays on features.
Features are not a wish list
The usual model is a wish list: copy what DoorDash and Uber Eats ship, sort by how impressive it looks in a demo, build from the top. That model fails in a specific way.
The big platforms ship features that fit their scale. A group ordering tool for 100 people makes sense for Uber for Business; it's a distraction for a regional app with 40 restaurants. Meanwhile the features that carry legal weight, like how fees are itemized, look boring in a demo and get pushed to "phase two."
The better model is a grocery run. You buy what you'll get in trouble for not having (milk for the kids) before what's nice to have (the fancy cheese). In an app, the trouble is legal exposure and disputes. Revenue features come after.
Therefore: rank by exposure first, disputes second, revenue third. I'll show that ranking in a table below, and every feature card says which rule, if any, touches it.
The rules in force today
Five sets of rules shape food delivery features in the US as of September 30, 2026: California's pricing law and its restaurant carve-out, New York City's fee caps, New York City's worker pay and tip laws, San Francisco's fee cap, and Seattle's app worker pay law. One federal rule people expect to apply does not.
California SB 478took effect July 1, 2024. The Attorney General's guidance puts the principle simply: the price a Californian sees should be the price they pay. Mandatory fees go into the displayed price; government taxes like sales tax can stay out.
California SB 1524, signed June 29, 2024, carved restaurants, bars, food concessions, grocery stores and grocery delivery services out of that rule, on condition that any mandatory fee is clearly and conspicuously displayed with an explanation of its purpose. Then it adds the sentence that matters for this article: the exemption does not apply to a third-party food delivery platform, or any other food delivery platform.
The AG's page goes further and says food delivery platforms must advertise the full, all-in price of the delivery service they provide. So a restaurant's own ordering site can show a disclosed service charge; a delivery marketplace serving the same restaurant does not get that carve-out.
New York City's fee capschanged in 2025. The platforms sued the city in 2021; the case settled in 2025, and the Council passed Int. 762-B, enacted May 31, 2025 as Local Law 79 of 2025. It keeps the old caps (15% delivery, 5% basic service, 3% transaction) and adds a separate cap of 20% for optional "enhanced services," but only if the platform also sells a basic tier at the old caps that includes being listed and receiving orders on all its apps and sites.
You'll see a "43% cap" quoted. That's just 15 + 5 + 3 + 20 added up, and it only applies if a restaurant chooses the enhanced tier. The law also requires monthly itemized statements to restaurants, bans forcing price parity across channels, and requires 30 days' notice of fee changes.
New York City's pay and tip rulesare the most concrete. The minimum pay rate for app-based restaurant and grocery delivery workers is $22.13 an hour before tips, from the first pay period on or after April 1, 2026 (a 3.2% inflation adjustment from $21.44). On January 26, 2026, the city's Department of Consumer and Worker Protection announced that Local Laws 123 and 124 had extended the rate to grocery delivery, and Local Laws 107 and 108 now require a tip option before or at checkout with a suggested tip of at least 10% or a custom amount.
San Franciscomade its 15% cap permanent in June 2021. Since January 31, 2023, the cap applies to core delivery service (listing plus delivery), and a platform offering that core option at or below 15% can charge more for extras. Restaurants can terminate with 72 hours' notice, and platforms can't charge for phone calls that didn't produce a sale.
Seattle'sApp-Based Worker Minimum Payment ordinance took effect January 13, 2024. It pays the greater of a per-offer minimum or time plus mileage, and gives workers rights to upfront offer information and receipts. For 2026 the rates are $0.47 a minute, $0.80 a mile and $5.34 per offer, as restated by Amazon Flex from the city's figures.
| Rule | Status on September 30, 2026 | Who it binds | Feature it changes |
|---|---|---|---|
| FTC Rule on Unfair or Deceptive Fees | In force since May 12, 2025 | Live-event tickets and short-term lodging only | None directly for food; general FTC deception law still applies |
| California SB 478 | In force since July 1, 2024 | Most sellers advertising prices to Californians | All-in price display; mandatory fees in the first price shown |
| California SB 1524 | Chaptered June 29, 2024 | Restaurants, bars, grocery stores, grocery delivery services | Carve-out with fee disclosure; expressly excludes third-party food delivery platforms |
| NYC Local Law 79 of 2025 | Enacted May 31, 2025 | Third-party food delivery services charging NYC restaurants | Basic tier at 15% / 5% / 3%, optional enhanced tier up to 20%, monthly itemized statements |
| NYC minimum pay rate | $22.13 an hour from April 1, 2026 | Restaurant and grocery delivery apps | Courier pay engine, route and pay disclosure before acceptance |
| NYC Local Laws 107 and 108 | Effective January 26, 2026 | Restaurant and grocery delivery apps | Tip option at or before checkout, suggested tip of at least 10% or custom |
| San Francisco Police Code Article 53 | 15% cap permanent; core-service structure since January 31, 2023 | Third-party food delivery services charging SF restaurants | A core delivery tier at or below 15%; 72-hour termination; no fees on phone calls without a sale |
| Seattle App-Based Worker Minimum Payment | In force since January 13, 2024; 2026 rates $0.47 a minute, $0.80 a mile, $5.34 per offer | Network companies with app-based workers in Seattle | Upfront offer disclosure, receipts, per-offer pay calculation |
How I ranked the ten
The ten features below are ordered by three tests in sequence: legal exposure if you get it wrong, the customer or courier disputes it prevents, and only then revenue. A feature that scores high on the first test outranks one that only scores on the third.
This is a judgment, not a measurement. I haven't found an independent study that ranks delivery features by outcome, and I won't pretend one exists. The table makes the reasoning checkable instead.
| Rank | Feature | Legal exposure | Disputes it prevents | Revenue effect |
|---|---|---|---|---|
| 1 | Itemized all-in fees | High in CA, NYC, SF | High | Protects conversion from surprise totals |
| 2 | Tip flow and tip transparency | High in NYC and Seattle | High | Courier retention |
| 3 | Real-time tracking | Medium (upfront disclosure rules for couriers) | High | Fewer where-is-my-order contacts |
| 4 | Proof of delivery | Low | Very high | Cuts refund leakage |
| 5 | Allergen and dietary labels | Medium (safety, not delivery law) | High | Trust |
| 6 | Substitutions with approval | Low | High for grocery | Order completion |
| 7 | Support, ratings and refunds | Medium | It is the dispute system | Repeat orders |
| 8 | Scheduled ordering | Low | Medium | Smooths kitchen load |
| 9 | Group ordering | Low | Low | Larger baskets |
| 10 | Membership and loyalty | Medium (enrollment and renewal consent) | Low | Recurring revenue |
The 10 features
Each card below says what the feature is, who ships a real version of it, which rule touches it, and what I'd build. The platform examples come from the companies' own help centers and newsroom pages.
Itemized All-In Fees
the first price is the real price
Checkout has to show every fee as its own line with a plain explanation, and in California the first price a customer sees has to include every mandatory fee. This is feature one because it's the only one with a statute behind the display itself.
Under SB 478 as the AG reads it, a delivery platform advertising its delivery service must show the all-in price. SB 1524's softer "disclose it clearly" route is for restaurants, not platforms. If you're building a white-label ordering app for one restaurant group, you may sit on the restaurant side of that line; if you're building a marketplace, you don't.
What I'd build: a fee engine that stores every fee with a type (mandatory or optional), a purpose string, and a jurisdiction flag. The menu, cart and checkout all read from that one engine, so the price shown on the restaurant card and the price charged can never drift apart.
The cost: this is more backend work than a hard-coded service fee, maybe a couple of weeks for a small team. It's cheaper than retrofitting it after a complaint.
Tip Flow and Tip Transparency
where the prompt sits is now law
The tip prompt belongs at or before checkout, with a real suggestion, and every dollar tipped goes to the courier with a record the courier can see. In New York City, that's no longer a design choice.
Local Laws 107 and 108 require restaurant and grocery apps to show a clear tip option before or at checkout, including a suggested tip of at least 10% of the purchase price or a custom amount. The city's notice of rights also says the app must pay workers all tips and show how much the customer tipped for each delivery.
Why so specific? The city's January 2026 announcement alleges that DoorDash and Uber changed their interfaces in ways that lowered workers' tip earnings by $550 million. That's the city's claim, drawn from its own report, not a court finding. But it tells you exactly what regulators are reading: the pixels.
What I'd build: the tip step on the checkout screen, default suggestions starting at 10% or above for NYC addresses, a custom field, and a tip ledger that pays out separately from base pay so a worker's statement shows both.
Real-Time Tracking
the answer to the question customers ask most
Live tracking on a map with honest status steps (accepted, preparing, picked up, arriving) is table stakes, and it has a second job on the courier side: disclosure. Uber's group ordering page even lists tracking arrival as a step of its team order flow.
The courier side is where the rules bite. New York City's notice of rights says that before a worker accepts, the app must show route details including pickup address, estimated time and distance, tip and pay. Seattle's ordinance also gives workers a right to upfront offer information and receipts, and the city's Q&A lists substantially inaccurate upfront information among the reasons a worker can cancel an offer and still be paid.
So the same location and ETA service drives both screens. What I'd build: one dispatch service that computes distance and time once, shows it to the courier before acceptance, stores it, and powers the customer map. When the estimate and the actual diverge a lot, flag it.
Proof of Delivery
a photo that settles the argument
A drop-off photo tied to the order record is the cheapest dispute tool in the whole app. DoorDash's help center says Dashers must submit a clear proof-of-delivery photo before they can complete a delivery, and recommends including a doorway or other surroundings and using flash in the dark.
Pair it with the customer's choice: hand it to me, or leave at the door. The photo matters most for the second.
What I'd build: required photo capture in the courier app for contactless drop-offs, stored with a timestamp and GPS point, visible to the customer and to support. Downside, said plainly: photos can be staged. They reduce disputes; they don't end fraud. Support still needs judgment.
Allergen and Dietary Labels
suggested by software, confirmed by the kitchen
Per-item allergen and dietary labels are a safety feature first, and the restaurant must own their accuracy. DoorDash's merchant help center says its food labels support the top 9 US allergens (wheat, milk, eggs, fish, crustacean shellfish, soybeans, tree nuts, peanuts and sesame) plus dietary tags like vegan and gluten-free.
The detail I like: DoorDash uses machine learning and human review to suggest labels from item names, descriptions and photos, but the merchant must confirm them before they take effect, and is told to review them again if ingredients change.
That's the right boundary. Software may suggest a label; a person at the restaurant must confirm it; the app must never display an unconfirmed suggestion as fact. What I'd build: a confirm step in the merchant tool, a free-text allergy note on the order, and a filter customers can trust because every label behind it was confirmed.
Substitutions With Approval
the grocery feature restaurants now need
When an item is out, the customer should approve the replacement with one tap or take a refund. Instacart's October 16, 2025 shopper post describes the pattern: the shopper scans up to three alternatives, the system recommends the best match, and the customer is notified and can approve or pick another.
Instacart also protects shoppers who follow the recommended or pre-approved replacement, removing sub-5-star ratings tied to those substitutions. That's a nice piece of fairness design: the worker isn't punished for the system's choice.
For restaurants, the same flow covers "we're out of the salmon." What I'd build: per-item customer preferences (substitute, refund, or contact me), a merchant-side out-of-stock toggle, and a refund that posts automatically when nothing is approved.
Support, Ratings and Refunds
the dispute system you design once
In-app support with order-linked evidence and clear refund rules is the backbone every other feature feeds. The photo from feature 4, the substitution record from feature 6 and the tracking log from feature 3 all end up here.
Ratings need care. New York City requires itemized pay statements under Local Law 113, and Seattle gives workers a right to receipts. If a rating can cut a worker's access, you want an audit trail showing why.
What I'd build: a support console that opens on the order timeline, preset refund reasons with limits, an escalation path to a human, and ratings that exclude events outside the worker's control (like a restaurant's late prep).
Scheduled Ordering
the kitchen's favourite feature
Letting customers order for a later time smooths kitchen load and fills slow hours. Uber's group ordering page lists scheduling orders in advance and recurring group orders among its options.
No delivery law I checked regulates scheduling itself. The trap is operational: a scheduled order needs a prep trigger at the right time, and the fee and tip shown at booking must still be the ones charged.
What I'd build: slot selection that respects each restaurant's hours and capacity, a timed release to the kitchen, and price locking at booking so feature 1 still holds a day later.
Group Ordering
bigger baskets, one link
Group ordering lets several people add to one cart through a shared link, with one payer or split payments. Uber for Business describes per-person spending limits, scheduling, recurring orders, individually packaged meals and, at some restaurants, orders for up to 100 people.
It's ninth because it's revenue-only. It prevents no disputes and carries little legal weight, but it complicates everything above it: whose tip, whose allergy note, whose refund?
What I'd build, when the data says office lunches matter: a shared cart with per-guest line items so allergen notes and refunds stay attached to a person, not the whole order.
Membership and Loyalty
recurring revenue with a consent problem
A subscription that waives delivery fees on eligible orders is the standard model. DoorDash's help center lists DashPass at $9.99 a month or $96 a year, with $0 delivery fees and reduced service fees on eligible orders above a subtotal minimum, a free trial for new users, and automatic enrollment into the paid plan afterward. Uber describes Uber One as including $0 delivery fees on eligible Uber Eats orders.
Notice what Uber chose to write on its benefits page: that it never enrolls anyone in Uber One without their consent, and that members can cancel anytime in the app. A company doesn't put that sentence on a marketing page unless enrollment consent is something people ask about.
Both companies publish average savings figures for members. I don't repeat them here, because they're self-reported with no published method.
What I'd build: explicit opt-in, a clear trial end date shown before signup, cancellation inside the app in as few steps as signup, and member pricing that still passes feature 1 (the waived fee shows as waived, not hidden).
What to copy and what to skip
Copy the big platforms' boundaries, not their feature count. The most useful thing in each help page I read wasn't the feature itself; it was the rule sitting behind it.
DoorDash's allergen labels are a good example. The feature is a tag on a menu item. The boundary is that software suggests and the merchant confirms. That boundary is what you copy, because it puts responsibility where the knowledge is: the kitchen knows what's in the sauce, the app doesn't.
Instacart's replacement flow is the same shape. The shopper scans options, the system recommends, the customer approves. Three parties, each doing the part they're best placed to do, and the worker protected from a bad rating caused by the system's own suggestion.
DoorDash's drop-off photo requirement is a boundary too: no photo, no completed delivery. It's blunt, and it works because it's not optional.
What to skip, at least at launch? Anything whose value depends on scale you don't have yet. Group ordering for 100 people. A membership program before you have enough restaurants to make free delivery feel like a benefit. A ride-share cross-promotion when you don't run rides.
Here's an honest downside to my ranking: loyalty programs can drive a lot of repeat ordering, and putting them tenth might leave money on the table for an operator that already has density. If you already run a busy restaurant group with a loyal base, move feature 10 up. The ranking is for a new app, not an established brand.
One more thing worth copying from both DoorDash and Uber: they write the eligibility rules into the benefit. "$0 delivery fee on eligible orders" above a subtotal minimum, at participating stores. That precision is what keeps a membership from turning into a pricing complaint, and it connects straight back to feature 1.
The same app in California
Move the same app to Los Angeles and the courier pay floor from New York City disappears, but the checkout rules get stricter for a platform. That's the part people get backwards.
In New York City, the rules I checked mostly regulate what the platform charges restaurants and pays couriers, plus where the tip prompt sits. In California, SB 478 regulates what the customer sees as the price. A platform that shows a $12 burrito on the restaurant card and adds a mandatory service fee at checkout has a California problem, even if every fee is itemized at the end.
Why does the restaurant next door get to show a disclosed service charge while the platform can't? Because SB 1524 wrote it that way. The carve-out covers restaurants, bars, food concessions, grocery stores and grocery delivery services, and then expressly excludes third-party food delivery platforms. Whether your specific business counts as one is a question for counsel, not a blog post.
The AG's guidance also notes that delivery platforms have separate rules in the Business and Professions Code about how restaurant prices are listed. I didn't analyse those for this piece, so treat them as one more item for your lawyer's list.
The practical design answer is the same in both places: one fee engine that knows which fees are mandatory, shows them in the first price where the law requires it, and itemizes them everywhere. Build it once and switch behaviour by jurisdiction, rather than building two checkouts.
A worked scenario
Here's a scenario, not a client story: we don't have a published food ordering or delivery case study, and I won't invent one. Consider a regional operator launching a delivery app in New York City with its own couriers.
Start with courier pay. At $22.13 an hour before tips, a courier who spends 30 minutes preparing for and making a delivery must earn at least about $11.07 for that time (22.13 divided by 2). Tips sit on top and can't be used to reach that floor, because the rate excludes tips.
Now the restaurant side. On a $40 order under the basic tier, the most the app can charge the restaurant is 15% for delivery ($6.00), 5% for basic service ($2.00) and 3% for the transaction ($1.20): about $9.20 in total. If the restaurant opts into enhanced services, up to 20% more ($8.00) is allowed.
Put those together. Basic-tier revenue from the restaurant is about $9.20; the courier's time costs at least about $11.07. That's a gap of roughly $1.87 per order before customer fees, software, support and refunds. So this operator needs customer-side fees, enhanced-tier merchants, or more deliveries per courier hour to break even.
Which brings us back to feature 1. If those customer fees exist, they must be itemized and, for a California version of the same app, included in the first price shown. The business model and the checkout design are the same decision.
The side nobody demos
The merchant tools are where fee cap laws land in code, and they're the part most founders under-scope. Customers never see them; regulators and restaurants do.
New York City's Local Law 79 requires monthly itemized transaction statements to restaurants and 30 days' notice before fee changes. San Francisco requires contracts to say which services carry which fees, lets restaurants terminate with 72 hours' notice, and requires platforms to keep transaction records for three years.
- Fee tiers stored per restaurant, with the basic tier always available where the law requires it.
- Monthly itemized statements generated from the same ledger that charged the fees.
- Fee change notices with a dated effective time at least 30 days out for NYC restaurants.
- Menu management with allergen confirmation and out-of-stock toggles.
- Scheduled order queue with adjustable prep times.
- Contract termination and data export on request.
This is mostly backend and API work, which is why I'd scope it with the same team building the fee engine. Our API development work usually starts at exactly this ledger, because statements, payouts and checkout all read from it.
What breaks first
The first thing to break in a new delivery app is usually the price shown versus the price charged, and the second is courier pay records. Both are data problems dressed as UI problems.
Price drift between screens
Signal: support tickets saying "the total was higher than the menu." Cause: fees calculated in two places. Fix: one fee engine, and a test that compares the card price, cart and final charge on every release.
Tips mixed into base pay
Signal: couriers can't see per-delivery tips. Cause: one payout number. Fix: separate ledgers. In NYC this is a stated worker right, not a nice-to-have.
Estimates that are wrong in one direction
Signal: couriers decline offers that looked short and ran long. Cause: optimistic ETA. Fix: compare estimated with actual weekly and correct the model, since upfront information is regulated in Seattle and NYC.
Allergen labels no one confirmed
Signal: a label shows on an item the restaurant never reviewed. Fix: labels stay hidden until confirmed, and a menu edit to ingredients forces reconfirmation.
Cost and build order
Build in the same order as the ranking: fee engine and tip flow first, tracking and proof of delivery next, loyalty last. A focused first release with features 1 to 5 is a real product; one with only 8 to 10 is a demo.
We bill senior-led work at $150 to $225 an hour and send a fixed-price phased proposal after discovery. Full source code and IP transfer to you, and there's a 30-day post-launch warranty. I won't quote a total here, because a single restaurant group's ordering app and a three-sided marketplace are different animals.
| Build | What is in it | How we price it |
|---|---|---|
| Single restaurant or group ordering app | Customer app, menu, checkout, tracking via a delivery partner, admin | Discovery first, then a fixed-price phased proposal at $150 to $225 an hour |
| Regional delivery marketplace | Customer, courier and merchant apps, dispatch, payouts, support tooling | Same method, much larger scope; phase it |
| Compliance retrofit on an existing app | Fee itemization, tip flow, pay disclosure, statements | Scoped from an audit of the current checkout and payout code |
For most first launches I'd start with a narrow MVP in one city, built in React Native so the customer and courier apps share one codebase across iOS and Android. Our food and hospitality industry page shows how we approach restaurant clients generally.
If you're comparing agencies, our ranking of food delivery app development companies lays out what we scored and what we left out.
Red flags in a vendor
The clearest red flag is a vendor who cites the FTC junk fee rule as the reason for your checkout design. It tells you they haven't read which industries it covers.
- They quote a single '43% cap' for New York City without explaining the basic and enhanced tiers.
- They can't say whether your app is a restaurant or a third-party food delivery platform under California SB 1524.
- Their tip screen comes after payment confirmation.
- Courier pay and tips come out of one number.
- They promise a ready-made 'DoorDash clone' with every feature and no discovery.
- They quote average platform commissions or 'most diners prefer ordering direct' without a primary source.
That last one deserves a sentence. I looked for a primary source behind the commission percentages and "prefer ordering direct" statistics that circulate in this space and didn't find one I'd print.
What I could not verify
Several things I could not confirm from a primary source, and they're not printed as fact above.
- Current fee cap status in Chicago, Los Angeles and other cities that adopted pandemic-era caps. I didn't verify them, so I don't claim them.
- Seattle's 2026 per-minute, per-mile and per-offer rates come from Amazon Flex restating the city's figures; I read the city's Q&A for the ordinance itself.
- The $550 million tip figure is New York City's allegation from its own report, not a court finding.
- DashPass and Uber One average savings figures are self-reported by the companies, with no published method.
- Current Uber One pricing in the US: I didn't fetch an official page that states it, so I don't print it.
- Average marketplace commission rates and 'prefer ordering direct' percentages: no primary source found.
- Whether a given business is a 'third-party food delivery platform' under California law is a legal question for your counsel.
Three things this week
Do these three this week, before any design work.
- List every city and state you'll launch in, and next to each, write which rows of the rules table apply.
- Screenshot your current or planned checkout and mark where every fee and the tip prompt appear. Check them against California SB 478 and NYC Local Laws 107 and 108.
- Decide whether your fees, tips and courier pay live in one ledger or three. If it's three, that's the first thing to fix.
The siblings in this series apply the same method to other verticals, like the e-commerce features that lift conversion, if you're building a store alongside delivery.
Time to get to work.
Scoping a Food Ordering or Delivery App?
Book a discovery call with Frenchy Digital, a senior-led Black-owned Los Angeles agency. Bring your launch cities and your checkout. You get a fixed-price phased proposal after discovery, full source code ownership and a 30-day post-launch warranty.
Planning a food ordering or delivery app?
Book a discovery call and we will map your checkout, tip flow and payouts against the rules in the cities you serve before anyone writes code.
1517 S Bentley Ave Apt 204, Los Angeles CA 90025
Frequently Asked Questions
Sources & References
- 1FTC: Rule on Unfair or Deceptive Fees announcement↗
- 2California Attorney General: SB 478 hidden fees guidance↗
- 3California Legislature: SB 1524 (Chapter 43, Statutes of 2024)↗
- 4Greenberg Traurig: California junk fee bill SB 1524 becomes law↗
- 5NYC Council: Int. 762-B, enacted as Local Law 79 of 2025↗
- 6Insurance Journal: DoorDash, Grubhub, Uber Eats settle lawsuits against New York City↗
- 7NYC DCWP: Minimum pay rate for delivery workers↗
- 8NYC DCWP: Notice of rights for restaurant delivery workers↗
- 9NYC DCWP: Landmark delivery worker protections take effect (January 26, 2026)↗
- 10Restaurant Dive: San Francisco passes permanent delivery fee cap↗
- 11City of San Francisco: FAQ on delivery service regulations↗
- 12Seattle Office of Labor Standards: App-Based Worker Minimum Payment Q&A↗
- 13Amazon Flex: Seattle ABWMP rates for 2026↗
- 14DoorDash Help: What is DashPass↗
- 15Uber: New benefits for Uber One members↗
- 16Uber for Business: group ordering↗
- 17Instacart: a more straightforward replacements experience↗
- 18DoorDash Help: confirming delivery drop-off photos↗
- 19DoorDash Help: food and store labels in Merchant Portal↗
