Skip to content
Book a demo
Use cases · PSPs & card processing

Card testing is quiet. Chargebacks aren’t.

Fraudsters test a stolen card with tiny payments, then spend big. Sieve scores every attempt, declines included, and blocks the big spend before it settles.

Book a demoEvents reference

For payment service providers, gateways, acquirers and merchants taking card, mobile money, USSD and POS payments.

How it hits

Four ways the money goes missing.

Each looks like ordinary activity. Sieve scores every event in context, before the money moves.

  1. 01

    Card testing

    Dozens of tiny payments, most declined, then one big purchase on a card that worked.

    Caught by Card testing rule and pattern, rapid succession

  2. 02

    Velocity attacks

    A quiet card suddenly makes fourteen mid-size payments in an hour.

    Caught by Volume spike, transactions in quick succession

  3. 03

    Out-of-pattern amounts

    A customer who usually spends KES 3,000 pays KES 95,000 to a gift-card merchant.

    Caught by Exceptionally large amount, large payment to a first-time recipient

  4. 04

    Account takeover

    A new device, a password reset, then the account’s biggest payment ever.

    Caught by Failed logins then success, new device money out, account takeover pattern

A catch, step by step

Minutes of activity. One decision.

A story from the Payments & card processing demo, run through the same engine as your events. Each reason is written for the analyst who acts on it.

Eight minutes of testing, then the real spendreplayed through the engine
  1. 11:40:0024 payments of KES 10 to 25 in eight minutes, 19 declinedCard testing: declines piling up
  2. 11:48A few of the tiny payments go throughReviewed
  3. 11:50KES 180,000 at an electronics merchant on a card that worked
  4. DecisionBlocked
    • Payment after 19 declined attempts in 30 minutes
    • Large first payment to a new merchant
    • New account moving money out

The KES 180,000 purchase is blocked before it settles. The burst of declines was already flagged for review.

What Sieve does

Choose “Payments & card processing” and these start enforcing.

Plain-English rules you can adjust, joined into fraud patterns. Everything else runs in Watch, scoring without acting, until you trust it.

Rules
  • Card testing
  • Transactions in quick succession
  • Volume spike
  • Exceptionally large amount
  • New device + money out
  • Failed logins, then a success
Patterns
  • Card testing
  • Account takeover
  • Scripted activity
Integrate

Send these events. One endpoint.

  • transactionEvery authorisation, declines included (status: failed). Card testing hides in the declines.
  • loginWith device and IP, to catch takeovers.
  • customer.updatedCredential and payout changes.
POST /v1/events
await sieve.events.create({
  type: 'transaction',
  customer_id: 'cus_8841',
  direction: 'out',
  amount: 15,
  method: 'card',
  status: 'failed',            // send declines too
  counterparty: { id: 'merchant_digital_goods' },
  device: { id: deviceId, ip: req.ip },
})
Compliance

What your regulator will ask, answered.

Sieve supports your obligations. It doesn’t replace your compliance team.

PCI DSS scope
Sieve never needs a card number. Send a token or card fingerprint instead.
Card scheme fraud monitoring
Fewer fraudulent payments, so fewer chargebacks against your merchants.
Other use cases
Book a demo

See it on a workspace built for you.

A private Payments & card processing workspace for Kenya or Nigeria, with a month of traffic and the fraud above. We walk your team through a live catch.

Book a demoTalk to our team