Postback Controls To Reject, Approve, Or Hold Conversions

Postback Controls allow you to automatically reject, approve, or place conversions on hold based on criteria passed in the conversion postback. This enables you to enforce business logic like minimum order values, lead quality filters, fraud prevention rules, and revenue restrictions without manual intervention.

This guide covers rule configuration, logic patterns, variable selection, testing workflows, and troubleshooting common issues.

Key Terms

Review these postback-related terms before diving in

Postback Controls: A system for automatically managing conversions based on predefined rules and criteria.

On Hold Conversions: A feature that enables networks to fire conversions with a preset timer, determining when the conversion becomes realized. Ensures conversions are created and become payable at the right time.

Control Type: Determines how conversions are handled (Accept/Reject/On Hold).

Rule Variables: Parameters used to evaluate incoming conversion data (e.g., Sale Amount, ADV1-5, Sub1-5).

Effective Period: The timeframe during which a postback control is active.

Understanding AND vs OR Logic

The most common source of confusion with Postback Controls is understanding how multiple conditions combine. Everflow uses AND logic by default, which can cause unexpected scenarios where you need more rules than expected.

🧮 AND vs OR Logic: How Rules Combine

📘 "All Must Apply" = AND Logic (Default)

When you add multiple conditions to a single rule, ALL conditions must be true for the rule to fire. This is standard AND logic.

Example: Reject if Sale Amount > 100 AND State = NY
Result: Only rejects conversions that are BOTH over $100 AND from New York
What passes: $150 sale from Florida ✅ (fails State condition)
What passes: $50 sale from New York ✅ (fails Amount condition)
What rejects: $150 sale from New York ❌ (both conditions true)

The "Matrix Nightmare": When you need State + Amount + Time combinations, AND logic forces you to create a separate rule for EVERY valid combination. 50 states × 3 amounts × 3 times = 450 rules!

📗 "One Or More Must Apply" ≠ Simple OR

Common Misconception: This dropdown name suggests simple OR logic. It does NOT work that way.

Reality: "One Or More Must Apply" still uses AND logic within each condition. The difference is which rule action to take (reject vs approve vs hold).

Customer Quote:
"Is it possible to set up a condition where a lead is approved if Adv1 = 1 AND either Adv2 = 1 OR Adv3 = 1, given that I don't see an OR statement option?"

Support Response: "There isn't currently a function that we have that can do that"

💡 The "OR Workaround" (Single Variable Only)

There IS a workaround for OR logic, but it only works for a single variable, not multiple variables.

Discovered by a customer:
Goal: Lower payouts for leads at 5 PM, 6 PM, OR 7 PM

The Workaround:
1. Use comparison method Equals Number
2. List multiple values on separate lines:
17
18
19
20

Result: Acts as OR logic for that single variable (ADV1 equals 17 OR 18 OR 19 OR 20)

⚠️ Limitation:

This workaround ONLY works for a single variable. You cannot do multi-variable OR like "(ADV2=1 OR ADV3=1) AND State=NY". For that, you need multiple separate rules.

🚨 Real Customer Impact: "Matrix Nightmare"

Customer Example

Goal: Set payouts based on Debt Amount + State + Time of Day

The Realization: Because each rule uses AND logic, they would need a separate rule for every single combination:
• "NY + High Debt + Morning"
• "NY + High Debt + Afternoon"
• "NY + Low Debt + Morning"
• "CA + High Debt + Morning"
• ...and hundreds more

Account Manager Quote:
"It gets managed. I wouldn't want to manage that personally."

They referred to it as building a "big matrix" and requested mapping it in a spreadsheet first because the complexity could "balloon quite easily".

When Do You Need Postback Controls?

Before setting up rules, identify your specific use case. Here are the most common scenarios:

💳

Revenue Restrictions

Block commissions on subscription renewals, zero-dollar test orders, or low-value transactions that shouldn't be commissionable.

Example: SaaS Company
Only pay affiliates for initial purchase, NOT subscription renewals from Stripe/PayPal. Set rule to reject if Sale Amount equals $29.00 (renewal price).

Example: Online Community Platform
Reject zero-dollar validation orders. THE MISTAKE: Applied to Brand Level → rejected ALL "Sign Up" events (naturally $0). THE FIX: Scope to Event Level → apply ONLY to Purchase event.

Variable: Sale Amount | Comparison: Equals

✅

Lead Quality Filtering

Only accept leads that have reached specific "valid" status in your CRM. Reject leads that don't meet quality thresholds.

Example: Medical Services Company
Using Zoho invoicing - only pay when invoice actually PAID. Map Zoho status to ADV1. Rule: Accept ONLY if ADV1 equals "paid". CASE SENSITIVITY ERROR: Initially typed "Paid" (capitalized) → rule failed. Fix: "paid" (lowercase).

Example: Financial Services Company
Wanted "Qualified" OR "Jumbo" loans. Discovered OR logic not possible for multiple variables without workaround.

Variable: ADV1 (status) | Comparison: Equals (case sensitive!)

🕐

Business Hours Restrictions

Pay different amounts based on when conversion occurs. Leads during business hours worth more than nights/weekends.

Example: Insurance Lead Agency
Auto insurance leads - business hours (9-5 weekdays) pay $14. Nights/weekends pay $10. Used Custom Payout Settings with ADV1 (Hour of Day). DISCOVERED "OR" WORKAROUND: Used "Equals Number" with multiple values (17, 18, 19, 20) on separate lines for single-variable OR logic.

Variable: ADV1 (hour) | Comparison: Equals Number (list)

⏸️

On Hold Conversions

Hold conversions for verification (medical approval, fraud review, payment processing) before paying affiliate. Avoids clawbacks.

Example: Weight Loss Clinic
Weight loss clinic - patients pay upfront but must pass provider review. Hold conversion until doctor approves. If rejected, no clawback needed.

Example: Airline Company
Flight bookings months in future. Hold up to 5-6 months to validate ticket wasn't cancelled. CRITICAL TRAP: On Hold conversions don't have real Conversion ID yet (just placeholder). MUST use Transaction ID for bulk approval.

Setting: Enable "On Hold" | Bulk Update: Use Transaction ID

🚨

Fraud Prevention

Block suspicious conversions based on geographic location, fraud scores, velocity patterns, or other red flags.

Example: Lead Generation Network
Partners force-firing conversions from India/Nigeria for US-only offers. CHALLENGE: Postback Controls don't have native Country dropdown. SOLUTION: Advertiser passes country code ("IN") into ADV5 parameter. Rule: If ADV5 equals "IN" → Reject.

Example: Insurance Lead Agency
Partner cap at 100 leads/day with Pass-Through. When cap hit, traffic STILL goes to landing page (ad account not banned), but excess conversions rejected (0 payout).

Variable: ADV5 (country/fraud score) | Additional: Caps + Fail Traffic

🔁

Duplicate Prevention

Prevent affiliates from getting paid twice for same customer. Most common for e-commerce order deduplication.

Common Configuration
Enable "Reject Duplicate Conversion Order ID" at offer or account level. System automatically rejects any conversion with duplicate order_id value.

Example: Home Services Company
Pass Falcon CRM Lead ID into Order ID field. Enable duplicate rejection to prevent double payment when CRM fires update webhooks for same lead.

Setting: Reject Duplicate Order ID | Variable: Order ID from CRM

🌎

Geographic Restrictions

Only accept conversions from specific states/countries. Block traffic from regions where you don't do business.

Example: Insurance CRM Company
Only sells insurance in Florida - needed to disqualify Georgia traffic. Used Targeting (Allowed Region = Florida). Traffic outside region sent to Fail Traffic.

State-Based Status Logic
Hold leads from certain states for manual review while auto-approving others. Set conversions from specific state to "pending" status for approval workflow.

Method: Targeting (for clicks) OR ADV parameter (for conversions)

🛍️

Product/SKU Restrictions

Block commissions on specific products (clearance, free items, cancellation fees) that shouldn't be commissionable.

Example: Pet Products Brand
Partners receiving commissions on "Early Cancellation Fees" ($16). When customer cancels subscription, Shopify processes fee → Everflow tracks as sale. SOLUTION: Modify integration to pass SKU/flag into ADV1. Rule: If ADV1 equals "Early Cancellation" → Reject.

Example: Supplement Company
Custom JavaScript loops through cart, concatenates all SKUs into string, passes to ADV1. Rule: "Reject if ADV1 *contains* [Restricted_SKU]".

Variable: ADV1 (SKU/product type) | Comparison: Contains or Equals

Choosing The Right Variable

Postback Controls can ONLY evaluate data passed in the conversion postback URL. You must select the correct parameter type and ensure data is being passed correctly.

📊 Variable Selection Guide

ADV1, ADV2, ADV3, ADV4, ADV5

Owner: Advertiser (you)
When Populated: On conversion postback (server-to-server or pixel)
Common Uses: Status flags, email addresses, demographics, quality scores, product types

ADV1: Status ("paid", "qualified", "returning", "1")
ADV2: Email address or secondary identifiers
ADV3-5: Demographics (age, income, debt amount)

Real Example: Map Zoho Invoice Status to ADV1. Rule: Accept ONLY if ADV1 equals "paid" (lowercase, case sensitive).

Real Example: Pass product type into ADV1. Rule: Reject if ADV1 equals "Early Cancellation".

⚠️ CRITICAL: Postback Controls can ONLY see data passed in the postback URL. Shopping cart data (SKUs, tags, attributes) is INVISIBLE unless you explicitly scrape it and inject into an ADV parameter. If your rule isn't firing, first check that the data is actually being passed.

sub1, sub2, sub3, sub4, sub5

Owner: Partner (affiliate)
When Populated: On click (passed in tracking link)
Common Uses: Campaign IDs, source IDs, placement IDs, creative IDs, BM codes

sub1: Campaign type ("Amplify", "PS" for Paid Search)
sub2-5: Source, placement, creative identifiers

Real Example: Partner passes campaign type in sub1. If sub1="Amplify", CPA=$190. If sub1="PS", CPA=$450 (Custom Payout Settings).

Real Example: Use sub5 for "BM Codes" (internal affiliate IDs) to map traffic sources without creating thousands of Everflow partners.

⚠️ Important: sub parameters are set on the CLICK and remain static through the conversion. They cannot be changed during the conversion postback. Use ADV parameters for data that needs to be determined at conversion time.

Amount (Sale Amount)

Source: Conversion postback amount parameter
Common Uses: Minimum order value rules, revenue thresholds, zero-dollar blocking

Real Example: Reject subscription renewals. Rule: Sale Amount equals 29.00 (renewal price) → Reject.

Real Example: Reject zero-dollar test orders. Rule: Sale Amount equals 0.00 → Reject. MISTAKE: Applied to Brand Level → rejected $0 Sign Up events too.

Common Queries:
• "Reject conversions if order value is less than $50"
• "Only count FTDs over $9.99"
• "Block $0 postbacks"

Decimal Precision: System handles "29" and "29.00" equivalently, but use "Equals" comparison (not "Contains") to avoid rejecting other amounts like "129.00".

Custom Parameters

Advanced: Additional custom fields you've configured
Common Uses: LTV tracking (User ID), event-specific data, specialized integrations

User ID / Customer ID: Required for Customer Value Tool (LTV tracking). Persists across multiple conversions to trigger retention bonuses.

Real Example: Pass persistent User ID. System listens for cumulative revenue >$1,000 OR "Month 3 Renewal" event → trigger $100 bonus.

❌ What Postback Controls CANNOT See

Postback Controls do NOT have native access to:
• Geographic data (Country, State, City) - unless passed as text in ADV parameter
• Device data (OS, Browser, Device Type) - unless passed in ADV parameter
• Shopping cart contents (SKUs, product names, tags) - unless scraped and passed in ADV parameter
• Click-level data not passed through to conversion

Real Example: Attempted to reject conversions from India using Postback Controls. Discovered Controls don't have Country dropdown. Solution: Advertiser passes country code into ADV5, then rule evaluates ADV5.

Understanding Rule Scope (Brand vs Event vs Offer)

One of the most common mistakes is applying rules too broadly, causing unintended rejections of valid conversions.

The #1 Setup Mistake: Wrong Scope Level

Real Customer Mistake: Goal was to reject conversions with Sale Amount = $0 to prevent duplicate subscriptions. The mistake was applying the rule at Brand Level, which inadvertently rejected ALL Sign Up events (which are naturally $0).

The Fix: Switch scope from Brand to Events level, selecting ONLY the Purchase event and excluding Sign Up.

Lesson: Always start with the narrowest scope (Event Level) and expand only if needed.

🏢

Brand Level

Broadest Scope

Rule applies to ALL events across the entire brand (all offers, all partners, all event types).

Applies To:
• All offers under this brand
• All event types (Base, Upsell, Renewal, Sign Up, etc.)
• All partners
• All geographic regions

⚠️ Danger: Most likely to cause unintended rejections. A common mistake happens here - rejecting natural $0 Sign Up events when targeting $0 test orders.

When To Use: Global deduplication rules, company-wide fraud prevention, brand-level compliance requirements

🎯

Event Level

Recommended Scope

Rule applies ONLY to specific event type(s) you select (e.g., Purchase only, not Sign Up).

Applies To:
• Selected event(s) only (Purchase, Upsell, Renewal, etc.)
• All offers that use this event
• All partners

✅ Best Practice: Start here. Most specific and safest option. The fix is switching from Brand to Event Level.

When To Use: Revenue restrictions on purchases (not signups), upsell-specific rules, renewal blocking

Example: "Reject Purchase events with $0 amount, but allow $0 Sign Up events"

🎁

Offer Level

Narrowest Scope

Rule applies ONLY to one specific offer. Most granular control.

Applies To:
• Single offer only
• All events on that offer
• All partners on that offer

When To Use: Offer-specific restrictions, A/B testing rules, partner-specific offer configurations

Real Example: Had conflicting rules - one on specific offer, another on global CPA offer. Confused about which applies. Fix: Delete offer-level rules → implement single Brand-level rule.

⚠️ Management Risk: Managing hundreds of offer-level rules becomes unsustainable. Consider Event or Brand level for scalability.

Setting Up Postback Controls

Navigate to Advertisers → Postback Controls and click Add Postback Control.

General Configuration

Fill in Name — use a descriptive name like "Reject $0 Purchases" or "Hold Leads 7 Days".

Status: Set to Active or Inactive (you can test with Inactive first).

Effective Between: Choose "Always On" or set a specific time period.

Control Type: Select Accept, Reject, or On Hold.

If you select On Hold, a hold period configuration appears. Choose the time unit (Seconds, Minutes, Hours, Days, or Weeks) and enter the duration.

GIF showing General Configuration settings for Postback Controls in Everflow

Rules Configuration

Choose application scope: Apply to all Postbacks, or narrow it to specific Offers, Advertisers, Events, or Partners.

Set Condition Logic: "All Must Apply" (AND) or "One Or More Must Apply" — see the logic explainer above.

Build Rules: Select the Variable (e.g., ADV1, Sale Amount), Comparison Method (Equals, Contains, Greater Than, etc.), and the Value to match against.

Add additional rules by clicking the Rules button.

GIF showing Rules Configuration for Postback Controls in Everflow

Comparison Methods Reference

Selecting the correct comparison method is critical for rules to fire correctly. Here is what each method does:

Comparison Method	How It Works	Case Sensitive?	Common Use Cases	Example
Equals	Exact string match. Value must match perfectly.	YES ⚠️	Status flags ("paid"), specific product names, exact amounts	ADV1 equals "paid" Rejects "Paid" or "PAID"
Equals Number	Numeric exact match. Can list multiple values on separate lines for OR logic (single variable only).	N/A (numeric)	Sale amounts, time of day (hour), age thresholds	Sale Amount equals 29.00 OR: list 17, 18, 19, 20
Contains	Partial match. Checks if value includes the string anywhere within it.	Typically YES	SKU lists (comma-separated), error messages, partial names	ADV1 contains "Cancellation" Matches "Early Cancellation Fee"
Greater Than	Numeric comparison. Value must be strictly greater than threshold.	N/A (numeric)	Minimum order value, fraud score thresholds	Sale Amount greater than 50 Only orders above $50
Less Than	Numeric comparison. Value must be strictly less than threshold.	N/A (numeric)	Maximum order caps, low-value filtering	Sale Amount less than 25 Reject low-value orders
Is Empty	Checks if parameter is null, blank, or not passed at all.	N/A	Required field validation, missing email detection	ADV2 (email) is empty Reject if no email
Does Not Contain	Inverse of Contains. Value exists but does NOT include the string.	Typically YES	Allowlist logic, exclusion rules	ADV1 does not contain "approved" ⚠️ Different from "Is Empty"
Between	Numeric range. Value must fall within specified min and max (inclusive).	N/A (numeric)	Business hours (9-17), age ranges, revenue tiers	ADV1 (hour) between 9 and 17 Business hours only

Case Sensitivity Warning

Real Example: A rule was set up to accept conversions ONLY if Zoho status equaled "Paid" (capitalized). But Zoho's webhook passes "paid" (lowercase). Result: NO conversions were accepted because the rule never fired.

Best Practice: Always check the exact value being passed in the Advertiser Postback Report before creating your rule. Copy and paste the value directly to avoid typos and case mismatches.

The OR Workaround: When using "Equals Number" comparison, you can list multiple values on separate lines to create OR logic for a SINGLE variable. Example: ADV1 equals 17, 18, 19, 20 creates "ADV1=17 OR ADV1=18 OR ADV1=19 OR ADV1=20". This does NOT work for multi-variable OR logic like "(ADV2=1 OR ADV3=1)".

Configuring Rule Actions

Once your conditions are set, choose what action to take when conditions are met:

Reject

Effect: Conversion is rejected and hidden from partner (unless they check invalid reports).

Reporting: Shows as "Rejected" status with "Error Code 26: Blocked by Postback Control" in the Error Message column.

When To Use: Fraud, duplicates, failed quality checks, restricted products.

Approve

Effect: Conversion is immediately approved (bypasses any other pending status).

Reporting: Shows as "Approved" status.

When To Use: Allowlist logic (approve ONLY if specific conditions met), VIP partner auto-approval.

On Hold

Effect: Conversion placed in "On Hold" status for manual review or time-delayed approval.

Reporting: Shows as "On Hold" status, visible to partner but not yet payable.

When To Use: Medical approval gaps, fraud review periods, payment processing delays, subscription trial periods.

Hold Period Configuration: Set duration in Advanced Settings — conversions auto-approve after period expires if no action taken.

On Hold Identifier Trap

On Hold conversions are in "limbo" and do not have a real Conversion ID yet (just a placeholder). To bulk approve or reject them via CSV upload, you MUST use Transaction ID, not Conversion ID.

The Risk: Transaction ID affects ALL events associated with that click. If one click generates 1 booking plus 3 ancillary purchases, updating Transaction ID affects all 4 conversions.

Real Example: An airline held flight bookings for 5-6 months. With 1,500+ PNRs, manual UI approval was unsustainable. Required CSV bulk update workflow using Transaction ID.

Testing Your Rules Before Go-Live

ALWAYS test Postback Control rules before deploying to production. Untested rules can accidentally reject thousands of valid conversions.

Pre-Launch Testing Checklist

Follow these steps before activating any rule

Step 1: Verify Data Is Being Passed

Navigate to Reports, then Advertiser Postback Report. Fire a test conversion and check that your target variable (ADV1, ADV2, etc.) shows the expected value. Copy the EXACT value (case sensitive) rather than retyping it.

Step 2: Create Test Rule With Narrow Scope

Start with Event Level (not Brand Level) to limit blast radius. Use a specific test value that will not affect live traffic.

Step 3: Fire Test Conversion

Use Postman or browser to manually fire postback with test parameters. Or use a test partner account with $0 payout.

Step 4: Verify Rule Fired Correctly

Check the Conversion Report. If rule should reject, confirm status = "Rejected". If rule should approve, confirm status = "Approved". Enable the "Error Message" column to see: "Error Code 26: Blocked by Postback Control: [Rule Name]".

Step 5: Verify Scope (Critical Safety Check)

Confirm ONLY intended conversions were affected. Check that other events (Sign Up, Upsell) were NOT affected if rule should be Purchase-only.

Step 6: Test Edge Cases

Test with case variations ("Paid" vs "paid" vs "PAID"). Test with empty values (parameter not passed). Test with partial matches if using "Contains". Test with boundary values for numeric comparisons.

Testing Tools: Use Postman or cURL to manually fire test postbacks with controlled parameters. For client-side scripts (Shopify), use browser console to inspect data layer before mapping variables.

Troubleshooting

Use this guide to diagnose common Postback Control issues:

Rule Not Firing (Conversions Still Approved)

1. Data Not Being Passed In Postback

Postback Controls can ONLY see data in the postback URL. Shopping cart data (SKUs, tags) is invisible unless mapped to a parameter. Check the Advertiser Postback Report to verify ADV1/ADV2/etc. actually contains the expected value.

2. Case Sensitivity Mismatch

The "Equals" comparison is case sensitive. If your rule looks for "Paid" but the webhook passes "paid", the rule will never fire. Copy the EXACT value from the Advertiser Postback Report.

3. Wrong Variable Selected

Verify which parameter your integration actually populates. If data is in ADV2, a rule checking ADV1 will never match.

4. Wrong Comparison Method

Using "Contains" when you need "Equals" or vice versa. "ADV1 contains 29" also matches "129", "229", "1290".

Too Many Conversions Rejected (Good Conversions Blocked)

1. Wrong Scope (Brand Level Instead of Event Level)

Wanted to reject $0 purchases but also rejected $0 signups. Solution: Switch from Brand Level to Event Level and select ONLY the Purchase event, exclude Sign Up.

2. Comparison Method Too Broad

Using "Contains" when you meant exact match. "ADV1 contains test" matches "test", "latest", "attest", "contest". Use "Equals" for exact match.

3. Multiple Conflicting Rules

One rule at Brand Level, another at Offer Level, unclear which applies. Consolidate to a single rule level or clearly document rule hierarchy.

Cannot Tell Which Rule Rejected A Conversion

Navigate to the Conversion Report and enable the "Error Message" column (customize columns). Look for "Error Code 26: Blocked by Postback Control: [Rule Name]" to identify the exact rule that fired.

Distinguishing Rejection Types:

Postback Control rejection shows Error Code 26 plus the rule name. Duplicate rejection shows a different error code with "Duplicate Conversion" message. Manual rejection shows no Error Code 26; check History (three dots, then History) to see who and when.

OR Logic Not Working (Need ADV2=1 OR ADV3=1)

Problem: Need to approve if EITHER condition is true, but system uses AND logic.

Workaround 1 - Single Variable OR (List Method): Use "Equals Number" comparison and list values on separate lines. Works for single variable only (ADV1=17 OR ADV1=18 OR ADV1=19).

Workaround 2 - Multiple Separate Rules: Create one rule for each OR condition. Rule 1: If ADV2=1, Approve. Rule 2: If ADV3=1, Approve. Can lead to many rules with complex combinations.

Workaround 3 - Pre-Process Logic: Handle OR logic in your integration. If (qualified=true OR jumbo=true), pass ADV1="approved". Keeps Everflow rules simple.

On Hold Conversions: Cannot Bulk Approve With Conversion ID

On Hold conversions do not have a real Conversion ID yet (just a placeholder). You MUST use Transaction ID for bulk approval or rejection via CSV.

Export On Hold conversions to get the Transaction ID column. Create CSV with Transaction ID plus Status update, and upload via CSV import tool.

Risk: Transaction ID affects ALL events tied to that click. If one click generates multiple conversions, all will be updated. Handle carefully if multiple events per transaction.

Editing Rules Mid-Campaign: What Happens To Existing Conversions?

Postback Controls are forward-looking only. Changing a rule does NOT retroactively scan or update historical data. Only NEW conversions going forward are affected.

To fix past data, use Conversion Imports (add or correct historical conversions), the Adjustments Tool (fix accounting totals), Manual CSV Update (bulk update status), or the API (/conversions/update endpoint).

Postback Control vs Custom Settings: Which Should I Use?

Postback Control (Reject): Conversion is hidden from affiliate. Status shows "Rejected" with Error Code 26. No payout, no visibility. Use for fraud, true invalids, duplicates.

Custom Settings ($0 Payout): Conversion is visible to affiliate. Status shows "Approved" with $0 earnings. Good for algorithm training (Meta, Google). Use for business logic (low-quality but valid), geo exclusions.

Advanced Integration Patterns

For complex use cases, these patterns combine Postback Controls with other Everflow features:

Pattern 1: CRM Integration For Lead Verification

Use Case: Only pay for leads that reach "qualified" status in CRM (HubSpot, Salesforce, Falcon).

Step 1: Add hidden form field on landing page with Everflow transaction_id. Form submission sends transaction_id to CRM.

Step 2: On initial lead accept, fire "Unverified Lead" event with $0 payout. Partner gets immediate signal for optimization without payment obligation.

Step 3: When lead status changes to "Qualified" in CRM, fire webhook to Everflow with stored transaction_id plus status flag in ADV1. Postback Control: Accept ONLY if ADV1 equals "qualified".

Step 4: Pass CRM Lead ID into Order ID field. Enable "Reject Duplicate Order IDs" to prevent double payment.

Pattern 2: E-Commerce SKU Filtering (Shopping Cart Data)

Use Case: Block commissions on specific products (clearance, free items, cancellation fees).

The Challenge: Shopping cart data (SKU, product type) is not automatically visible to Postback Controls. It must be scraped and passed in an ADV parameter.

Solution Step 1: Modify Shopify integration to detect specific SKU or product tag ("Cancellation") and pass flag into ADV1 parameter.

Solution Step 2: Configure Postback Control: If ADV1 equals "Early Cancellation", reject. Prevents commission without stopping data flow.

Advanced (Multiple SKUs): Custom JavaScript loops through entire cart, concatenates all SKUs into comma-separated string in ADV1. Rule: "Reject if ADV1 contains [Restricted_SKU]".

Pattern 3: Fraud Prevention With Geographic Blocking

Use Case: Block conversions from specific countries where fraud is high or business not permitted.

Postback Level: Advertiser integration passes country code into ADV5 parameter. Postback Control: If ADV5 equals "IN" (India), reject. Can list multiple countries.

Click Level: Use Targeting with Allowed Countries = US. Set Fail Traffic to "Global Fail" offer (smart link). Non-US clicks get redirected to backup monetization instead of just blocked.

Result: Two layers of defense. Blocks fraudulent conversions while still monetizing legitimate international clicks.

Pattern 4: Time-Based Payout Adjustments (Business Hours)

Use Case: Pay different amounts based on when conversion occurs (business hours vs nights/weekends).

Setup: Integration captures timestamp and extracts hour (24-hour format). Pass hour into ADV1 parameter.

Important: Use Custom Payout Settings, NOT Postback Controls. Postback Controls reject (no conversion recorded). Custom Payout Settings approve with adjusted payout. Partner still sees the conversion and can optimize.

The OR Workaround: Use "Equals Number" and list multiple hour values on separate lines (17, 18, 19, 20). Acts as OR logic for single variable.

Reporting and Visibility

After configuring Postback Controls, verify they are working correctly and track rejected conversions:

Where To See Rejected Conversions

Primary Report: Navigate to Reports, then Conversions. Filter by Status = "Rejected". Enable the "Error Message" column to see "Error Code 26: Blocked by Postback Control: [Rule Name]".

Partner View: Rejected conversions are hidden from partner standard reporting. Partners CAN see them in "Invalid" reports if they specifically look. This is different from Custom Settings ($0 payout) which ARE visible to partner as "Approved" with $0 earnings.

Advertiser Postback Report: Use this report to verify data is being passed correctly BEFORE rejection. Shows all postback attempts with ADV1-5 values. Critical for debugging "rule not firing" issues.

The Timestamp variable should only be used when the parameter &timestamp=XXX is included in the conversion pixel or postback.

Quick Tips

View Postback Control edit history in the conversion report by clicking the three vertical dots at the row end and selecting History.
Rejected conversions due to Postback Controls will show Error Code 26 and Error Message "Blocked_Postback_Control" in reporting.
Rules apply to event postbacks even when variables are not passed. If your rule requires adv1 and the postback does not include an adv1 parameter, the conversion will be rejected.
When using On Hold Conversions, you can set up a default rule if you want the hold period to apply to all conversions.

Did This Help You Today?