For payout platforms, CPA networks and mass payment services

Don't let money go out by mistake

Checks duplicates, limits and logic errors before money leaves.

After signup you immediately see the demo and decision log.

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 decision log

02

Demo

Test request before connecting payouts

03

Connect to payouts

Only when you decide to

Three types of errors that cost money

Examples from the demo — similar cases happen in 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 checks payouts before money leaves

Right after signup you'll see the decision 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 demo · 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"
}
allow proceed hold review block stop
Create and edit rules View and filter logs Enable blocking when ready 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.

Decision log. Froddy records evaluations and reasons.

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.

Decision log in one place TLS 1.3 for all connections

Start free. Pay when you see results

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

Starter
9 900 ₽/mo
10,000 checks included
  • Enable blocking when ready
  • Webhook and email notifications
  • Check history and trigger reasons
  • Manual activation, no auto-billing

Activate manually after Free. Monthly billing, no automatic upgrades.

Enterprise
Custom
From 500K checks/month
  • Volume pricing
  • Dedicated support
  • Custom rule configuration
  • DPA and processing description
Request terms

Need Growth or a custom volume? — Contact us

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 demo?
The demo lets you see how Froddy evaluates payouts before you enable blocking. You can send a test request and review the decision log.
What if nothing is found at first?
That is still useful. Froddy helps validate limits, rule logic, and the decision log before money moves.
When does billing start?
The Free plan is always free. 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 Froddy checks payouts before money leaves

After signup you immediately see the demo and decision log.

Start free
No blocking until you enable it.
ban