Cashback card with rule sets

Build a cashback credit card program with three named rule sets alongside the program’s automatic default set. Tracking rules update counters, earning rules choose one cashback rate, and maintenance rules reset monthly state.

What you’ll build

Use case	How it works
Category multipliers	5% on dining, 3% on groceries, 1% on everything else
Spend threshold bonus	Rate jumps from 1% to 3% after $2,500/month in total spend
Retroactive bonus	When crossing the threshold, a one-time bonus covers the delta on prior spend
Monthly reset	Counters reset on the 1st of each month via automation
Independent execution groups	Three named sets run after the automatic `default` set

The end result is 4 rule-set resources, 8 rules, and 1 automation: the automatic default set plus 3 named sets.

Assumptions

This guide assumes you already have:

A program created
An asset linked to that program (CASHBACK_USD, scale 2, UNLIMITED, SIMPLE)

See the quickstart if you need help with setup.

Create the rule sets

Every program already has a default rule set in the first position. This example intentionally leaves it empty and creates three named sets because the rules have separate responsibilities:

curl -X POST https://api.scrip.dev/v1/programs/$PROGRAM_ID/rule-sets \
  -H "Authorization: Bearer $SCRIP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key":"tracking","name":"Tracking"}'

curl -X POST https://api.scrip.dev/v1/programs/$PROGRAM_ID/rule-sets \
  -H "Authorization: Bearer $SCRIP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key":"earning","name":"Earning"}'

curl -X POST https://api.scrip.dev/v1/programs/$PROGRAM_ID/rule-sets \
  -H "Authorization: Bearer $SCRIP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key":"maintenance","name":"Maintenance"}'

Save the three returned IDs as TRACKING_RULE_SET_ID, EARNING_RULE_SET_ID, and MAINTENANCE_RULE_SET_ID. Each new set is appended after the ones that already exist. Because these are created in the order tracking, earning, maintenance, Scrip numbers the sets default = 1, tracking = 2, earning = 3, maintenance = 4. All applicable ACTIVE rules across all four sets participate. If you add an applicable ACTIVE rule to default, it runs before this walkthrough’s named sets because default holds the first position. Set position controls execution priority only.

Tracking set

Each rule request below assigns its rule via rule_set_id to one of the three named sets. Create the rules in the order shown; Scrip numbers them within each set as they are added, so creation order is execution order. stop_after_match on any rule is scoped to that rule’s containing set.

1. Track monthly spend

Every rule in this program needs to know how much the participant has spent this month. We track two counters: total spend (for the threshold check) and non-category spend (for the retroactive bonus calculation). monthly_spend tracks everything, for the $2,500 threshold:

{
  "name": "track_monthly_spend",
  "rule_set_id": "{{TRACKING_RULE_SET_ID}}",
  "condition": "event.type == \"purchase\" && event.amount > 0",
  "actions": [
    { "type": "COUNTER", "key": "monthly_spend", "value": "${{ event.amount }}" }
  ]
}

2. Track non-category spend

monthly_base_spend tracks only non-category purchases. This is what the retroactive bonus pays out on.

{
  "name": "track_monthly_base_spend",
  "rule_set_id": "{{TRACKING_RULE_SET_ID}}",
  "condition": "event.type == \"purchase\" && event.amount > 0 && !(event.mcc in [\"5812\", \"5813\", \"5814\", \"5411\", \"5422\"])",
  "actions": [
    { "type": "COUNTER", "key": "monthly_base_spend", "value": "${{ event.amount }}" }
  ]
}

Counter values in conditions are snapshots: they reflect the state before the current event’s actions execute. These rules increment the counters in the database, but later rules in the tracking set and every later set still see the pre-event values. This is important for threshold detection.

3. Retroactive bonus at $2,500

When a participant crosses the $2,500 monthly threshold, they should retroactively earn an extra 2% on their non-category spend so far. This makes up the difference between the 1% they already earned and the 3% high-spender rate.

{
  "name": "threshold_retroactive_bonus",
  "rule_set_id": "{{TRACKING_RULE_SET_ID}}",
  "condition": "event.type == \"purchase\" && event.amount > 0 && participant.counter.monthly_spend < 2500.0 && (participant.counter.monthly_spend + event.amount) >= 2500.0",
  "actions": [
    {
      "type": "CREDIT",
      "asset_id": "{{CASHBACK_USD_ASSET_ID}}",
      "amount": "${{ round(participant.counter.monthly_base_spend * 0.02, 2) }}",
      "description": "Retroactive 2% bonus on prior non-category spend"
    }
  ]
}

The condition has two parts that make it fire exactly once per month:

snapshot < 2500: hasn’t crossed yet
(snapshot + event.amount) >= 2500: this event crosses it

The credit amount uses monthly_base_spend (not monthly_spend) so the retroactive bonus only applies to purchases that earned the 1% base rate. Dining and grocery purchases already earned their full 5%/3%. Paying an extra 2% on those would overshoot.

Do not use stop_after_match here. It would skip later rules in the tracking set. The earning set would still run, but future tracking rules in this set would not.

Earning set

The earning rules are mutually exclusive. A matching category or high-spender rule stops only the rest of this set. Tracking and maintenance remain independent.

4. Dining: 5%

{
  "name": "dining_cashback",
  "rule_set_id": "{{EARNING_RULE_SET_ID}}",
  "stop_after_match": true,
  "condition": "event.type == \"purchase\" && event.amount > 0 && event.mcc in [\"5812\", \"5813\", \"5814\"]",
  "actions": [
    {
      "type": "CREDIT",
      "asset_id": "{{CASHBACK_USD_ASSET_ID}}",
      "amount": "${{ round(event.amount * 0.05, 2) }}",
      "description": "Dining 5% cashback"
    }
  ]
}

MCC codes: 5812 (restaurants), 5813 (bars), 5814 (fast food). stop_after_match: true ensures a dining purchase earns 5% and only 5%. It skips the later grocery, high-spender, and base rules in the earning set. It does not stop another set.

5. Groceries: 3%

{
  "name": "grocery_cashback",
  "rule_set_id": "{{EARNING_RULE_SET_ID}}",
  "stop_after_match": true,
  "condition": "event.type == \"purchase\" && event.amount > 0 && event.mcc in [\"5411\", \"5422\"]",
  "actions": [
    {
      "type": "CREDIT",
      "asset_id": "{{CASHBACK_USD_ASSET_ID}}",
      "amount": "${{ round(event.amount * 0.03, 2) }}",
      "description": "Grocery 3% cashback"
    }
  ]
}

MCC codes: 5411 (grocery stores), 5422 (freezer/meat lockers). The same set-local stop prevents the high-spender and base rules from also firing.

6. High-spender: 3% on everything else

After crossing the $2,500 monthly threshold, all remaining non-category purchases earn 3% instead of 1%.

{
  "name": "high_spender_cashback",
  "rule_set_id": "{{EARNING_RULE_SET_ID}}",
  "stop_after_match": true,
  "condition": "event.type == \"purchase\" && event.amount > 0 && (participant.counter.monthly_spend + event.amount) >= 2500.0",
  "actions": [
    {
      "type": "CREDIT",
      "asset_id": "{{CASHBACK_USD_ASSET_ID}}",
      "amount": "${{ round(event.amount * 0.03, 2) }}",
      "description": "High-spender 3% cashback"
    }
  ]
}

This uses (snapshot + event.amount) >= 2500 so the threshold-crossing purchase itself earns at the higher rate.

7. Base: 1% on everything else

The catch-all for purchases below the threshold that don’t match a category.

{
  "name": "base_cashback",
  "rule_set_id": "{{EARNING_RULE_SET_ID}}",
  "condition": "event.type == \"purchase\" && event.amount > 0",
  "actions": [
    {
      "type": "CREDIT",
      "asset_id": "{{CASHBACK_USD_ASSET_ID}}",
      "amount": "${{ round(event.amount * 0.01, 2) }}",
      "description": "Base 1% cashback"
    }
  ]
}

Only fires when no earlier rule in the earning set matched: the dining, grocery, and high-spender rules all use stop_after_match.

Maintenance set

8. Monthly counter reset

{
  "name": "monthly_counter_reset",
  "rule_set_id": "{{MAINTENANCE_RULE_SET_ID}}",
  "condition": "event.type == \"monthly_reset\"",
  "actions": [
    {
      "type": "COUNTER",
      "key": "monthly_spend",
      "value": "${{ -participant.counter.monthly_spend }}"
    },
    {
      "type": "COUNTER",
      "key": "monthly_base_spend",
      "value": "${{ -participant.counter.monthly_base_spend }}"
    }
  ]
}

Triggered by the automation below. Subtracting the current value zeros both counters.

Automation

Create one automation to fire the monthly reset:

{
  "name": "Monthly Counter Reset",
  "trigger": {
    "type": "cron",
    "cron_expression": "0 0 1 * *"
  },
  "scope": "participants",
  "participant_filter": "participant.counter.monthly_spend > 0",
  "event_name": "monthly_reset"
}

On the 1st of each month at midnight UTC, this fans out a monthly_reset event to every participant with a non-zero spend counter. The filter avoids unnecessary events for inactive participants.

Rule evaluation flow

Here is the effective execution sequence for a purchase. The empty default set contributes no rule evaluations in this walkthrough:

purchase event arrives
  │
  ├─ default set (position 1, intentionally empty)
  │
  ├─ tracking set (position 2)
  │    ├─ rule 1: track_monthly_spend
  │    ├─ rule 2: track_monthly_base_spend
  │    └─ rule 3: threshold_retroactive_bonus
  │
  ├─ earning set (position 3)
  │    ├─ rule 1: dining_cashback        5% if MCC matches → STOP THIS SET
  │    ├─ rule 2: grocery_cashback       3% if MCC matches → STOP THIS SET
  │    ├─ rule 3: high_spender_cashback  3% if threshold reached → STOP THIS SET
  │    └─ rule 4: base_cashback          1% catch-all
  │
  └─ maintenance set (position 4)
       └─ rule 1: monthly_counter_reset (purchase does not match)

The named sets run after the empty default set. If default contained an applicable ACTIVE rule, that rule would participate first, before any named set. The tracking set then evaluates before the earning set. Its counter writes persist first, but earning conditions and dynamic action expressions still read the shared event-start snapshot. The earning rules are mutually exclusive through set-local stop_after_match. The maintenance set still participates after an earning rule stops its own set.

Example event

Your backend sends this when a card transaction settles:

{
  "program_id": "{{PROGRAM_ID}}",
  "external_id": "user_123",
  "idempotency_key": "txn_abc123_settled",
  "event_timestamp": "2026-01-15T10:30:00Z",
  "event_data": {
    "type": "purchase",
    "amount": 85.00,
    "mcc": "5812",
    "merchant_name": "Corner Bistro",
    "transaction_id": "txn_abc123"
  }
}

Only type, amount, and mcc are used by rule conditions. Include whatever else you need for your own analytics.

Edge cases and watchouts

Rounding

With scale: 2, amounts are stored to the cent. Use round(expr, 2) in every CREDIT to avoid precision issues:

round(event.amount * 0.05, 2)  // good: $85.00 * 0.05 = $4.25
event.amount * 0.05             // risky: may produce $4.250000000001

The threshold-crossing purchase

The event that pushes monthly_spend past $2,500 earns at the 3% rate (high-spender), not 1%. This is because high_spender_cashback checks (snapshot + event.amount) >= 2500, which is true for the crossing purchase. The retroactive bonus also fires on the same event, covering all prior spend.

Category purchases don’t care about the threshold

A dining purchase always earns 5% whether the participant has spent $500 or $5,000 this month. The stop_after_match on dining_cashback (the first rule in the earning set) fires before the high-spender and base rules in that set are evaluated. The threshold only affects non-category purchases.

The second counter

monthly_base_spend exists so the retroactive bonus only pays out on purchases that earned 1%. Without it, a participant who spent $2,000 on dining before crossing the threshold would get an extra 2% on those dining purchases, bumping them from 5% to 7%, which isn’t intended. The retroactive bonus should only upgrade 1% purchases to 3%.

Counter resets and tier status

On the 1st of each month, the counter drops to zero. There’s no “tier” to maintain: the high-spender rate is purely counter-driven. A participant who spent $10,000 last month starts fresh at 1% the next month.

Refund handling

This example doesn’t include refund rules. In production, you’d add rules to:

Debit cashback earned on the refunded transaction
Reduce the monthly_spend counter so the threshold status stays accurate

A refund rule might look like:

{
  "name": "refund_clawback",
  "rule_set_id": "{{MAINTENANCE_RULE_SET_ID}}",
  "condition": "event.type == \"refund\" && event.original_cashback > 0",
  "actions": [
    { "type": "DEBIT", "asset_id": "{{CASHBACK_USD_ASSET_ID}}", "amount": "${{ event.original_cashback }}", "allow_negative": true },
    { "type": "COUNTER", "key": "monthly_spend", "value": "${{ -event.original_amount }}" }
  ]
}

Your backend would include original_cashback and original_amount from the original transaction record. allow_negative lets the debit succeed even if the participant has already spent the cashback; without it, a DEBIT against an insufficient available balance fails and the refund event is marked FAILED.

Excluded transaction types

The base rule doesn’t exclude any MCC codes. In practice, you’d want to block non-qualifying transactions like cash advances or wire transfers:

event.type == "purchase" && event.amount > 0 && !(event.mcc in ["6010", "6011", "6051", "4829", "7995"])

Large MCC lists

The CEL in operator works well for short lists (5-20 entries). If you need to match against hundreds of merchants or categories, move the classification into your backend and pass a flag like event.is_dining: true in the event payload instead.

Recipes

Integrations

Cashback card with rule sets

What you’ll build

Assumptions

Create the rule sets

Tracking set

1. Track monthly spend

2. Track non-category spend

3. Retroactive bonus at $2,500

Earning set

4. Dining: 5%

5. Groceries: 3%

6. High-spender: 3% on everything else

7. Base: 1% on everything else

Maintenance set

8. Monthly counter reset

Automation

Rule evaluation flow

Example event

Edge cases and watchouts

Rounding

The threshold-crossing purchase

Category purchases don’t care about the threshold

The second counter

Counter resets and tier status

Refund handling

Excluded transaction types

Large MCC lists

​What you’ll build

​Assumptions

​Create the rule sets

​Tracking set

​1. Track monthly spend

​2. Track non-category spend

​3. Retroactive bonus at $2,500

​Earning set

​4. Dining: 5%

​5. Groceries: 3%

​6. High-spender: 3% on everything else

​7. Base: 1% on everything else

​Maintenance set

​8. Monthly counter reset

​Automation

​Rule evaluation flow

​Example event

​Edge cases and watchouts

​Rounding

​The threshold-crossing purchase

​Category purchases don’t care about the threshold

​The second counter

​Counter resets and tier status

​Refund handling

​Excluded transaction types

​Large MCC lists

What you’ll build

Assumptions

Create the rule sets

Tracking set

1. Track monthly spend

2. Track non-category spend

3. Retroactive bonus at $2,500

Earning set

4. Dining: 5%

5. Groceries: 3%

6. High-spender: 3% on everything else

7. Base: 1% on everything else

Maintenance set

8. Monthly counter reset

Automation

Rule evaluation flow

Example event

Edge cases and watchouts

Rounding

The threshold-crossing purchase

Category purchases don’t care about the threshold

The second counter

Counter resets and tier status

Refund handling

Excluded transaction types

Large MCC lists