Delivery App Promo Codes: What the Terms Say and How to Test Your Own Offers

A customer signs up with a new email, fills a cart, enters one of those delivery app promo codes, and the app answers that the "new customer" discount has "already been redeemed."

Sometimes the customer really is new. A partner may have used the offer at the same address last year. The laptop might be shared. The phone might be secondhand. Often the offer is simply doing what its terms say it does: it is meant for one person's first order.

We build JustBrowser, a multi-account browser for teams, so we work every day with the signals websites use to recognise devices: canvas hashes, WebGL renderer strings, font lists, timezone and screen data. Delivery apps aren't our usual lane, but the recognition logic is the same family, and it explains that error message better than a support macro does.

This post has two audiences. For customers, it explains what delivery app promo code terms say and why a denial happens. For the teams that run a restaurant group's ordering site, a grocery storefront or a delivery app, it covers how to test your own promo-code rules safely, using test accounts you own.

What Delivery App Promo Code Terms Actually Say

Start with the rules, because most of the frustration around delivery app promo codes comes from not knowing them.

First-order and new-customer offers on the big apps (DoorDash, Instacart, Uber Eats, Grubhub and the rest) are generally limited to one per customer. Many go further: one per household, per device, per delivery address, per payment method. Most offers are also non-transferable, can't be stacked with certain other offers, and can be withdrawn or reversed later if the platform decides they were obtained in breach of its terms.

The exact wording changes from offer to offer and country to country, so don't rely on a summary, this one included. Open the offer's own terms, usually linked from the promo banner or the code entry screen, plus the app's main terms of service. Those two documents decide what happens to an order.

The short version: the offer is meant for one person's first experience of the service. Claiming it again under a different account is against the terms, and the rest of this post follows from that.

Why a Genuinely New Account Can Get Denied

A customer who has never used the offer can still be denied. The app isn't really asking "is this email new?" It's asking "is this customer new?" And it answers with whatever it can see.

• Shared delivery address. A roommate, partner or previous tenant redeemed the offer to the same apartment. Household-level limits apply even though you're a different person.
• Shared card. A family card, or a card already on someone else's account. Payment processors can recognise the same card across accounts without storing the number in plain form, so "different account, same card" is an easy match.
• Shared or secondhand device. A family laptop or a used phone may already be associated with another account.
• Recycled phone number. Carriers reassign numbers. Yours may have belonged to an existing customer.

None of that means the customer did anything wrong. It means the check was blunt, and apps could do more to say which rule fired instead of showing a flat "already redeemed."

The most reliable fix is plain: contact support through the app's help section, say you've never ordered before, and explain the overlap. Support can usually see why the offer was blocked, and sometimes applies a different credit instead.

How Delivery Apps Recognise a Returning Customer

This is the part we know well. Think of it as an explainer of the detection side, written for people who build or test promo systems.

There's no single tripwire. Delivery and grocery apps run risk scoring that pulls in many signals at once and weighs how they line up together.

Account and payment signals. Email, phone number, card, billing details, delivery address. Addresses get normalised (so "Apt 4B" and "#4B" match). Cards get matched by a token that represents the card number. These are cheap to check and tied to real-world identity, which is why fraud checks generally lean on them.

Device signals on mobile. Most orders happen in the native apps, and mobile apps can read device and app identifiers that a website can't. What those identifiers are, and how long they last, depends on the operating system and changes as Apple and Google update their privacy rules.

Browser signals on the web. On a desktop checkout, a fingerprinting script reads things like:

Public test pages show how much of this any page can collect, and it is usually more than people expect. If you want the long version of a single signal, our WebGL fingerprinting breakdown and TLS fingerprinting explainer go layer by layer.

Third-party fraud vendors. Companies like Sift, Forter and Kount sell fraud scoring to online merchants, and some of them describe using signals from across their whole customer network. Which delivery app uses which vendor (if any) is rarely public, and plenty of large platforms build their own in-house systems too. The practical effect still matters: a device or card that looks risky on one service can look riskier on another, without the two apps ever sharing a customer list.

Behaviour. Sign-up timing, how fast a promo is applied after sign-up, order patterns, delivery addresses that repeat across "unrelated" accounts. Accounts can also be linked after the fact. A promo that went through last month can still be reversed when the risk model catches up.

The browser fingerprint is rarely the main event. Card, address and phone are cheap to check and hard to change, so fraud systems generally lean on them, and the device layer adds to that picture.

Legitimate Ways to Pay Less

If the goal is cheaper delivery, these are the routes the apps actually want customers to use. Check each one's current terms in your country, because offers and eligibility change.

Subscription plans. DashPass on DoorDash, Uber One on Uber Eats, Instacart+ on Instacart, Grubhub+ on Grubhub. They typically cut delivery fees on eligible orders, and they often come with a free trial. The trial is usually one per person as well. Anyone who orders more than a couple of times a month is better served here than by chasing first-order codes.

Referral programs. Most apps give credit to both sides when you invite a friend who becomes a real new customer. Refer actual people. Referring yourself through a second account is exactly what the programs prohibit.

Business accounts for teams. If the "many accounts" you need are really staff ordering lunch on company money, the platforms have a product for that: DoorDash for Business, Uber Eats through Uber for Business, and Instacart Business. Employees order under a company account with central billing, and some let you set spend limits. Check each product's current features for your country.

One account per real person. Everyone in a household can have their own account. Expect household-level offers to apply once per address.

Ask support. A denied promo on a genuinely new account is a support ticket, not a puzzle.

What Repeat-Offer Abuse Costs

Anyone tempted to claim a new-customer offer a second time should weigh the downside:

1. Accounts get closed, often including the one you actually use, because linking accounts is the whole point of the checks.
2. Credits and promos get reversed after the fact, sometimes along with cancelled orders.
3. Payment methods get blocked. A card flagged on one service can look riskier on others that share a fraud vendor.
4. Chargebacks and disputes go nowhere. If the platform says you breached the terms, disputing the charge with your bank tends to make things worse.
5. Legal exposure at scale. Small cases are generally handled as terms breaches. Using false identities to get goods at scale is a different matter, and depending on where you live it can be treated as fraud. This isn't legal advice; read the terms and ask a lawyer if you're unsure.

The saving is also small: one discount on one meal.

Testing Your Own Promo-Code Rules With Test Profiles

If you run a restaurant group's ordering site, a grocery storefront or a delivery app, the interesting question is the reverse one: do your own rules do what the terms say? That is a QA problem, and it is where a multi-account browser is useful.

A promo engine has several rules that all need testing, and each one needs a session that does not share cookies, storage or saved logins with the last test:

• One per customer. A second order from the same test customer should be refused the new-customer offer.
• One per address. Two separate test customers with the same delivery address should trip the household limit.
• One per payment method. The same test card token on two test accounts should trip the payment limit.
• The false-positive case. A genuinely new customer, with a new address and a new card, must never be blocked. Denying real customers costs more than most of the abuse you are guarding against.
• Region and locale behaviour. Offers, currencies and terms often differ by country, so test each target market.

Run all of it in staging or a test mode with test accounts you own, never against live promotions that real customers are using.

Each JustBrowser profile is its own browser, with its own cookies, storage, proxy and identity parameters, so test sessions don't contaminate each other. A local REST API and CDP let you script the runs with Playwright, Puppeteer or Selenium. Other uses in this space:

• Ad verification across cities. Delivery and grocery brands, and the agencies that buy media for them, need to see what a promo ad or landing page looks like to someone in Austin versus Toronto. Separate profiles with matching locale and a proxy you supply make that check repeatable. Our ad verification workflow walks through it.
• Fraud teams checking their own rules. A risk team can review how its own fingerprinting and scoring behave across distinct, consistent test devices, with sign-off.
• Agency staff in client-owned accounts. A marketer managing a restaurant client's ad and social accounts, with the client's permission, can keep each client's logins in its own profile and share those profiles with teammates. Team seats are free on JustBrowser, and a seat runs only the profiles shared with it.

If the platform has its own multi-user feature, use that first. Merchant dashboards on the big delivery apps generally let an owner add staff or managers under their own logins, and that is a better answer than a shared browser profile.

JustBrowser is desktop software for Windows x64 and macOS (Apple Silicon). It has no mobile app and no Linux build, and proxies aren't included in the subscription (bring your own or buy a plan in the app). Most delivery orders happen in native mobile apps, so mobile-app promo flows need to be tested on devices; the browser covers the web checkout.

For People Who Build the Other Side

Most of what the big apps use is available to smaller operators too: card tokens from your payment processor, address normalisation, device and browser fingerprinting, velocity checks on sign-ups. None of it is exotic. If you buy paid traffic to promo pages, bot clicks are a separate problem, and ClickzProtect, our sister product, does bot detection for affiliates and traffic operators. For first-party numbers on your own ordering site from analytics that doesn't rely on cookies, JustAnalytics is ours as well.

Frequently Asked Questions

Why was my first-order promo denied on a brand-new account?

New-customer offers are usually limited to one per customer, and many are also limited per household, device or payment method. If your account shares a delivery address, card, phone number or device with an account that already used the offer, the app can treat you as a repeat customer. If you genuinely never used the offer, contact the app's support through the help section and explain the situation.

Do delivery apps use device fingerprinting?

Large delivery and grocery apps run fraud checks that look at more than your email. These typically combine payment details, delivery address, phone number, device and browser signals, and order behaviour into a risk score, using in-house systems, third-party fraud vendors, or both. Which app uses which vendor is rarely public.

Can I claim a second first-order discount with another account?

No. New-customer offers are meant for one person's first order, and claiming one again under a different account breaks the apps' terms. The consequences can include closed accounts, revoked credits, cancelled orders and blocked payment methods. The legitimate routes are subscription plans, referrals and asking support.

How can a store or app team test its own promo-code rules?

Use a staging environment or a test mode, create test accounts you own, and run each rule through separate browser profiles so the sessions do not share cookies or storage. Check that one-per-customer, per-address and per-payment-method limits all trigger when they should, and that a genuine new customer is never blocked.

Do fraud-detection vendors share data across different apps?

Some fraud vendors serve many merchants and describe using signals from across their network in risk scoring. That can mean activity flagged on one service affects how risky a device or card looks elsewhere, without the apps sharing customer lists directly. The details vary by vendor and contract.

---

Try JustBrowser

A multi-account browser for teams, built on a custom Chromium engine with native C++ integration, not extension-based. Each profile is its own browser, with its own cookies, storage, proxy and 40+ identity parameters. Local REST API + CDP for Playwright, Puppeteer, Selenium. Windows x64 and macOS (Apple Silicon). $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles, unlimited cloud sync, unlimited team seats.

Get started → · How it differs from Multilogin / GoLogin / AdsPower