For payout platforms, CPA networks and mass payment services

Catch duplicates, limits and logic errors before money leaves

See how Froddy checks payouts before money leaves: catches duplicates, limits and logic errors in the test environment. Connect real traffic later, when you're ready.

After signup you immediately see the demo, check log and can run a test scenario without connecting real traffic.

Doesn't block flow No response — payout proceeds normally
No card or personal data Only IDs, amounts and service fields
Decision is yours Froddy advises, you decide
Single decision log Every check, rule and verdict — in one place.
01

Sign up

Access to demo and check log

02

Test environment

Test request without connecting real traffic

03

Real traffic

Observation mode, 14 days free

Three types of errors that cost money

Examples from the test environment — similar cases happen in real payout flows every day.

$14 200

Duplicate payout

Two identical payouts 3 seconds apart — the second one stopped.

block
stop
$48K of $50K

Limit exceeded

Daily payouts to a partner approached the ceiling — paused pending confirmation.

hold
review
120/hr

Abnormal frequency

Suspiciously high frequency for one partner — paused pending confirmation.

hold
review

See how Froddy will work for you before integrating into real traffic

Right after signup you'll see the check log, active rules and a live API response example. Enough to understand in a few minutes how duplicates, limits and frequency rules work.

Verdict log test environment · last 8
Payout IDcounterpartyamountverdict
pay_00415 partner_047$3 200 allow
pay_00414 partner_012$14 200 hold
pay_00413 partner_047$14 200 block
pay_00412 partner_003$890 allow
pay_00411 partner_047$7 500 allow
pay_00410 partner_003$2 100 allow
pay_00409 partner_012$49 800 hold
pay_00408 partner_091$4 750 allow
Rule: daily limit active
Typedaily_limit
Limit$50,000 / day
Groupingby counterparty
Verdicthold
Rule: duplicate active
Typeduplicate_check
FieldPayout ID
Window24 hours
Verdictblock
API response example POST /v1/evaluate
{
  "entity_id": "partner_047",
  "amount": ,
  "currency": "USD",
  "event_type": "payout",
  "payout_id": ""
}

Try: amount > 50,000 → hold, ID = pay_00413 → block, otherwise → allow.

{
  "verdict": "block",
  "rule_id": "duplicate_check",
  "reason": "duplicate payout_id",
  "mode": "shadow"
}
allow proceed hold review block stop
Create and edit rules View and filter logs Enable observation mode Run a test check

One API call before the payout. Verdict returns immediately, the decision stays with your code

Froddy is called before sending a payout, returns allow / hold / block, and the final action stays with your code.

01

Send the request

POST /v1/evaluate — counterparty ID, amount, currency, event type, payout ID.

02

Get the verdict

allow, hold or block — plus the rule and reason.

03

Decide yourself

If Froddy doesn't respond in time, the payout proceeds normally.

Anonymous IDs and amounts only, no personal data. Timeout and final action are controlled on your side.
API reference → · Docs →

Fail-open — integration example
try {
  const res = await fetch('https://api.froddy.io/v1/evaluate', {
    method: 'POST',
    headers: { Authorization: `Bearer ${key}` },
    body: JSON.stringify(payload),
    signal: AbortSignal.timeout(YOUR_TIMEOUT_MS) // your timeout
  });
  const { verdict } = await res.json();
  if (verdict === 'block') return rejectPayout();
} catch (err) {
  // Froddy unavailable → payout proceeds
  log.warn('froddy timeout, proceeding');
}
proceedWithPayout();
try {
  $response = (new \GuzzleHttp\Client([
    'timeout' => YOUR_TIMEOUT_S
  ]))->post('https://api.froddy.io/v1/evaluate', [
    'headers' => ['Authorization' => "Bearer {$key}"],
    'json'    => $payload,
  ]);
  $verdict = json_decode($response->getBody(), true);
  if ($verdict['verdict'] === 'block') return rejectPayout();
} catch (\Throwable $e) {
  // Froddy unavailable → payout proceeds
  Log::warning('froddy timeout, proceeding');
}
proceedWithPayout();
import requests

try:
    resp = requests.post(
        'https://api.froddy.io/v1/evaluate',
        headers={'Authorization': f'Bearer {key}'},
        json=payload,
        timeout=YOUR_TIMEOUT_S  # your timeout
    )
    verdict = resp.json()['verdict']
    if verdict == 'block':
        return reject_payout()
except Exception:
    # Froddy unavailable → payout proceeds
    logger.warning('froddy timeout, proceeding')

proceed_with_payout()
ctx, cancel := context.WithTimeout(ctx, YOUR_TIMEOUT)
defer cancel()

body, _ := json.Marshal(payload)
req, _ := http.NewRequestWithContext(ctx,
    "POST", "https://api.froddy.io/v1/evaluate",
    bytes.NewReader(body))
req.Header.Set("Authorization", "Bearer "+key)

resp, err := http.DefaultClient.Do(req)
if err != nil {
    // Froddy unavailable → payout proceeds
    log.Warn("froddy timeout, proceeding")
    proceedWithPayout()
    return
}
var result struct{ Verdict string }
json.NewDecoder(resp.Body).Decode(&result)
if result.Verdict == "block" { rejectPayout(); return }
proceedWithPayout()
Your backend
Froddy APIrequest → verdict
Your backend
Bank / Gatewayif verdict = allow

Your request, verdict from Froddy, action — yours

Why it's safe to test. And what we don't do

Why it's safe

Fail-open. If Froddy doesn't respond in time, the payout proceeds normally. Froddy doesn't control the payout itself — it only returns a verdict.

Observation mode. Froddy monitors the flow and writes logs. Enabling blocking is your decision only.

Minimum data. Only anonymous IDs and amounts. Card numbers, CVV and personal data are not passed to Froddy. The service works only with anonymous IDs, amounts and service fields.

What Froddy handles

Replaces hand-rolled pre-payout checks. Limits, duplicate checking, hold logic and a unified decision log — what teams often build themselves.

Not a bank or PSP. Froddy doesn't send money or manage payment routes. It only answers: proceed or not.

Not anti-fraud or KYC/AML. We don't evaluate the payer or look for complex fraud. Froddy checks the payout request itself: duplicates, limits, frequency and logic errors.

The final decision is yours. Froddy returns allow, hold or block, and your code acts on it.

Servers in Moscow (Timeweb Cloud) TLS 1.3 for all connections

Start free. Pay when you see results

1 check = 1 verdict. Intermediate requests are not billed.

Observation mode
0 ₽
14 days on real traffic, no blocking
  • Enable manually when you're ready
  • Logging only, no blocking
  • All rules from the test environment
  • Real statistics of your flow
Start with test environment
Starter
19 900 ₽/mo
100,000 checks included · overage $3/1,000
  • Observation mode and blocking
  • Webhook and email notifications
  • Check history and trigger reasons
  • Manual activation, no auto-billing

Activate manually after the test environment or observation mode. Monthly billing, no automatic upgrades.

500K+ checks per month — Request pricing

Frequently asked questions

How is Froddy different from anti-fraud?
Anti-fraud checks the payer and looks for fraud. Froddy checks the payout itself: duplicates, limit errors and logic failures before money is sent. It's an additional control layer, not a replacement for anti-fraud.
How long does integration take?
Basic integration is one API call before the payout. Full launch depends on your internal checks and release cycle.
What is the test environment?
An isolated environment where you call the API locally and see logs without risking real data. Free forever — test as much as you want.
What if nothing is found during the 14-day observation period?
That's fine. It means there are no obvious duplicates, limit errors or frequency anomalies in your current flow. The test environment stays available and you can come back after changes to your payout logic.
When does billing start?
The test environment is always free. Observation mode on real traffic is free for 14 days. You connect the paid plan manually — no automatic upgrades.
Froddy logs all checks — does that slow down payouts?
No. Froddy returns a verdict synchronously, before money is sent, but doesn't block the flow itself. What to do with the verdict — block, log or route to manual review — is your decision. A log of all checks and verdicts is available in real time.
How does Froddy fit into the payout process?
You add one API call before sending a payout. Froddy checks it against your rules — duplicates, limits, logic errors — and returns a structured verdict. Your system decides how to react. No changes to payment routing required.

Data and requirements

Froddy does not require personal data by default: you define which fields to send for risk checking.

  • We don't require PAN/CVV, names or email in plain form.
  • If entity-level checks are needed — use pseudonymous/hashed IDs (e.g. account_id).
  • Decisions and technical logs are available for audits and investigations.

For projects with 152-FZ / GDPR / CCPA requirements, we provide DPA and processing description on request. Learn more · Contact us

See how payout checks will fire before connecting to real traffic

After signup you'll see the demo, check log and can run a test scenario without connecting real traffic.

Start free
Connect real traffic later — only when you decide to.
ban