The Complete Guide to Pay-Per-Call for Publishers

Pay-per-call can be an attractive monetization model because the publisher is paid for a phone-based performance event rather than an impression or click.

That simple description leaves out most of the work.

A serious publisher is not merely placing a phone number on a page and waiting for a payout. The publisher is operating a traffic source, shaping a consumer journey, passing routing data, working within buyer capacity, managing source labels, documenting acquisition methods, investigating rejected calls, reviewing payout reports, and deciding whether a buyer or intermediary is dependable enough to scale.

The difference between a source that earns consistently and one that creates constant disputes is usually operational clarity.

A publisher should know:

• What kind of caller the source produces.
• What the consumer saw, heard, or agreed to before calling.
• Whether the call is consumer-initiated or transferred.
• Which source, sub-source, campaign, creative, and landing page produced it.
• Which qualification and duplicate rules apply.
• How a ping becomes a bid, reservation, route, connected call, and payable event.
• Why a call was rejected or excluded.
• Which records support a dispute.
• How a payout report ties back to call-level activity.
• When payment is due and how adjustments are handled.
• Whether the buyer has the capacity, reporting discipline, and financial reliability to support more volume.

This guide covers the full publisher journey, from packaging the first source through reconciling the final payout.

It is written for media buyers, affiliate publishers, owned-and-operated website publishers, agencies, transfer operations, call generators, and traffic owners. It is educational, not legal advice, compliance advice, privacy advice, or a substitute for reviewing a specific campaign with qualified counsel.

Table of contents

• What pay-per-call means for a publisher
• Key publisher definitions
• How publishers generate and monetize calls
• Consumer-initiated inbound calls versus transfers
• Duration-based and CPA payout models
• Sources, sub-sources, campaigns, creatives, and landing pages
• Package traffic before asking for volume
• Understand buyer qualification rules
• Pings, bids, reservations, live calls, and routing
• Why calls and pings get rejected
• Caps, schedules, geography, concurrency, and capacity
• Caller ID and duplicate rules
• Source-level reporting and optimization
• Call recordings and quality assurance
• Traffic applications and source review
• Documentation buyers may request
• Publisher privacy and scoped transparency
• Payout reports, disputes, and adjustments
• Payment terms and reconciliation
• Scaling without damaging quality
• Warning signs of an unreliable buyer or intermediary
• Publisher-readiness assessment
• Traffic-package template
• Technical integration checklist
• First-campaign checklist
• Payout-report checklist
• Buyer-evaluation scorecard
• How Dependable Calls approaches publisher operations
• Frequently asked questions

What pay-per-call means for a publisher

Pay-per-call is a performance model in which a publisher earns when a phone call meets an agreed commercial condition.

The trigger might be a call arriving, connecting, reaching a duration, passing qualification, receiving an RTB bid, or producing a later CPA event such as an appointment, sale, enrollment, or signed case.

The label pay-per-call does not explain whether IVR or hold time counts, duplicates earn, disputes can reverse payment, conversion reporting is required, bids vary, the source is approved for every buyer, or the campaign has capacity when the call arrives. Those details determine value.

Evaluate a campaign at two levels:

1. Traffic economics: Can the source acquire calls at a sustainable cost?
2. Operating economics: Can the calls be accepted, routed, explained, qualified, reconciled, and paid under the actual rules?

A high advertised payout can underperform when bid coverage is low, hours are narrow, duplicate exclusions are broad, capacity is unstable, or reporting is weak. A lower payout may be more valuable when the buyer answers reliably, provides useful reasons, keeps rules consistent, and pays on time.

The payout matters. The operating system around it often matters more.

Key publisher definitions

These terms should remain separate.

A call can route without connecting, connect without qualifying, or qualify without becoming payable because another rule applies. For a deeper status breakdown, read the difference between a routed call, a qualified call, and a billable call.

How publishers generate and monetize calls

Publisher models include owned websites, paid search, social advertising, organic search, offline media, agencies, transfer operations, affiliate networks, and relevant existing audiences. The method matters because it determines consumer expectation, attribution, review materials, and risk.

A typical commercial flow is:

1. Select an offer or buyer relationship.
2. Review call type, geography, hours, payout, and restrictions.
3. Submit the source for review.
4. Configure numbers, RTB credentials, tags, or routing.
5. Launch a controlled test.
6. Send pings or calls.
7. Route accepted calls to eligible demand.
8. Record call events and downstream outcomes.
9. Apply qualification, duplicate, dispute, and adjustment rules.
10. Reconcile the payout report and payment.

Publishers should monitor bid rate, route rate, connection rate, short calls, duplicates, disputes, payable rate, conversion feedback, source earnings, and payment timing. The job is not finished when media launches; it includes understanding what happened after every call entered the system.

Consumer-initiated inbound calls versus transfers

These call types should be reviewed and reported separately.

Consumer-initiated inbound calls

The consumer chooses to dial or tap after seeing or hearing marketing. The publisher may control the keyword, audience, advertisement, landing page, call-to-action, tracking number, and attribution tags.

Potential strengths include direct attribution and strong intent when the marketing matches the buyer’s service. Risks include misleading creative, accidental calls, wrong-service calls, attribution failures, and the assumption that inbound automatically means compliant.

The FTC’s Telemarketing Sales Rule guidance explains that interstate campaigns may be subject to the TSR whether a business makes outbound calls or receives calls in response to advertising. Exemptions and exceptions depend on the facts. A consumer’s act of dialing is not a universal legal safe harbor. The FTC also states that advertising claims must be truthful, not deceptive or unfair, and evidence-based in its advertising and marketing guidance.

Transfers

A transfer includes an upstream interaction before the buyer receives the caller. It may use an agent, IVR, lead form, verification step, warm introduction, or blind handoff.

A controlled transfer can confirm geography, language, or need. A weak transfer can create script drift, confusing handoffs, long holds, recycled records, incentive problems, or consumers who do not understand the destination.

Confirm the accepted transfer method, sourcing, script, qualification steps, handoff language, data passed, and fallback when the buyer does not answer. See consumer-initiated inbound calls versus transfers and why live transfers and consumer-initiated inbounds have different risk profiles.

Duration-based and CPA payout models

Two common models are duration-based and CPA-based.

Duration-based payout

Confirm which leg is measured, when timing begins, whether IVR, hold, ringing, or voicemail counts, how rounding works, and which exclusions override duration. A duplicate or unapproved source may remain non-payable even after reaching the threshold.

Duration is a settlement rule, not proof of intent. A weak call can run long, and a strong call can end just before the threshold.

CPA payout

Confirm the exact event, reporter, matching identifier, normal lag, cutoff, pending status, reversal rule, evidence standard, and treatment of late outcomes. CPA can work well when reporting is disciplined; it becomes difficult when the publisher receives an unexplained conversion file weeks later.

Read duration-based call buying versus CPA call buying and how settlement changes between CPA and duration-based calls.

Sources, sub-sources, campaigns, creatives, and landing pages

A publisher should decide how traffic will be identified before the first meaningful test.

Hypothetical example: A publisher combines three owned websites, two paid-search accounts, and one transfer partner under the label Plumbing. The blended source shows a 28% payable rate. After separating the traffic, one owned site shows 72%, another 51%, paid search 34%, and the transfer partner 8% with a high dispute rate.

The original label did not describe a source. It hid six different businesses.

Source labels should be stable, human-readable, unique enough to avoid collisions, specific enough to support decisions, free of consumer PII, and consistent between pings, call records, reports, and payout files. A publisher should also govern who may create or change a sub-source so traffic cannot silently change identity.

Do not place raw phone numbers, email addresses, consumer names, or sensitive data in source labels. Do not use a label that exposes a confidential buyer relationship to unrelated partners.

For more on clean packaging, read why publishers benefit from cleaner source packaging.

Package traffic before asking for volume

A traffic package is the publisher’s operating description of a source. It should tell a buyer or intermediary enough to evaluate fit without requiring the publisher to disclose every proprietary detail.

A strong package includes:

• Vertical and consumer need.
• Call type and acquisition method.
• Source and sub-source structure.
• Geographic footprint and hours.
• Expected test volume and clearly labeled mature-volume estimate.
• Creative, script, landing-page, or consumer-path examples.
• Caller-intent description and known exclusions.
• Technical delivery method and reporting identifiers.
• Appropriate compliance and review materials.
• Historical performance with period, sample size, and definitions.
• Limitations or uncertainties.
• Named quality and technical contacts.

Avoid vague claims such as exclusive, high intent, fully compliant, no duplicates, unlimited scale, or direct source. Each needs a definition and evidence.

For example, direct might mean the publisher owns the media account, contracts directly with a transfer center, or merely has one intermediary between it and the source. Those are different arrangements.

The focused preparation process is covered in how to prepare your traffic for buyer review.

Understand buyer qualification rules

A publisher cannot optimize toward a rule it does not understand. Before launch, request the written call specification.

It should cover:

• Accepted call type, vertical, product, intent, language, and geography.
• Schedule and time zone.
• Duration or CPA condition.
• Duplicate identity key and lookback window.
• Existing-customer and wrong-number treatment.
• Agent, IVR, or transfer-introduction requirements.
• Prohibited sources or methods.
• Recording and QA policy.
• Dispute reasons, evidence, and window.
• Payout rate or bid logic.
• Payment terms.
• Rule-change process.

A buyer qualification rule is not the same as routing eligibility. A call may fit the buyer’s product but fail routing because the buyer is closed, a state is disabled, a cap or concurrency limit is reached, the source is paused, or the bid expired. That is not automatically a traffic-quality failure.

Likewise, a call can route successfully and still be a poor fit. Good reporting separates those causes.

The companion buyer perspective is available in the complete guide to pay-per-call for buyers.

Pings, bids, reservations, live calls, and routing

Publishers can deliver through static routes or RTB.

Static delivery

The consumer calls a tracking number, the campaign evaluates available targets, and the call routes to an eligible destination. Static delivery is simple, but the publisher may not know before the call whether live demand exists.

Pre-call RTB

A common flow is:

1. The publisher sends allowed metadata in a ping.
2. The buyer or exchange evaluates fit and capacity.
3. A bid or no-bid is returned.
4. An accepted bid provides a temporary route or reservation.
5. The publisher sends the live call before expiration.
6. The reservation is validated and the call routes.
7. Qualification and payout rules are applied.

Ringba’s RTB setup guide documents controls such as required caller ID, expiration, rate limits, payout events, duplicate treatment, tags, and modifiers. Its RTB FAQ describes responses containing the amount, expiration, route, and duplicate settings, plus error codes for failed bids.

A bid is not a permanent promise. It can expire; a reservation may be single-use; the live call can fail to match the ping; and buyer capacity can change before arrival.

Live-call routing

When the call is already in progress, decisions must happen quickly enough to avoid holds, dead air, or abandonment. Confirm whether the integration uses a pre-call ping, live-call ping, static DID, SIP, RTB pass-through, or fallback path.

Read what happens between a publisher ping and a buyer call and live-call routing versus a pre-call ping.

Why calls and pings get rejected

A rejection should have a reason the publisher can act on.

Reporting should distinguish no-bid, ping rejection, accepted bid, expiration, call not received, routing rejection, buyer no-answer, caller abandonment, connected non-qualified, payable, disputed, adjusted, and paid.

Bad call is not a useful code. Neither is did not convert when the commercial model pays on duration. See why good call publishers still get rejected calls and what breaks in pay-per-call routing and how to diagnose it.

Caps, schedules, geography, concurrency, and capacity

These controls are related but not interchangeable.

• Cap: A maximum number of calls, events, pings, or spend units in a period. Confirm what is counted and when it resets.
• Schedule: The target’s eligible hours. Confirm time zone, weekends, holidays, split shifts, and what happens near closing.
• Geography: The accepted service area. Confirm whether routing uses caller area code, supplied state, ZIP, service location, or another signal when values disagree.
• Concurrency: The simultaneous calls a target can handle. A buyer can be open and under its daily cap but have no free slot.
• Capacity: The combined reality of agents, answer speed, skills, product availability, routing, technology, and management.

Publishers should watch for no-bid clusters, increased hold time, buyer no-answer, and a gap between nominal caps and usable capacity. Volume should follow live capacity, not stated appetite. Read how caps, schedules, and concurrency shape call flow.

Caller ID and duplicate rules

Caller ID is operationally important and sensitive. It can support duplicate detection, geographic enrichment, bid caching, fraud review, call matching, conversion attribution, and dispute investigation. It should not be copied casually into spreadsheets, source labels, chat threads, or external tools.

The campaign should specify:

• Whether caller ID is required at ping time.
• The accepted format, commonly E.164.
• Whether the same caller ID must arrive on the live call.
• How blocked or anonymous caller ID is handled.
• Whether caller ID is the only duplicate key.
• The duplicate lookback window.
• Whether rules vary by buyer, target, source, campaign, or vertical.
• Whether a duplicate receives zero bid, no bid, another route, or a non-payable connection.

Ringba’s tracking-number documentation describes tracking numbers as attribution and routing tools. Its duplicate-routing documentation shows that duplicate handling can be configured at multiple levels, so publishers should ask where the authoritative decision occurs.

A usable duplicate rule answers: duplicate of what, identified how, across which campaigns, over what period, whether unanswered or non-payable prior calls count, and whether a false match can be challenged.

Read why caller-ID matching matters in call routing and why duplicate policies matter in call campaigns.

Source-level reporting and optimization

A publisher should not optimize from an account-level payout total. Useful reporting begins at the call level and rolls up through the source hierarchy.

Publisher-facing fields may include call ID, date and time, source, sub-source, campaign, call type, ping ID, bid ID, publisher payout, bid expiration, route result, rejection code, connected status, publisher-relevant duration, payable status, duplicate status, dispute status, CPA status, adjustment, and payout batch.

Useful source metrics include:

• Pings, bid rate, and average bid.
• Calls placed after a bid.
• Route and connection rate.
• Buyer answer time and caller abandonment.
• Average connected duration.
• Qualified and payable rate.
• Duplicate and dispute rate.
• CPA conversion rate and reporting lag.
• Earnings per call, ping, and media dollar.
• Payment aging.

The denominator must be clear. Conversion rate can mean conversions divided by pings, calls, routed calls, connected calls, qualified calls, or payable calls. Each tells a different story.

Ringba’s reporting-tag documentation reflects a common call-tracking pattern: tags make operational dimensions available in reporting. Decide which dimensions matter before launch rather than reconstructing them later.

Read why source-level reporting matters for publishers.

Call recordings and quality assurance

Recordings can help confirm intent, review transfer introductions, diagnose dead air, separate buyer handling from source quality, investigate prohibited claims, validate disputes, and train teams.

They also create legal, privacy, retention, and access obligations. A publisher should not assume that because a platform can record a call, every party may listen, download, store, or redistribute it.

A recording policy should address:

• Which calls are recorded and which law applies.
• How notice or consent is handled.
• Who may access a recording.
• Whether access is streamed or downloadable.
• Whether access is logged.
• Retention and deletion.
• Training use.
• Source-review samples.
• Consumer PII protection.

Ringba’s official call-recording documentation is one example of recording as an explicit campaign feature rather than an invisible assumption.

Publishers should ask for enough QA feedback to improve a source without demanding unrestricted buyer-private information. Useful feedback includes wrong service, confused caller, existing customer, unsupported geography, language mismatch, buyer no-answer, excessive delay, script deviation, duplicate, and low intent.

Read call recordings, consent, and QA: what operators need to think through.

Traffic applications and source review

A traffic application is a structured request to evaluate a source for a campaign. It should ask who controls the source, how traffic is acquired, what the consumer experiences, whether the source is direct or aggregated, which call type and geography apply, which creative or script is used, what volume is realistic, what controls exist, and who owns quality issues.

Possible outcomes include:

• Approved for a limited test.
• Approved with restrictions.
• Approved for specified targets only.
• Pending documentation.
• Pending technical validation.
• Rejected.
• Suspended after launch.
• Approved but not currently offered because buyer fit is unavailable.

Approval is not a guarantee of routing, volume, payment, or continued eligibility. It means the source passed the current review threshold for a stated use.

Read how traffic applications can improve call quality and why creative and landing-page review matters for inbound calls.

Documentation buyers may request

Documentation varies by vertical, call type, law, contract, and buyer policy.

A publisher should verify requests before transmitting sensitive material. Banking or payee changes should use a secure process and independent verification; an email alone should not be treated as sufficient proof.

A buyer requesting relevant documentation is not automatically unreasonable. A buyer requesting everything without a stated purpose or security process may be.

Publisher privacy and scoped transparency

Responsible transparency means giving enough information to review the source, protect consumers, operate routing, and reconcile money without surrendering the publisher’s entire business.

Usually appropriate to provide

• Legal identity to the contracting party.
• Traffic type, ownership or control model, and acquisition method.
• Stable source identifiers.
• Relevant creatives, landing pages, and scripts.
• Geography, hours, volume expectations, and technical details.
• Compliance-process descriptions.
• Performance data with period, sample size, and definitions.
• The contact responsible for quality.
• Evidence needed for a specific dispute.
• Tax and payment information through a secure authorized process.

Usually limit, redact, pseudonymize, or withhold unless necessary

• Raw caller phone numbers or full consumer lists.
• Recording URLs sent through unsecured channels.
• Consumer health, financial, identity, or contact data unrelated to the task.
• Buyer destinations, private buyer contracts, and unrelated buyer names.
• Complete media plans, keywords, bids, margins, or unrelated source identities.
• Credentials, tokens, API secrets, and private keys.
• Records outside the agreed purpose or retention period.

Hypothetical example: For an owned insurance site, the publisher can provide the source label, relevant ads and landing page, states, hours, source-level history, change-control process, and lawfully available redacted samples. It need not expose every property, its full search account, raw caller data, unrelated buyers, destination numbers, spend, or margin.

Dependable Calls’ source-enablement direction follows this balance. The exchange decides which reviewed sources to offer, and the buyer decides which offered sources to enable for a target. The buyer can receive useful source material without automatically receiving the publisher’s private identity or unrelated relationships.

Read what source enablement means in pay-per-call.

Payout reports, disputes, and adjustments

A payout report should explain the publisher’s earnings rather than show only a total.

At minimum, it should identify the publisher, reporting period, time zone, campaign, source, sub-source, call or event ID, date, payout model, applied rate or bid, qualification result, payable result, duplicate result, dispute status, adjustment, batch, payment status, and expected or actual payment date.

Disputes

A serious process defines allowed reasons, submission deadline, evidence, whether the amount is held, who reviews it, whether the publisher may respond, decision deadline, resolution states, adjustment treatment, and escalation path.

Potential reasons include wrong geography, wrong service, invalid transfer, duplicate under the written policy, technical routing failure, prohibited source, evidence-supported fraud, or failure to reach the stated event.

Did not sell is not automatically a valid dispute on a duration campaign. Bad quality is not a complete reason.

Adjustments

Adjustments should be append-oriented and explainable. A report should not silently delete a call that appeared payable yesterday. It should preserve the original result, adjustment, reason, date, and resulting balance.

Read how disputes should work in a serious pay-per-call operation and what publishers should expect in a payout report.

Payment terms and reconciliation

Terms may be weekly, biweekly, semimonthly, monthly, Net-7, Net-15, Net-30, after buyer funds clear, or a hybrid. The agreement should define the reporting period, approval date, due-date calculation, weekends and holidays, minimum threshold, currency, method, fees, reserve, dispute cutoff, late CPA treatment, negative adjustments, and responsibility when an underlying buyer pays late.

Publisher reconciliation workflow

1. Confirm the period and time zone.
2. Match call IDs to internal records.
3. Compare source and sub-source counts.
4. Match accepted bids to live calls.
5. Compare connected durations or CPA outcomes.
6. Identify duplicates.
7. Review disputes and holds.
8. Confirm adjustment reasons.
9. Recalculate expected payout.
10. Compare it with the report.
11. Confirm the due date.
12. Match payment to the approved amount.
13. Carry unresolved differences in an exceptions log.

Reconciliation is not distrust. It is how serious operators maintain trust at scale.

Read why finance visibility builds trust between buyers and publishers.

Scaling without damaging quality

Scaling should follow evidence rather than begin with the largest possible cap.

Stage 1: Technical validation

Send test pings, validate fields and bid parsing, confirm expiration, place controlled calls, verify source labels, and confirm call and payout records appear.

Stage 2: Small live sample

Limit volume, run during staffed hours, use approved sources, review every rejection category, examine a lawful QA sample, and confirm payout math.

Stage 3: Source-level expansion

Increase the strongest source, keep weak sources capped, test one change at a time, and add geography or hours only when capacity supports it.

Stage 4: Operational scale

Add demand deliberately, preserve source identity, automate reporting and reconciliation, alert on bid, answer, duplicate, and dispute changes, maintain pause controls, review payment aging, and revalidate creatives and scripts.

Before scaling, watch bid coverage, route rate, answer rate, abandonment, connected duration, payable rate, duplicate rate, dispute rate, CPA lag, payout accuracy, payment timeliness, complaints, and source mix.

A source can look stable at 10 calls per day and fail at 100 because the media mix changes, the buyer reaches capacity, a sub-publisher is added, or QA cannot keep up. Not every source should scale.

Warning signs of an unreliable buyer or intermediary

Publishers should evaluate demand as carefully as buyers evaluate traffic.

Commercial and financial warnings

• Payout is quoted without a written payable rule.
• Terms change after delivery.
• Duplicate or CPA definitions are vague.
• Payment depends on unspecified approval.
• No written schedule, dispute window, or remittance detail exists.
• Calls disappear instead of appearing as adjustments.
• Payment dates are repeatedly missed.
• Exclusivity is requested without dependable capacity.
• The payer does not match the contract.

Operational warnings

• No controlled test or rejection codes.
• No source-level reporting.
• Frequent buyer no-answer or calls accepted while closed.
• Buyer hold time is blamed on the publisher.
• Integrations change without notice.
• The operator cannot locate a call by ID.
• Different employees apply different rules.
• No named owner exists for quality, technical issues, or finance.

Compliance, privacy, and security warnings

• The buyer does not care how calls are generated.
• The publisher is asked to hide or mislabel the source.
• Misleading creative is encouraged.
• Raw consumer data is requested without a purpose.
• Recording links, credentials, or destination numbers are shared casually.
• Payee instructions are changed through an unverified email.

A dependable relationship does not require zero exceptions. It requires explainable exceptions and a process for fixing them. See what serious publishers should look for in a pay-per-call buyer.

Publisher-readiness assessment

Score each item from 0 to 2: 0 means unavailable, 1 means partial or inconsistent, and 2 means documented and operational.

Interpretation:

• 31–36: Operationally ready for a controlled test, subject to campaign-specific review.
• 23–30: Promising, but close the most important gaps first.
• 14–22: Traffic may exist, but the operation is not yet buyer-ready.
• 0–13: Do not scale. Build controls and records first.

A high score does not guarantee acceptance, routing, payment, or compliance.

Traffic-package template

Publisher and source

• Legal name:
• Source name and sub-source structure:
• Source owner or controller:
• Direct, aggregated, or mixed:
• Quality, technical, and finance contacts:

Traffic profile

• Vertical and consumer need:
• Call type and acquisition channel:
• Geography, language, hours, and time zone:
• Expected test volume and estimated mature volume:
• Seasonality and known exclusions:

Consumer journey

• Creative summary and landing-page sample:
• Call-to-action:
• Form or consent step, if applicable:
• Transfer script and handoff, if applicable:
• What the consumer expects when answered:
• Complaint and opt-out handling:

Technical delivery

• Static DID, SIP, pre-call RTB, live-call RTB, or other:
• Required fields and source tags:
• Caller-ID format:
• Bid timeout and reservation handling:
• Retry, webhook, or postback needs:
• Test environment and monitoring contact:

Commercial rules

• Payout model and rate or bid basis:
• Duration rule or CPA event:
• Duplicate policy:
• Dispute reasons and window:
• Payment terms, minimum, and holdback:
• Rule-change notice:

Evidence and review

• Current creatives, pages, and scripts:
• Sample-call availability:
• Historical period, sample size, and definitions:
• Compliance materials:
• Known limitations and requested test conditions:

Technical integration checklist

Before coding

• Obtain the current specification and environment.
• Confirm authentication, allowed IPs, fields, formats, timeout, rate limits, response schema, and errors.
• Confirm caller-ID, duplicate, expiration, reservation, destination, idempotency, webhook, and retry behavior.
• Confirm who owns integration support.

During implementation

• Validate fields before sending.
• Use stable request IDs and preserve ping, bid, reservation, and call IDs.
• Log status without PII or secrets.
• Separate no-bid, timeout, rejection, and technical error.
• Reject stale bids and prevent reservation reuse.
• Normalize phone numbers and preserve source tags.
• Protect credentials in a secret store.
• Test clock boundaries, retries, duplicate pings, duplicate calls, missing fields, unsupported geography, closed buyers, caps, and fallback routing.
• Confirm reporting receives the same identifiers.

Before live traffic

• Complete end-to-end test calls.
• Confirm consumer experience, buyer answer, source attribution, qualification, and payout calculation.
• Confirm recording-access rules, pause controls, escalation contacts, and that no production secrets appear in logs or screenshots.

First-campaign checklist

Source and consumer

• Source and call type approved.
• Creative, script, or landing page reviewed.
• Consumer expectation matches buyer service.
• Geography, hours, and source labels confirmed.
• Privacy and compliance questions reviewed with appropriate counsel.

Buyer and routing

• Qualification, duplicate, schedule, cap, and concurrency rules are written.
• Rejection codes and buyer no-answer handling are confirmed.
• Overflow or no-bid behavior is confirmed.
• Source is enabled only for approved call paths.

Commercial and finance

• Payout model, rate, disputes, terms, and report fields are confirmed.
• Tax and payment onboarding is completed securely.
• Reconciliation owner and first expected payout date are known.

Launch

• Test pings and calls pass.
• IDs reconcile across systems.
• Monitoring is active.
• Initial volume is conservative.
• Pause authority and first-week review are scheduled.

Payout-report checklist

A payout report should answer what earned, what did not, why, and when payment is due.

• Publisher, period, time zone, and generation date.
• Campaign, source, sub-source, call or event ID, and timestamp.
• Payout model, applied rate or bid, and relevant duration.
• Qualification, payable, duplicate, CPA, and rejection status.
• Dispute, adjustment amount, and adjustment reason.
• Payout batch, status, terms, due date, paid date, and remittance reference.
• Export format and exceptions contact.

Buyer-evaluation scorecard

Score each category from 1 to 5.

Decision bands:

• 4.5–5.0: Strong candidate for measured expansion.
• 3.8–4.4: Suitable for a controlled test.
• 3.0–3.7: Test with tight caps and corrective conditions.
• 2.0–2.9: Resolve material gaps before meaningful volume.
• Below 2.0: Do not launch.

The scorecard is a decision aid, not a guarantee.

How Dependable Calls approaches publisher operations

Dependable Calls is building a controlled, operator-led, beta-stage pay-per-call exchange around the idea that serious publishers need more than a buyer list.

They need:

• A practical way to package traffic.
• Clear source and sub-source identity.
• Clean technical integrations.
• Buyer rules understood before launch.
• Useful rejection and performance feedback.
• Source-level reporting.
• Scoped access to QA evidence.
• Dispute and adjustment records.
• Publisher-facing payout detail.
• Reconciliation that can be explained.

The current software implementation includes publisher-side call, RTB, reporting, recording-access, dispute, ledger, and payout workflows. Those capabilities remain subject to live validation, infrastructure readiness, operational adoption, and continued hardening. Code and automated tests do not prove that every workflow is mature or in live use.

Dependable Calls is not designed as an unrestricted marketplace where every source automatically reaches every buyer.

The source-enablement model is two-gate:

1. Dependable Calls determines which reviewed sources are appropriate to offer to a buyer.
2. The buyer determines which offered sources to enable for a specific target or call path.

Both gates must be satisfied before a curated source routes.

This protects buyer choice while preserving operator oversight and publisher privacy. The goal is not to promise that every source will be accepted, every call will route, every call will earn, or every campaign will scale. The goal is cleaner call operations: buyer-ready traffic, deliberate review, explainable call flow, and payout records a publisher can reconcile.

Frequently asked questions

How much can a publisher earn?

There is no universal answer. Model net earnings by source using acquisition cost, bid coverage, payable rate, duplicate and dispute rates, conversion lag, and payment timing—not the headline payout alone.

Do I need a website?

Not always. Approved sources may include websites, paid or offline media, agencies, transfer operations, or other explainable acquisition paths.

Are consumer-initiated calls automatically compliant?

No. Inbound describes direction, not compliance. Advertising, solicitation, consent, recording, state law, vertical rules, and the full journey can matter. Obtain qualified legal advice.

Is a transfer better than an inbound call?

Not automatically. A controlled transfer can improve matching; a poor one can create confusion. An inbound can show intent; misleading creative can still create risk.

What belongs in an RTB ping?

Only required and permitted fields. Validate the schema, authentication, timeout, and data-minimization requirements. Do not send unnecessary PII.

Does a bid guarantee payment?

No. Expiration, reservation mismatch, no connection, duplicates, source approval, and the payable condition can still affect the outcome.

Why did a real caller not earn?

Real is not the same as payable. The caller may be outside geography, duplicated, unsupported, late after bid expiration, from an unapproved source, short of duration, or missing the CPA event. Reporting should identify the reason.

Should publishers receive recordings?

Only when law, contract, privacy controls, and operational need allow it. Limited audited access or scoped QA feedback may be more appropriate than unrestricted downloads.

What is a fair dispute window?

It depends on the model and evidence timing. Define it before launch, apply it consistently, and pair it with allowed reasons and a decision deadline.

What happens when a rule changes?

Material changes should be documented, dated, communicated before application, and reflected in routing and settlement. Avoid retroactive treatment unless the contract clearly supports it.

How can publishers protect proprietary information?

Use scoped disclosure: show the consumer path and relevant evidence while withholding unrelated buyers, raw consumer data, complete media strategy, credentials, and unnecessary commercial detail.

When should a source scale?

After delivery is stable, buyer capacity is real, source metrics are consistent, disputes are explainable, payout reports reconcile, and payment behavior is dependable.

Build the operation before chasing the payout

A sustainable publisher operation can answer four questions:

1. What created this call?
2. Why did it route or fail?
3. Why did it earn or not earn?
4. Can the resulting payout be reconciled?

When those answers exist at the source level, the publisher can optimize intelligently, protect good traffic, pause weak segments, challenge errors with evidence, and choose buyers based on more than a headline rate.

That is how publishers scale without turning every exception into a dispute.

Have buyer-ready traffic? Apply to become a Dependable Calls publisher.