Payment and SMS fraud (beta)

Beta

Payment and SMS scoring are in beta. They are off for a site until its paymentFraud flag is set, and the feature may not yet be generally available (a closed flag is 403 feature-disabled). Treat the output as one signal among several.

When to use it

• Payments: card testing (an attacker tries many stolen cards on your checkout) and stolen cards.
• SMS: toll fraud, where bots make your app send texts to premium-rate numbers.

How it works

Both are assessments (see assessments). You add extra fields, and the answer adds an extra block. One assessment counts as one check, whatever it scores. RevokeGPT never charges the card and never sends the SMS. It only scores.

Payments, step by step

1. Create an assessment with fraudPrevention: 'ENABLED' and transactionData.
2. Send only the card’s BIN (the first 6 or 8 digits) and last four. The SDKs’ cardFields helper refuses anything else, so a card number never leaves your server. Every string of transactionData is also scanned for a card number, and the server answers 400 bad-request if it finds one (also for expiry, CVV or track data).
3. Read fraudPreventionAssessment.transactionRisk (0 to 1).
4. After the gateway answers, annotate the assessment with transactionEvent so the scorer learns.

const a = await revokegpt.createAssessment({
  token,
  fraudPrevention: 'ENABLED',
  transactionData: { ...cardFields({ bin: '424242', last4: '4242' }), currencyCode: 'USD', value: 59.9 },
});
a.fraudPreventionAssessment?.transactionRisk; // 0 to 1; 0.5 with unscored: true when it could not be scored
await revokegpt.annotate(a.name, {
  transactionEvent: { eventType: 'MERCHANT_APPROVE', value: 59.9 },
});

The block fraudPreventionAssessment holds transactionRisk, riskReasons, cardTestingRisk, stolenInstrumentRisk and the two verdicts. transactionData also accepts addresses, user, items, merchants and gatewayInfo (the gateway’s own response codes). Send fraudPrevention: 'DISABLED' to skip payment scoring on an assessment.

Suggested thresholds: block at risk 0.7 or more, step up (for example email MFA) at 0.4 or more. Nothing is enforced for you.

SMS toll fraud, step by step

Pass the destination phone number in userInfo.userIds (phoneNumber). The answer carries phoneFraudAssessment.smsTollFraudVerdict.risk and reasons. Gate on it: for example send only below 0.4. An answer with unscored: true means “could not score”: do not send.

const a = await revokegpt.createAssessment({
  token,
  userInfo: { userIds: [{ phoneNumber: '+14155550123' }] },
});
const v = a.phoneFraudAssessment?.smsTollFraudVerdict;
if (!v || v.unscored || v.risk >= 0.4) refuseToSend();

This needs the site’s smsTollFraud flag. Without it the phone number is ignored.

Errors

Status and code	Meaning	What to do
400 bad-request	A card number or other card data in the request.	Send BIN and last four only.
403 feature-disabled	The flag is off for the site.	Enable it, or skip the call.
429 rate-limited	Too fast.	Retry after a second.
503 service-unavailable	Assessments unavailable.	Decide per risk: for payments fall back to your gateway’s own checks; for SMS do not send.

Security notes

• Never send full card numbers, expiry or CVV anywhere in the request.
• A phone number is personal data. Send it only when you are about to send a text to it.
• Annotate with real outcomes (gateway approve, chargeback), not guesses.