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.

What's Changed Last updated Sep 4, 2026 ▼

Sep 4, 2026 Added

An Offer’s Base Conversion Event can now be tied to a Global Advertiser Event, so an Event Level rule can reach base conversions across many Offers instead of only the additional events that follow them. New section: Event Level Rules And The Base Conversion.

May 18, 2026 Updated

Sub ID and Advertiser ID slots expanded from 1–5 to 1–10. Postback control rules now apply across the expanded 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.

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., 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.

AND vs OR Logic: How Rules Combine

"All Must Apply" is AND logic, and it is the default

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.

"One Or More Must Apply" is not a simple OR

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."

There is an OR workaround, for one variable only

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:

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.

What the matrix problem costs in practice

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

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" 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.

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 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.

Variable Selection Guide

ADV1, ADV2, ADV3, ADV4, ADV5, ADV6, ADV7, ADV8, ADV9, ADV10

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-10: 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 or JavaScript SDK call. 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.

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.

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.

Explore Related Content

Setting the tie up in the first place:

→ 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 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.

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.

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 once the period expires if no action is 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

Work down these before you switch any rule on. Tick them off as you go.

Step 1 · Confirm the data is actually arrivingOpen Reports, then the Advertiser Postback Report. Fire a test conversion and check your target variable, ADV1 or ADV2 and so on, really holds the value you expect. Copy that value straight out of the report rather than retyping it, because the match is case sensitive and a retyped value is where this usually goes wrong.

Step 2 · Build the test rule with the narrowest scope you canStart at Event Level, not Brand Level, so the blast radius stays small if you have got it wrong. Point it at a specific test value that live traffic will never send.

Step 3 · Fire a test conversionSend the postback by hand with Postman, cURL or the browser, using your test parameters. A test Partner account on a $0 payout works too.

Step 4 · Check the rule did what you meantOpen the Conversion Report. If the rule should reject, the status must read Rejected. If it should approve, it must read Approved. Switch on the Error Message column and you will see the reason spelled out: Error Code 26: Blocked by Postback Control: [Rule Name].

Step 5 · Check what it did NOT touchThis is the safety step people skip. Confirm only the conversions you intended were affected, and that other events such as Sign Up or Upsell came through untouched if the rule was meant to be Purchase only.

Step 6 · Try to break itTest the case variations, 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:

Rule Not Firing (Conversions Still Approved)

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".

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-10 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?