The power chain

Recurring offers & the clip lifecycle

Clipping turns an offer into spendable money on an InComm customer. "To clip" is InComm's verb: attaching an offer to an ingenId on their side. Every recurring benefit is built from clip, unclip, and re-clip, so this page covers both together.

ℹ️

The one-clip rule drives everything here.

An InComm customer can hold many offers, but never two clips of the same offer at once. A monthly benefit reuses the same offer every cycle, so the old clip must come off before the new one goes on. That is the whole reason unclip-then-re-clip exists.

What the member experiences month to month

Digital cards: a new link arrives at the start of each month. The new cycle's offer is clipped when the member clicks the link. No click, no refill.
Physical cards: the re-clip happens automatically each cycle (when the program has auto-clip enabled). The member keeps using the same plastic.

The full activation flows, including phone activation for physical cards, are on The member journey.

First card: create the customer

The platform generates a PAN and calls InComm's CreateCustomer with the offer number and that PAN.
InComm returns an ingenId. We store it as cards.AccountId.
The card row becomes CustomerStatus = active, IssuerStatus = funded, with balance and expiration set.

More offers: clip onto the same customer

When the member already has an ingenId, the platform calls ClipOffer with the ingenId and the new offer number. The offers must differ: the same identical offer can never be clipped twice to one customer. Each clip creates a new iQpay card row that shares the wallet's VerificationCode, PAN, and ingenId. See What is a card.

Recurring orders: unclip, then re-clip

For a monthly benefit, the same offer must fund again each cycle. There is no top-up call; the platform refills by unclip and re-clip:

The platform unclips the offer from the customer (DeleteCustomer with ingenId and offer number).
The platform re-clips the same offer to the same customer.
The balance returns to the full monthly allocation.

This applies to digital cards. For physical cards the platform reconciles local state without the unclip call. Throughout the whole cycle the member's ingenId never changes.

ℹ️

Where the schedule lives.

Recurring sends are pre-planned as groupedproductlogs rows, one per future send. On the send date each row becomes a real order, and the order re-runs the clip. Monthly cadence expires cards at end of month. If the program has AutoClipOnPhysical on, members who already activated get the new cycle clipped automatically.

What "renewal" actually is

When a monthly benefit renews, the platform does not edit the existing card. It creates a brand-new card row for the new month. The new row reuses the same wallet code, the same PAN, and the same ingenId, and the old row expires. From the member's side the same card just keeps working; in the database each month is its own row.

Deactivation: unclip and claw back

Deactivating a funded card unclips the offer from the customer.
The leftover balance is recorded in cards.AmountRemoved, and Balance goes to 0.
AmountRemoved is clawback, not spend. Real spend lives in card events. See Card events.

Reconciliation: FixCard

Local state and InComm state can drift. The FixCard routine fetches the customer's remote clip list and repairs both directions:

An offer is clipped remotely, but the local card is expired or inactive → unclip it.
A local card is active and funded, but the offer is missing remotely → clip it.

FixCard exists only for InComm cards. For Walmart cards it does nothing, because there is no clip concept on that side.

⚠️

Known trap: the clip-deleted orphan.

If a member ends up with two overlapping monthly cards on one customer, the old card's expiry can delete the clip that the new card depends on. The symptom is CLIP DELETED declines on everything. The fix is a careful re-clip. Re-clipping blindly risks double funding.