Ask your payment traffic a question. Get an answer with evidence.

AI analysis of approval rates, chain retries and routing — running on models inside the payment platform. Your data never leaves the platform.

Request access See how it works

Recorded turn · Jul 9 – Aug 9, 202632 days · 12 tool calls

Customers who have already paid us before started failing to pay again this week. It is not the newcomers — it is the ones coming back. Where does it break for them?

1Is there a problem
2Where it comes from
3What to do

Approval rate by day

project 90

68.8%-13.4 pp

Jul 9Aug 9

vs 82.2% average before Aug 8

Decline reasons

gate 163 · 370

issuer decline: 46.0%
dropped by routing: 37.6%
processor error: 16.5%

◇ no number

Gate 161 serves first payments, 162–164 the returning ones. Approval rates across branches are not comparable — no uplift is computed.

data stays in the payment platform
numbers only from tools
read-only: nothing changes in processing

The answer

And this is how the turn ends

Three paragraphs in a fixed order — what happened, why, what to do — and, where the data supports it, the exact row to change in the cabinet.

What happened

Returning customers are stalling at the second gate of their chain this week.

Why

Their chain for repeat customers runs Halvora (gate 162) first, and most of these orders end on Veltora (gate 163), which this week saw its decline mix swing from issuer refusals toward internal chain-balancing and unclassified processor errors — a technical fault, not a gate verdict. Because Veltora sits almost always last in this chain by observed position, its approval rate cannot be fairly benchmarked against Halvora, so no reroute uplift is offered here — only the direction of the recommendation.

What to do

Worth flagging Veltora’s processor (gate 163) for an integration check, since the jump in unclassified and internal errors this week looks operational rather than card-issuer driven; until that is resolved, consider giving Veltora less weight in the returning-customer chain so fewer of these repeat orders dead-end there.

Routing recommendation

Move this route to another gate

Takes this segment nowNordica - NetInvest Redeposit 3 - EURgate 16457.8%1,845 decided · ±2.25 pp

+32.4 pp

Approves betterHalvora - NetInvest Redeposit 1 - EURgate 16290.2%29,703 decided · ±0.34 pp

Edit in the cabinetBalancing · project id 90 › returning-customer chain › row 3

No money figure is attached: the two gates stand at different positions in the chain, and an uplift computed across them would not be honest.

Same recorded turn · project name redacted, gates named from the configuration map

How it works

Three steps, and the third one is the point

01
Ask in your own words
No query builder, no parameters. "Returning customers stopped getting through — where does it break?" is a complete question.
02
The model calls tools one by one
Read-only MCP tools against processing data. The turn follows the analyst’s route, and you watch it move:
1. 1Is there a problem
2. 2Where it comes from
3. 3What to do
03
Every card opens down to the raw answer
Numbers are drawn from the tool response, not from model prose. Open any card to see the exact call and the JSON it returned.

Privacy

Private by architecture, not by promise

The analysis happens where your payments already are. No transaction data crosses the boundary of the payment platform — there is no outbound call to make.

Models run inside the platform: Weights are hosted on the payment platform’s own hardware.
No third-party AI providers: Nothing is sent to Anthropic, OpenAI, Google or DeepSeek. Not prompts, not results.
Isolated per tenant: Every tool call is scoped to your own projects. You cannot see another merchant, and neither can the model.
EU data residency: Data stays where your processing already lives.

Pricing

Prepaid credits. Pay for what you analyse.

No seats, no subscription. Usage is metered per analysis and charged against a balance you top up.

See pricing