R Recover
graph model: checking
Demo mode Blank = use each customer's own contact. Without SMTP/Twilio set up, messages are shown as simulated.

Recover lost revenue from failed payments

The agent observes failed payments, checks them for fraud with two signals, diagnoses each failure, scores how likely it is to be recovered, drafts the outreach and sends it. Prioritized by the rupees you can win back.

Live pipeline

waiting for traffic
Every box counts real events this session. Squares move along the flow as events arrive. Quarantined payments leave the pipeline before diagnosis and are never messaged.
observed payment failure moving on to recovery quarantined message sent
Draft and send are counted together (messages sent). Fraud check covers every failed payment.

Live activity

Real session activity: rises as you analyze payments, run recovery, or receive Stripe events. Simulate live traffic to see it stream like production (always labeled SIMULATED).
0
payments seen
₹0
revenue recovered
0
anomalies caught
0
messages sent
0
graph model flags
0
quarantined
failures anomalies (card-testing) messages sent graph model flags

Where failed payments went

No failed payments yet.

Recovery plan

Drop a failed-payments CSV. Each row is checked by the card-testing detector and (if linked) the graph model, diagnosed, scored, and ranked by expected rupees recovered.

Drop your payments CSV here or click to choose
Stripe/Razorpay export format · or try the sample · try attack sample · download sample
Optional column graph_node_id links a payment to a node in the graph model. The sample files include it as a demo link: card payments have no real node in a Bitcoin graph. Rows without it show "no graph link", and no graph signal is applied.

Live

Failures arriving from Stripe webhooks (and simulated traffic) run through the same pipeline: fraud check first, then diagnosis and scoring.

Live failures

Listening for Stripe charge.failed events...
Events without a metadata.graph_node_id are linked to a random test-period graph node (a labeled demo link) so the graph signal is visible. Set GRAPH_DEMO_ILLICIT_PCT to change how many demo links point at illicit nodes (default 25; real prevalence is far lower).

Graph risk of recent live events

Each dot is one live event, newest on the right. Dashed lines are the review and quarantine thresholds.

Payment router (SmartRoute)

Sends sample payments through the EWMA router to mock gateways. A payment the router cannot complete, because every gateway failed, is handed to the Recover agent. A payment the fraud check blocks is quarantined and never messaged.
Needs make psps and the fraud service. Customers are made up (@example.com is never emailed). Gateways are mock PSPs.

Fraud model

The second fraud signal: a 2-layer graph neural network (GCN) trained on the real Elliptic Bitcoin transaction graph.

This is a FRAUD model trained on Bitcoin transactions, not card payments. It does not predict recovery: P(recover) is still the logistic regression. A payment is linked to a graph node explicitly (graph_node_id) or by a labeled demo link, so a payment's graph score is a demonstration of the pattern, not a claim about that customer.

Status

Checking...

Score a graph node

Random picks come from the test period only (time steps 35-49), so the model never saw them in training.

Neighbourhood (1-2 hops)

Score a node to draw its neighbours. A 2-layer model sees exactly this: neighbours, and neighbours of neighbours.

Where the model puts each class

Share of each class's test transactions per risk bin. Illicit mass to the right of the lines is what gets reviewed or quarantined. Overlap is the model's misses and false alarms.
licitillicit

Precision vs recall

Each marker is one threshold (0.1 to 0.9) on the test period. Further up and right is better. Computed on the test split, so optimistic for any threshold chosen from it.
GCNlogistic regression

GCN vs baseline

Test-period metrics. GCN bars are the mean over seeds with the spread as a line.
GCN 165 featureslogreg 165GCN 93 locallogreg 93 local

Model report card

ModelFeaturesROC-AUCPR-AUCF1 (illicit)

ROC-AUC says how well the model ranks a bad transaction above a good one (0.5 = coin flip, 1.0 = perfect). It is not accuracy. The graph's clear gain is PR-AUC (precision among the top-ranked); on ROC-AUC the GCN and the baseline are close.

Benchmark

Measured, reproducible proof of value, plus the graph model's own test metrics.

Proven results measured

Run the agent against a labeled 52-payment dataset with known outcomes. Fully reproducible, so you can verify the numbers yourself. download the dataset

Graph model test metrics

Elliptic Bitcoin
From fraud/artifacts/results.json. These are fraud-detection metrics on a different dataset; the benchmark on the left does not use the graph model, and its table is unchanged.
ModelROC-AUCPR-AUCF1

Drop-in API

Wire Recover into any stack in two minutes. No dashboard needed.

Drop-in integration

Autonomous: point your Stripe/Razorpay webhook at /webhooks/stripe and set AUTO_RECOVER=true. Failures recover themselves; quarantined payments are skipped.
Or call the API directly from your code: 
curl -X POST /api/recover -d '{
  "charge_id":"ch_1","customer_email":"a@b.com","amount":49900,
  "currency":"INR","failure_code":"insufficient_funds",
  "graph_node_id":136279,"send":true
}'
Returns the diagnosis, recovery probability, the drafted message, and, with send:true, sends it. graph_node_id is optional. New response fields: graph_risk, graph_status, fraud_signals, quarantined. A quarantined payment is never sent.

Try it

Sends the request below to this server (no message is sent) and shows the real response.
Response appears here.

For merchants

Losing revenue to failed payments, or getting hit by card-testing bots? Recover drops into your existing Stripe/Razorpay setup: it recovers the real failures and quarantines the fraud, automatically. Want it tailored to your stack?
Get a custom plugin