The power chain

Products & advanced products

A product is the portal's sellable wrapper around an InComm offer or a Walmart promo. It is the bridge between InComm's world and our programs.

⚠️

"Product" is a muddy term, and it is ours.

The concept is pure iQpay, but the platform cannot decide what to call it. The same row in products is a product on the Products page, an offer in the Send cards wizard and in the member's wallet, and an Advanced Offer when it is composite. When you read "offer" anywhere in the portal UI, first ask: is this an InComm offer, or a product wearing the word? One sentence settles the verbs: you pick a product, the member gets a card, an offer funds it, and "sending" any of the three means creating an order.

Offerfunds it→ Productyou pick it→ Cardmember gets it

The same send, seen from three stages.

The product row

Products exist so the same underlying power source can be dressed up differently. A product carries the image and display text, and it can be customized per program or per organization, even though at ground level two products may run on the identical InComm offer or Walmart promo.

Field	Values	Meaning
`ProductType`	`original` · `advanced` · `marketplace`	Plain product or composite product. `marketplace` belongs to the defunct marketplace feature; do not create new ones.
`CardIssuer`	`incomm` · `walmart`	Who mints the card. A third value, `open_mastercard`, exists on 2 legacy rows and is not in use.
`IncommOffer`	an offer number	For InComm products: which offer this wraps. Stored as a string next to a real foreign key (`IncommOfferProductId`). Both are maintained.
`PromoCode`	a promo identifier	For Walmart products: which Walmart promo this wraps.
`RedeemOptions`	text	Where the member can redeem. The admin form calls this field Redeem At.

Advanced products

An advanced product is a product that contains other products. The parent is a normal products row with ProductType = advanced; the children are other products. What ties them together is the groupedproducts table: one row per child, and each row is the attachment record saying "parent X includes child Y, at amount Z, in position N, repeating on this cadence, expiring after this many days." So "composed of groupedproducts rows" just means: to see what an advanced product contains, read its rows in that table. The admin frontend calls these Advanced Offers.

ProductAdvanceType declares how the children combine:

Type	Meaning	Status
`either_or`	The member receives one of the children, their choice.	In use
`no_overlap`	The recurring wrapper: it wraps a product and makes it repeat, so cards go out on a cadence. Recurrence can only be set up at this advanced-product layer.	In use
`overlap`, `linked`, `different_values`	Defined in code but disabled in the admin UI.	Dormant

Either/Or mechanics

The pair is always an InComm offer and a Walmart promo of the same dollar amount. We do not mix denominations.
The member makes the choice at activation, not at order time.
The choice is irreversible for the life of that card. The platform issues the chosen child and nothing else. On recurring benefits, each monthly resend offers the choice again.
Order rows for either/or cards are recognizable in the database: orderproducts.ProductId is NULL and AdvanceProductId is set.
The order amount is the maximum of the children, not the sum. The member gets one side only.
Physical cards are not allowed for either/or products.
EitherOrCardSendLogic is single_issuer or multiple_issuers. The cross-issuer case (InComm offer or Walmart promo) is the classic exclusion + Walmart combination.

ℹ️

Advanced products are also how recurrence works.

Monthly benefits are advanced products whose child rows repeat on a cadence (CadenceType = monthly or custom). The scheduler pre-creates a groupedproductlogs row per future send, then turns each into a real order on its send date. See The clip lifecycle.

Attaching products

Products meet the rest of the platform in two different ways. Do not confuse them:

To a program: a programproducts row. This is what makes the product orderable in that program, with a program-specific amount.
To an organization: a many-to-many whitelist (product_organizations_x_organization_products). This only controls visibility, not ordering.