Feedback and learning

Tell Gurdx what really happened to the orders and users it scored, and your account's fraud models learn from it every night.

Why send feedback#

Out of the box, Gurdx scores payments with rules and a statistical model tuned for card-not-present digital goods. Your own outcomes make it yours:

• Your payment model. The model behind rule PF10015 is re-fitted on your labelled transactions every night.
• Your rule weights. How much each payment rule counts is calibrated on how often it fired on orders that turned out to be fraud.
• Reputation memory. Identities you confirm as fraud (customer id, email, phone, device, card, IP) raise the score of future payments that reuse them (rules GX2001 and GX2002) and of IP, email and phone checks. Customers with a long confirmed-legitimate record are scored more gently.
• A threshold suggestion. Your dashboard's Learning page shows the score threshold that would have cost you least on your own data.

Nothing learned is applied unless it beats what runs today on your most recent transactions, and Gurdx never changes your thresholds or your blacklists for you (blacklisting confirmed fraud automatically is an opt-in setting).

What to send#

Use the same transaction_id you send to Payment Fraud Detection. Outcomes can arrive in any order: a chargeback or fraud_confirmed is never overwritten by a later approved, and an outcome for a transaction Gurdx has not scored yet is kept and applied when it arrives.

Recommended integration for a digital-goods store#

1. Score every order with scoring/payment before delivering, with a stable transaction_id and customer_id.
2. When the order is delivered, send approved. When it is refunded or charged back, send that outcome as soon as you know it, with the reason.
3. When support confirms an account takeover or a stolen card, send fraud_confirmed for the order and label the email, phone or device with feedback/event.
4. Once a night, re-send the day's outcomes with feedback/bulk. It is idempotent, so a missed real-time call is simply caught up.
5. Once, backfill your history with feedback/bulk: past orders with their outcome, and for orders scored elsewhere, their customer_id, customer_email, customer_phone and customer_ip.

curl -X POST "https://gurdx.cretip.com/api/feedback/payment" \
  -H "Authorization: Bearer $GURDX_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transaction_id": "ORD-10492", "outcome": "chargeback", "reason": "fraudulent"}'

How learning works#

• Labels. A chargeback, a fraud_confirmed outcome or a declined outcome whose reason mentions fraud is fraud. legit_confirmed, or an approval that has gone 30 days without a chargeback, is legitimate. Refunds and other declines are not used for training.
• When it starts. The model is re-fitted once your account has at least 200 labelled transactions including at least 20 fraud cases.
• Fair comparison. The newest 20% of your labelled transactions are held out. A new model or new rule weights are adopted only if they rank fraud better on that hold-out (AUC higher by at least 0.01, and by more than chance on that sample could explain) and catch at least as much fraud at the event threshold.
• Reputation fades. Evidence about an identity halves every 90 days, so old mistakes stop counting.
• Privacy. Identities are stored only as keyed hashes plus a masked display value. A user data deletion request removes them too.

Notes#

• The feedback methods are free: they never count against your quota, and they are included in every plan.
• Test mode validates the payload and answers with a well-formed result, but stores nothing.
• Invalid feedback returns error 131 (invalid_feedback) and more than 1,000 items returns 132 (too_many_feedback_items), always with HTTP 200. In a bulk call a bad item is reported in its own result and does not stop the others.