Delivery Hero-style Multi-Market Delivery — Custom-Built for Your Market

One country’s fee change must not rewrite another country’s orders

A country manager updates a delivery fee while a neighboring market is closing yesterday’s merchant settlement. The new fee should affect eligible future orders in the intended country; it should not change the other market’s checkout or yesterday’s deductions. A Delivery Hero-style multi-market delivery platform earns its usefulness at that boundary: shared capabilities, local ownership and evidence that each change reached only the intended operation.

The buyer brief is an independently branded marketplace for groups coordinating regional merchants, fleets and customer service. Country brands may share ordering software while using different catalogs, policies and collecting entities. The reference name describes an operating category. It supplies no affiliation, inherited merchant network, existing riders, proprietary software or permission to operate under another company’s brand. Start by defining the countries and responsible entities you can actually support.

Build a country operating matrix before a global dashboard

Put each launch market on a row with its brand, legal entity, language, currency, customer support owner, merchant agreement and delivery responsibility. Name which decisions belong to the group and which require a country approver. A shared dashboard without this matrix can make an administrator appear authorized to change prices or issue refunds wherever an order is visible. Specify read access and action authority separately, including any approved group oversight role.

The Delivery Hero company overview describes a network of local brands and the roles of restaurants, vendors and riders. That is the category reference for this brief; the configuration and operating recommendations here are proposed requirements for your own organization, rather than a claim about Delivery Hero’s internal implementation.

Give central configuration a controlled local override

Treat a shared checkout or order lifecycle as a product capability, then make country rules explicit inputs. Local overrides might cover supported fulfillment modes, eligible item categories, fee labels, opening calendars and address requirements. Avoid a growing collection of invisible exceptions that only the original developer can explain. An operator should be able to see the effective settings for an outlet and why they differ from the group default.

Preview a change against representative orders before publication. Record its author, approver, intended markets, effective time and previous version. Decide which settings attach to an order at checkout and which remain live operational inputs, such as a temporary service-zone closure. Rollback should restore approved configuration for new activity while preserving the policy snapshots already attached to accepted orders.

Localize catalogs and checkout beyond translated labels

An outlet belongs to a market, service area and operating agreement. Its menu needs local item names, options, availability, prices and the information required by the agreed food policy. A centrally maintained merchant group may have multiple outlets, but an item eligible in one country should not automatically appear in another. Define who approves catalog changes and how a point-of-sale update reaches the customer-facing listing.

Test the full checkout in the actual language and address format, including validation messages, receipts, support contact and cancellation explanation. State whether an amount includes or excludes the reviewed tax components. Show delivery responsibility and the fee breakdown before commitment. If a customer changes country or location, re-evaluate catalog and service eligibility; carrying an old basket into a different market needs an explicit resolution.

Keep currency and tax decisions attached to the transaction

Store monetary amounts with their currency and the agreed precision. Define rounding at line item, discount, fee and final total boundaries, then use the same calculation evidence in the receipt and merchant settlement. A country switch must not simply relabel a numeric balance. Where group reports convert amounts, identify the reporting currency, conversion source and observation time separately from the original financial record.

The Stripe currency documentation distinguishes presentment currency from settlement currency and documents minor-unit formatting. This is a concrete integration concern to verify with the selected local provider, not an assumption that Stripe or any single account supports your launch countries. Have qualified owners review the applicable tax treatment and invoice obligations; configurable fields do not establish legal approval.

Separate collecting accounts from merchant settlement authority

Name the entity collecting the customer payment and the entity owing the merchant. For every market, map order proceeds, commission, promotion funding, refunds, disputes and payout timing to an agreed ledger treatment. A merchant statement should explain deductions and hold reasons at order level. Keep a settlement preview distinct from an approved payout and a provider-confirmed transfer; a positive dashboard balance alone proves none of those events.

Restrict approval and export permissions to the intended financial boundary. Rehearse an outlet with similar identifiers in two countries and verify that an export, refund or settlement action cannot cross into the wrong entity. Assign ownership for a missing callback or mismatched bank result. Reconcile against provider records before retrying an uncertain transfer, and retain the approval evidence needed to explain a later merchant dispute.

Choose fleet ownership before choosing dispatch screens

A platform-managed fleet, merchant delivery team and third-party logistics partner require different assignment authority. Specify who accepts a job, who can reassign it, who records completion and who responds when nobody acknowledges pickup. Country rules may allow only some models in certain zones. An attractive map with rider markers cannot settle these responsibilities; it needs an order-to-assignment trace with the relevant partner acknowledgement.

Model preparation load and delivery capacity as separate constraints. A merchant may accept more food orders than the eligible local fleet can carry. Show the effect of pausing intake, extending a quoted window or declining fulfillment according to the reviewed policy. Keep courier safety and applicable worker, insurance and transport requirements in the country review. Do not turn a target delivery window into a universal guarantee.

Expose local payment failures without losing the order

Define the accepted local payment methods with confirmed provider and entity access. Some methods can acknowledge payment after the customer leaves checkout. Give each order a clear pending, confirmed, failed or unresolved payment state and define when merchant preparation may begin. Deduplicate callbacks using the provider identifier and market context so a retry cannot create another order or settle a neighboring market’s transaction.

A network timeout can hide a successful payment. Let operations investigate the provider record before requesting another charge. Explain to the customer whether the order is awaiting confirmation or has been cancelled, and coordinate the refund route when food has already been prepared. The acceptance pack should include delayed confirmation, duplicate callbacks and a provider outage with a named local owner and recovery procedure.

Route support and incidents through country accountability

A food complaint, unavailable courier and disputed refund need different responders. Keep the country, outlet, fulfillment owner, payment state and relevant customer communication together in the support record. Country agents should see the minimum context required for their task; group escalation should use authorized access and redacted evidence where appropriate. Define which incidents require immediate intake suspension and who can approve reopening.

Provide a market pause with a readable reason and a defined effect on discovery, new checkout, accepted orders and settlement work. A payment outage in one country should have a local response unless evidence shows a shared dependency is affected. Preserve the incident timeline and decision history. Agree privacy, retention, cross-border data handling and customer communications with responsible reviewers for the actual jurisdictions involved.

Measure markets with comparable definitions and local detail

Compare accepted orders, merchant rejection, unassigned work, unresolved payments, completed delivery and refund outcomes using agreed event definitions. A country with merchant delivery may emit different partner events from a platform fleet market; label the difference instead of presenting both as identical coverage. Report original currency totals and explain any group conversion, including missing data and the reporting window.

Model platform revenue separately from gross basket value, courier costs, provider charges, support costs and promotional funding. Commission agreements and delivery fees can differ by country, so a blended group margin may hide a failing local operation. Use the report to identify the specific capacity or reconciliation problem before adding automation. This brief offers a measurement design, not operating benchmarks or a revenue forecast.

Prove isolation and rollback in a connected buyer walkthrough

Buyer acceptance should demonstrate two sample markets with different currencies, permissions and fulfillment rules. Change a local fee, attempt unauthorized cross-country access, deliver a duplicate payment callback and pause only one market. Inspect an order’s policy snapshot and merchant settlement preview afterward. Rehearse a fleet rejection and an unknown payout outcome so the buyer can see the responsible desk and recovery evidence.

Illustrative screens and sample balances explain intended surfaces; they do not prove provider access, deployment readiness or live fleet coverage. Request a connected demonstration with sandbox integrations clearly identified and unavailable functions recorded. The evidence pack should name the tested environment, scenario results, unresolved dependencies and accountable owners. Acceptance becomes reviewable when the buyer can trace an order through configuration, payment, delivery and settlement.

Roll out countries through separate readiness gates

Begin with the agreed markets and complete their operating loops before adding more countries or convenience retail. A new country needs its own provider access, localized content, policy review, support coverage, merchant terms and financial reconciliation checks. Reusing software can reduce repeat engineering; it does not transfer the first country’s permissions or operating readiness. Keep later fulfillment formats in a separate scope when inventory or restricted-item handling changes.

For a narrower restaurant marketplace, compare the Uber Eats-style delivery brief. This multi-market brief adds group configuration governance and country financial boundaries to the local delivery loop.

Use the delivery process to agree the operating matrix, demonstration evidence, acceptance cases and handover responsibilities before a country rollout is scheduled.

Bring the intended countries, entities and fulfillment models to a scope review. We can then define the smallest complete release and estimate against confirmed integration dependencies, with local review and unavailable demo capabilities recorded explicitly.