The power chain

The Walmart triangle

Three different Walmart arrangements exist, and they sound alike. Use this page to keep them apart.

The three arrangements

Term	What it is	Offer model	Who adjudicates items
WM-Managed	Walmart cannot power exclusion catalogs on its own, so it teams up with InComm, and the InComm offer then works at Walmart.	Exclusion InComm offers approved by Walmart	Walmart, using its own fine-line category adjudication. Not our UPC list.
Walmart Submitted	The normal path for inclusion offers. InComm submits the offer, Walmart approves it.	Inclusion InComm offers approved by Walmart	Walmart, against the submitted list.
Walmart promo code	Our direct relationship with Walmart. Walmart issues its own card. Works only at Walmart.	Not an InComm offer at all	Walmart, fully.

Which one do I need?

Situation	Answer
Inclusion offer, member shops at Walmart	Nothing special. Walmart Submitted covers it.
Exclusion offer marked WM-Managed, member shops at Walmart	Works directly. Walmart enforces by fine-line category.
Exclusion offer, not WM-Managed, client wants Walmart coverage	Build an Either/Or: exclusion InComm offer + Walmart promo card.
Client wants Walmart only	Walmart promo code product alone.

Network selection follows the same logic. An exclusion program that is not WM-Managed should run on a minus-Walmart network, so its cards never route to a Walmart register in the first place.

⚠️

Under WM-Managed, Walmart adjudicates by its own rules.

Walmart's fine-line categories do not match our UPC lists item for item. A product our catalog would block can pass at Walmart, and the reverse. When someone reports "the card behaved differently at Walmart", this is usually why.

Promo codes are frozen at creation

A Walmart promo code is scoped when Walmart sets it up, for example "Fresh Produce Only" or "All Grocery". That scope is hard-coded. It does not change after deployment. Enforcement is a category-level pass or fail: there is no barcode scanning and no real-time catalog behind it. A promo code is closer to restricted store credit than to a card. This is why promo code scopes tend to be broad, and why the initial setup matters so much.

Real examples from our 14 production promo codes (the Identifier is what a product references):

Name	`Identifier`	`RedeemAt`
BridgeMart ATF	`6814626`	`in_store_and_online`
Holiday Turkey	`7288082`	`in_store_and_online`
Nutrition Essentials	`7288492`	`in_store_and_online`
Breast Pump & Supplies	`7600922`	`in_store_and_online`
US Safety	`3336214`	`in_store_only`

RedeemAt has exactly two values: in_store_only and in_store_and_online. The redeemable code itself is a separate secret string per promo; it is not shown here.

Under the hood

There is no WM-Managed flag in our database or code. The arrangement lives in the InComm and Walmart paperwork. The nearest real field is products.CardIssuer, which only distinguishes who mints the card.
A Walmart promo product is a row in products with CardIssuer = walmart and a PromoCode that points at a row in promocodes.
Issuing a Walmart card skips InComm entirely. The platform sends a Fiserv/Datawire request, and Walmart's side returns the card number and an EAN. The EAN is stored in the card's SecurityCode field, and the member redeems with an EAN barcode or QR code.
There is no clip concept on the Walmart side. Each issuance is its own stored-value card.
Walmart redemptions do not arrive by webhook. They arrive in a daily settlement file and land in walmartfileimporttransactions. Expect them later than InComm events.