Most conflicts in performance marketing come from terms that were never written down. This page explains how Mobadly structures the commercial layer of a CPA engagement: how the KPI is defined, how caps and holds work, how conversions are validated through postbacks, and how disputed cases are resolved. The principle is simple: everything material is agreed in writing before traffic starts.
You submit the offer with vertical, GEOs, payout model and KPI definition.
Both sides confirm in writing what is billable, what is capped and what is prohibited.
A capped pilot on agreed sources with postback verification.
Sources and creatives are filtered by your approval data, not just conversion counts.
Volume grows only on cohorts that meet the agreed KPI.
The KPI is the exact event you pay for, defined precisely enough that both sides validate it identically. A weak definition — 'a deposit' — invites disputes; a strong one specifies the event (first deposit), the qualifier (of at least the agreed minimum), the user condition (new customer, target GEO), and the attribution window (within N days of the click). The KPI definition also states the data source of truth for validation — typically your system of record, reconciled with postback logs. This definition goes into the written agreement before the pilot. Changing the KPI mid-flight without written notice is not how we work; if your economics change, terms are renegotiated explicitly.
Caps limit how many conversions per day or per GEO the buyer may deliver. They exist to protect your processing capacity — call centers, onboarding, payment operations — and both sides' budgets during validation. The standard structure: a capped pilot, then stepwise increases gated by quality — volume grows only when the previous cohort passes the agreed approval checks. Caps are never a punishment; they are the mechanism that lets both sides scale with confidence. If your capacity changes, caps are adjusted in writing, not discovered from rejections.
Validation runs on two rails: your postback, which fires on the billable event and records the conversion in real time, and your system of record, which confirms the event actually stands — the deposit cleared, the order confirmed, the subscription active. Before any traffic starts, the postback is tested end to end: event fires, parameters pass, deduplication works. After launch, conversions are reconciled between postback logs and your confirmations within the agreed hold window. What we support on the tracking side — Keitaro, Everflow, Affise, TUNE, CAKE, Binom, RedTrack or in-house setups — is confirmed during onboarding.
The hold period is the time between a conversion and its final approval — the window in which you verify deposits, confirm orders, or check for fraud and refunds. Hold length depends on your validation cycle and is agreed per offer; what matters is that it is fixed, honored, and that approval data flows back per conversion so sources can be optimized. Payment schedule, methods and minimums are agreed individually and confirmed in writing — we do not publish standard payout terms, because they depend on the vertical, the model and the offer. The rule that does not move: approved conversions are paid on the agreed schedule, and rejections always come with a reason.
Disputes are handled against logs, not opinions. When you reject a conversion, the case is reviewed against both sides' data: postback parameters, timestamps, user identifiers, and your rejection reason. If the rejection is valid — fraud, duplicate, unmet qualifier — the source absorbs it and is filtered accordingly. If the rejection contradicts the agreed validation rules, the case is escalated and resolved against the written terms. Systematic disagreement is a signal to revisit the KPI definition together, not to accumulate silent rejections. This process exists so that quality control never becomes a hidden discount.
Reports, postbacks and disputed conversions are handled against written KPI terms and logs on both sides. Payout models, schedules and hold periods are agreed individually per offer and confirmed in writing before traffic starts.
The event, its qualifiers (minimum deposit, new customer, GEO), the attribution window, and the data source of truth for validation. Precise definitions prevent most disputes before they exist.
You set a daily or per-GEO limit for the pilot; volume scales stepwise as cohorts pass your approval checks. Cap changes are agreed in writing — you never discover a cap change from rejected conversions.
The window between conversion and final approval, during which you validate the event — deposits clear, orders confirm, fraud checks run. Its length depends on your validation cycle and is fixed in the agreement.
Through your postback (real-time event recording) reconciled with your system of record (confirmed deposits, orders, subscriptions) within the hold window. Postback correctness is tested before launch.
Payment schedule, methods and minimums are agreed individually per offer and confirmed in writing. The fixed rule: approved conversions are paid on schedule, and every rejection comes with a stated reason.
Against logs from both sides: postback parameters, timestamps, identifiers and your rejection reason. Valid rejections filter the source; rejections contradicting the written terms are escalated and resolved against the agreement.
Only by explicit written agreement. If your economics change, terms are renegotiated before they apply — never retroactively.
Keitaro, Everflow, Affise, TUNE (HasOffers), CAKE, Binom, RedTrack and in-house postback setups. Compatibility for anything else is confirmed during onboarding.
Short brief — we reply through your messenger.