Abuse Checks

Damping that is already on, scoring that is planned

Every end-user route your application calls is rate-limited per identity and answers 429 with a Retry-After header. Sign-in realms are provisioned with brute-force protection, workspace invitations have a budget, and every write that matters carries an idempotency key. Risk scores and allow, challenge or block policies are planned.

Create a workspace Read the integration notes

Abuse ChecksIn part

Implemented in part

1Available in part

2Works today: listed below

3Planned items labelled

Available in part — Abuse Checks: Today Abuse Checks is a set of always-on protections rather than a scoring product: rate limits on end-user and billing routes, brute-force protection on sign-in realms, an invitation budget per workspace and idempotent writes. Items listed as planned below cannot be enabled yet. What Paycux provides today.

Status

What exists today, and what is planned

Works today

PlannedPlanned

PlannedRisk scores for sign-up and sign-in events
PlannedAllow, challenge and block policies per environment
PlannedDevice and network signals
PlannedAn appeals and override flow for people who were blocked
PlannedMeasured false-positive reporting

How it works

What happens to a runaway client

The identity is counted

Every end-user call is charged to a token bucket for the calling identity. A client in a loop drains the bucket and is refused until it refills; a client calling at a normal pace never notices.

The source is counted when it can be

If the deployment declares which proxies to trust, the client address gets its own bucket. If not, Paycux refuses to guess, because a wrong guess would rate-limit every tenant behind one proxy.

The refusal is explicit

A refused request answers 429 RATE_LIMITED with a Retry-After header and writes nothing. Retry after the interval with the same Idempotency-Key and the request is simply processed.

Damping, not quotas

Rate limits stop runaway clients; entitlements decide quotas

Abuse damping and plan quotas are different things, and Paycux keeps them apart. A 429 means a client is calling too fast. A usage decision with LIMIT_EXCEEDED means the billing account has used its entitlement. The second is the one your product logic should act on.

Rate limits are kept per API instance and are not a billing quota
Entitlement decisions come back in the usage event response as allowed, reason, consumed and limit
Plan limits on projects, connections and members answer 402 PLAN_LIMIT_EXCEEDED, never 429
A deployment can scale every bucket with one multiplier for load tests

Damping, not quotasIn part

Implemented in part

1Available in part

2Works today: listed below

3Planned items labelled

Safe retries

Idempotency keys make a retry a no-op

Networks fail between your request and the response. Because usage events, checkouts and plan changes require an Idempotency-Key, retrying with the same key returns the original result instead of a second event, a second checkout or a second plan swap.

A repeated usage event answers duplicate: true with the original event id
A checkout retried with the same key keeps the same session; a changed payload answers 409
The console mints one key per plan per render for checkout and plan changes
A missing key answers 400 INVALID_INPUT before anything is written

Safe retriesIn part

Implemented in part

1Available in part

2Works today: listed below

3Planned items labelled

On today

Protections that need no configuration

Each of these is part of the API as deployed. There is nothing to enable and nothing to pay for separately.

429 with Retry-AfterA refused request names the wait in seconds. Honour the header and the next attempt goes through.

Per identity, optionally per sourceBuckets are keyed by the calling identity, and by client address only when the deployment has declared its proxy topology.

Brute-force protection on sign-inThe customer identity realm Paycux provisions for each environment refuses repeated failed sign-ins temporarily instead of letting them run.

Invitation budgetWorkspace invitations are counted per workspace before anything is written, and only owners and admins can spend the budget.

Idempotent writesUsage events, checkouts and plan changes carry an Idempotency-Key, so a retry can never double-count or double-sell.

Per-member damping on provider-facing actionsCreating, enabling and rotating provider connections and changing the workspace plan are damped per member, so one operator cannot turn Paycux into a key-testing relay.

On the wire

What a protected request looks like

The same usage event sent twice, a refusal with its Retry-After header, and an invitation that counts against the workspace budget.

1curl -X POST https://api.paycux.com/v1/usage/events \
2  -H "Authorization: Bearer <realm access token>" \
3  -H "Idempotency-Key: report-export-<order id>-0001" \
4  -H "Content-Type: application/json" \
5  -d '{
6    "projectId": "<project id>",
7    "environmentId": "<environment id>",
8    "realmId": "<realm id>",
9    "billingAccountId": "<billing account id>",
10    "meterKey": "report_exports",
11    "quantity": 1,
12    "occurredAt": "2026-10-13T09:00:00Z"
13  }'
14 
15# 200 OK
16{
17  "allowed": true,
18  "reason": "WITHIN_LIMIT",
19  "consumed": 12,
20  "limit": 100,
21  "eventId": "<event id>",
22  "duplicate": false
23}

Transparent pricing

Included in workspace plans

In part No separate price for what works today.Workspace plans

Included in every workspace plan. Limits (projects, provider connections, members, usage events) are listed on the pricing page.

See full pricing Talk to an expert

Rate limits on end-user routesIncluded

Brute-force protection on sign-in realmsIncluded

Workspace invitation budgetIncluded

Idempotent writesIncluded

Questions

Frequently asked

Is a 429 the same as a plan limit?

No. A 429 RATE_LIMITED means a client is calling faster than the damping allows and nothing was written. A plan limit answers 402 PLAN_LIMIT_EXCEEDED on creates, and a usage quota comes back inside a usage decision as LIMIT_EXCEEDED. Only the last two are about what the account is entitled to.

Why are requests not limited by IP address by default?

Behind a proxy every request arrives from the proxy's address. Counting that address would let one tenant's flood lock out every other tenant, so per-source damping is switched on only when the deployment declares its proxy topology with PAYCUX_TRUSTED_PROXIES. Per-identity damping is always on.

Can I tune the limits for my workspace?

Not per workspace today. The buckets are set to stop runaway clients rather than to meter normal traffic, and a deployment can scale all of them with PAYCUX_RATE_LIMIT_MULTIPLIER. If your application hits them in normal operation, that is worth a conversation.

Does brute-force protection lock people out for good?

No. The realm temporarily refuses further attempts after repeated failures and accepts a correct password once the wait has passed. It is a slow-down, not a permanent lockout, and it applies to the hosted sign-in of every environment.

When do risk scores and policies arrive?

They are planned and there is no committed date. Until they exist, this page will keep describing only the protections that are on.

Keep exploring