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.
Sign up
Access to demo and check log
→Test environment
Test request without connecting real traffic
→Real traffic
Observation mode, 14 days free
What Froddy catches
Three types of errors that cost money
Examples from the test environment — similar cases happen in real payout flows every day.
Duplicate payout
Two identical payouts 3 seconds apart — the second one stopped.
Limit exceeded
Daily payouts to a partner approached the ceiling — paused pending confirmation.
Abnormal frequency
Suspiciously high frequency for one partner — paused pending confirmation.
Demo
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.
For engineers
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.
Send the request
POST /v1/evaluate — counterparty ID, amount, currency, event type, payout ID.
Get the verdict
allow, hold or block — plus the rule and reason.
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 →
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 request, verdict from Froddy, action — yours
Security and limitations
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.
Pricing
Start free. Pay when you see results
1 check = 1 verdict. Intermediate requests are not billed.
- Access to demo and check log
- Check log and trigger reasons
- Core rules: duplicates, limits, frequency
- Test as much as you want, no time limit
- Enable manually when you're ready
- Logging only, no blocking
- All rules from the test environment
- Real statistics of your flow
- 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
FAQ
Frequently asked questions
How is Froddy different from anti-fraud?
How long does integration take?
What is the test environment?
What if nothing is found during the 14-day observation period?
When does billing start?
Froddy logs all checks — does that slow down payouts?
How does Froddy fit into the payout process?
Data
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