.svg){kind=icon}
Overview
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.
adv1–adv10 range. Existing rules that reference adv1–adv5 continue to work unchanged; new rules can target adv6–adv10 the same way.This guide covers rule configuration, logic patterns, variable selection, testing workflows, and troubleshooting common issues.
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., ADV1-10, Sale Amount, Order, Timestamp, Email).
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.
When you add multiple conditions to a single rule, every condition must be true before the rule fires. That is standard AND logic, and it is where most surprises come from.
Example: Reject if Sale Amount > 100 AND State = NY
Result: Only rejects conversions that are both over $100 and from New York.
Passes a $150 sale from Florida, because the State condition fails.
Passes a $50 sale from New York, because the Amount condition fails.
Rejects a $150 sale from New York, because both conditions are true.
The matrix problem. As soon as you need State plus Amount plus Time together, AND logic makes you build a separate rule for every valid combination. 50 states, 3 amounts and 3 time bands is 450 rules.
The misconception: the name suggests OR logic. It does not behave that way.
What actually happens: "One Or More Must Apply" still applies AND logic within each condition. What changes is which action the rule takes, reject or approve or hold.
A customer asked:
"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 answered: "There isn't currently a function that we have that can do that."
You can get OR behaviour, but only across values of a single variable, never across different variables. A customer found this one.
Goal: lower payouts for leads arriving at 5 PM, 6 PM or 7 PM.
How: choose the comparison method Equals Number, then list the values on separate lines:
- 17
- 18
- 19
- 20
Result: that behaves as OR for that one variable, so ADV1 equals 17 or 18 or 19 or 20.
The limit. This only works on a single variable. You cannot express multi-variable OR such as (ADV2=1 OR ADV3=1) AND State=NY. That still needs separate rules.
A real customer wanted payouts based on Debt Amount, State and Time of Day together. Because each rule is AND, they needed one rule per combination:
- NY + High Debt + Morning
- NY + High Debt + Afternoon
- NY + Low Debt + Morning
- CA + High Debt + Morning
- and hundreds more
Their Account Manager: "It gets managed. I wouldn't want to manage that personally."
They called it building a "big matrix" and asked to map 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
Only pay affiliates for initial purchase, NOT subscription renewals from Stripe/PayPal. Set rule to reject if Sale Amount equals $29.00 (renewal price).
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.
Lead Quality Filtering
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).
Wanted "Qualified" OR "Jumbo" loans. Discovered OR logic not possible for multiple variables without workaround.
Business Hours Restrictions
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.
On Hold Conversions
Weight loss clinic - patients pay upfront but must pass provider review. Hold conversion until doctor approves. If rejected, no clawback needed.
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.
Fraud Prevention
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.
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).
Duplicate Prevention
Enable "Reject Duplicate Conversion Order ID" in your account settings. This applies account-wide and cannot be scoped to individual offers. System automatically rejects any conversion with duplicate order_id value.
Pass Falcon CRM Lead ID into Order ID field. Enable duplicate rejection to prevent double payment when CRM fires update webhooks for same lead.
Geographic Restrictions
Only sells insurance in Florida - needed to disqualify Georgia traffic. Used Targeting (Allowed Region = Florida). Traffic outside region sent to Fail Traffic.
Hold leads from certain states for manual review while auto-approving others. Set conversions from specific state to "pending" status for approval workflow.
Product/SKU Restrictions
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.
Custom JavaScript loops through cart, concatenates all SKUs into string, passes to ADV1. Rule: "Reject if ADV1 *contains* [Restricted_SKU]".
Choosing The Right Variable
Postback Controls can ONLY evaluate data passed in the conversion postback URL or JavaScript SDK call. You must select the correct parameter type and ensure data is being passed correctly. The variables you can build a rule on are Adv1 to Adv10, Amount, Order, Timestamp, Email and Custom. Partner sub values are set on the click and are not available to Postback Controls.
When Populated: On conversion postback (server-to-server or pixel)
Common Uses: Status flags, email addresses, demographics, quality scores, product types
ADV2: Email address or secondary identifiers
ADV3-10: Demographics (age, income, debt amount)
Common Uses: Minimum order value rules, revenue thresholds, zero-dollar blocking
• "Reject conversions if order value is less than $50"
• "Only count FTDs over $9.99"
• "Block $0 postbacks"
Common Uses: LTV tracking (User ID), event-specific data, specialized integrations
• 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.
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.
• All offers under this brand
• All event types (Base, Upsell, Renewal, Sign Up, etc.)
• All partners
• All geographic regions
• Selected event(s) only (Purchase, Upsell, Renewal, etc.)
• All offers that use this event
• All partners
• Single offer only
• All events on that offer
• All partners on that offer
Event Level Rules And The Base Conversion
Look at the Event Level card again. A rule there applies to the event you choose, across every Offer that uses it. That reach is exactly why it is the recommended scope, and it is why the Advertiser Level Event is the unit worth building rules against.
There used to be a hole in that. Only the additional events that fire after a conversion could be attached to an Advertiser Level Event. The base conversion, which is usually the sale or the qualified lead and therefore the thing you most want a rule on, could not be. So an Event Level rule could never reach a base conversion. If you needed one, you dropped to Offer Level and repeated it per Offer, which is precisely the management risk the Offer Level card warns about.
That hole is now closed. A base conversion can be tied to an Advertiser Level Event from the Offer form, or across many Offers at once in Bulk Edit. Once tied, an Event Level rule aimed at that Advertiser Level Event governs the base conversion on every Offer tied to it.
Take the Lead Quality Filtering example from earlier on this page, where you only accept a lead once the CRM reports it as paid. If that check belongs on the base conversion and the Advertiser runs twenty Offers, you used to write that rule twenty times at Offer Level. Tie all twenty base conversions to one Advertiser Level Event, name it something like Qualified Lead, and it collapses into a single Event Level rule.
The practical difference
Launching a new Offer no longer means remembering to copy a rule onto it. Tie its base conversion while you are creating the Offer and the rule you already wrote covers it from the first conversion. The rule you never have to remember is the rule that never silently goes missing.
Two things worth checking before you rely on this. The tie is set on the Offer, not in Postback Controls, so if a rule is not firing where you expect, confirm the Offer’s base conversion is actually tied. And an Advertiser Level Event can only be used once per Offer, so if it is already assigned to one of that Offer’s additional events you will not be able to tie the base conversion to the same one.
→ How To Create & Assign Advertiser Level Events, for creating the event and tying it on one Offer.
→ How To Bulk Edit Offers, for tying the base conversion across many Offers in one pass.
→ How To Set Up Conversion Events, for where the switch sits on the Offer form.
Setting Up Postback Controls
Navigate to
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 |
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 once the period expires if no action is taken.
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.
Work down these before you switch any rule on. Tick them off as you go.
Error Code 26: Blocked by Postback Control: [Rule Name].Paid against paid against PAID. Test an empty value, where the parameter is not passed at all. Test partial matches if you are using Contains, and test the boundary values on any numeric comparison.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:
1. Data Not Being Passed In Postback
Postback Controls can ONLY see data in the postback URL or JavaScript SDK call. 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".
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.
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.
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 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.
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 (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:
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.
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]".
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.
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:
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-10 values. Critical for debugging "rule not firing" issues.
The Timestamp variable should only be used when the parameter ×tamp=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.
