Banking, Payments & Credit
Payment Success Optimisation API
A declined payment from a customer who had the money and meant to pay is the most expensive thing in your payment stack, and the least measured.
- Payment service providers
- Marketplaces
- Subscription platforms
- Orchestration layers
- Merchants of record
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Authorisation rates are treated as weather. They move, nobody is quite sure why, and the usual response is to ask the acquirer, who says it is the issuer, who does not answer. Meanwhile a subscription business with a ninety-two per cent approval rate is losing eight per cent of its revenue every billing cycle to a process failure rather than a customer decision.
Some of that gap is genuinely unrecoverable — insufficient funds is insufficient funds. A surprising amount is not. Soft declines retried at the wrong hour, authentication exemptions not claimed where they were available, card-on-file transactions missing the credential-on-file indicator, network tokens not used where the issuer approves them at a visibly higher rate, retries hammered at a fixed interval that the issuer treats as suspicious. Each of these is a few tenths of a percentage point, and together they are material.
The reason this is not already solved inside most payment stacks is that measuring it properly requires a clean decline taxonomy across acquirers who all report reason codes differently, enough volume per issuer and BIN to say anything statistically, and the discipline to run routing changes as experiments rather than as opinions. That is a data engineering job with a model on top, not a model with a data problem attached.
Who buys this
Payment service providers, Marketplaces, Subscription platforms, Orchestration layers, Merchants of record
What the API returns
What comes back
- Recommended route and scheme for a given transaction, with the expected approval uplift
- Issuer and BIN level approval performance, segmented by amount band, channel and authentication path
- Normalised decline taxonomy mapping each acquirer’s reason codes onto one consistent vocabulary
- Soft versus hard decline classification, so retries are only attempted where they can succeed
- Optimal retry timing per issuer and decline reason, derived from observed recovery rates
- Authentication strategy guidance: when to request exemption, when to force a challenge
- Network tokenisation and credential-on-file coverage gaps that are costing approvals
- Experiment framework output so a routing change is measured rather than assumed
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/route | Recommended acquirer, scheme and authentication path for one transaction |
| POST | /v1/declines/classify | Normalise and classify a decline, with a retry recommendation |
| GET | /v1/performance/issuers | Approval performance by issuer, BIN range and segment |
| POST | /v1/retry/schedule | Optimal retry schedule for a failed transaction |
| POST | /v1/events | Submit authorisation outcomes so the measurement stays current |
| GET | /v1/experiments/{id} | Results of a live routing experiment with confidence intervals |
Request and response
illustrativeRequest
{
"transaction": {
"amount": { "value": 29.99, "currency": "GBP" },
"bin": "465921",
"card_brand": "visa",
"funding": "credit",
"issuer_country": "GB",
"channel": "recurring",
"credential_on_file": true,
"network_token_available": true
},
"available_acquirers": ["acq_alpha", "acq_beta", "acq_gamma"],
"objective": "approval_rate"
}Response
{
"recommendation": {
"acquirer": "acq_beta",
"scheme_rail": "visa",
"use_network_token": true,
"authentication": "request_exemption_tra",
"expected_approval_rate": 0.961,
"baseline_approval_rate": 0.938,
"confidence_interval": [0.952, 0.969],
"sample_size": 41820
},
"alternatives": [
{ "acquirer": "acq_alpha", "expected_approval_rate": 0.944 },
{ "acquirer": "acq_gamma", "expected_approval_rate": 0.921,
"note": "lower fee, 2.3pts lower approval on this segment" }
],
"warnings": [
{ "code": "COF_INDICATOR_MISSING",
"detail": "17% of recurring volume on this BIN is submitted without the credential-on-file indicator" }
],
"as_of": "2026-10-21T10:02:00Z"
}Where the data comes from
| Your own authorisation records | Every attempt with its acquirer, BIN, amount, authentication path and outcome — this is the dataset the whole service is built on, and you already hold it |
| Acquirer decline reason codes | Raw reason codes per acquirer, which must be normalised because no two acquirers use the same vocabulary for the same refusal |
| BIN reference data | Issuer, country, funding type and product tier, licensed from a BIN data provider or the schemes directly |
| Scheme rules and mandates | Published rules on retry limits, credential-on-file indicators and authentication exemptions — these change and the logic has to track them |
| Network token and 3-D Secure outcomes | Authentication results and token usage per attempt, which are among the strongest predictors of approval |
| Settlement and fee data | So a routing recommendation can be optimised against net revenue rather than approval rate alone |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- A normalised decline taxonomy built first, because every downstream number is wrong until the reason codes mean the same thing across acquirers
- Approval models fitted per segment — issuer, amount band, channel, authentication path — with explicit minimum sample sizes before a recommendation is made at all
- Contextual bandit routing so traffic keeps exploring alternative routes at a controlled rate instead of locking onto a local optimum that decays
- Soft/hard decline classification validated against observed retry recovery rather than the scheme’s nominal category, which is frequently optimistic
- Retry timing modelled from recovery curves per issuer and reason code, respecting scheme retry limits as hard constraints
- Objective functions that can optimise approval rate, net revenue after fees, or a weighted combination you specify
- Experiment infrastructure with holdout traffic, so every routing change is measured against a concurrent control instead of last month
- Drift monitoring per issuer, because an issuer changing its risk policy overnight is the most common cause of a sudden approval drop
What it changes for the business
Recovered revenue
Approval improvements compound across every billing cycle, which is why a few tenths of a point matters more here than almost anywhere else.
Explained declines
A normalised taxonomy turns ‘the issuer declined it’ into a reason you can act on or tell the customer about.
Smarter retries
Retrying only recoverable declines, at the right time, recovers more volume while reducing the attempts that look like abuse.
Acquirer leverage
Per-segment performance data changes a renewal conversation from an assertion into a measurement.
How it fits into your product
How it embeds
- Called inline before authorisation for a routing decision, with a hard latency budget and a safe default route if we do not answer in time
- Outcome submission endpoint so the measurement layer stays current without you building a separate reporting pipeline
- Shadow mode where recommendations are logged but not acted on, so you can measure the counterfactual before changing live routing
- Fits behind an existing orchestration layer, or replaces its routing logic if you would rather own it
- Experiment configuration so a percentage of traffic is always held back as a control
- Deployment inside your infrastructure, which is the normal arrangement since this reads your full authorisation history
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How much improvement is realistic?
We will not quote you a number before seeing your data, and anyone who does is guessing. The honest process is to analyse a few months of your authorisation history during the prototype and show you where the recoverable volume sits — it might be concentrated in one issuer, or in retry timing, or in missing credential-on-file indicators. If the analysis says there is little to recover, you will hear that.
Do we need to switch acquirers?
No. Most of the available gain comes from how transactions are submitted rather than where — authentication path, tokenisation, indicators, retry timing. Multi-acquirer routing adds more, but it is an option rather than a prerequisite, and single-acquirer deployments are a normal case.
Why do you need our fee data?
Because optimising approval rate alone can lose you money. The highest-approving route is sometimes the most expensive one, and for low-margin volume that trade is not worth making. With settlement and fee data the objective can be net revenue, which is usually what you actually want.
Will this work at low volume?
Partially, and we would be specific about where. Decline normalisation and retry timing work at modest volume because they pool across issuers. Per-issuer routing recommendations need real sample size, and below the threshold the API declines to recommend rather than returning a number built on forty observations.
Can you guarantee an approval rate?
No. Issuers change their risk models without notice, and a routing engine can only optimise within the decision the issuer is going to make. What we can commit to is measurement: holdout traffic, confidence intervals and an honest account of which changes moved the number and which did not.
Related blueprints
Chargeback Prediction API
Dispute risk scores at authorisation and afterwards, so a chargeback can be prevented rather than fought six weeks later.
Bank Account Verification API
Confirm that a bank account exists, is open and belongs to the person or business claiming it, before you send money to it.
Transaction Fraud Scoring API
Real-time risk scores for payments and account events, with explanations your analysts and your customers can both understand.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.