Cost Ingestion: Fees & Coverage
Once settlement data has been ingested (see Connector Setup and Uploads), Decision Engine fits a per-cluster cost model — the input to multi-objective routing’s expected-value ranking. These endpoints read that model and let you override it manually. Overrides take priority in this order: cluster override → connector override → learned model.Connector Fees
Per-connector blended fee (volume-weighted over trustworthy clusters), any manual override, and which one is effective.source is "override", "model", or "none" (configured but no fitted data yet).
Set A Connector Fee Override
Replaces the learned model for every expected-value calculation on this connector.Delete A Connector Fee Override
pct_bps and fixed must be finite and non-negative. Setting or clearing an override refreshes this merchant’s served cost model immediately rather than waiting for the periodic refresh.
Cost Clusters
The highest-traffic fitted clusters (by GMV) — the fine-grained segments underneath a connector’s blended fee, and the target for surgical per-cluster overrides.key is the opaque connector|network|variant|funding|issuer|currency|ic_category identifier used for the override calls below. limit defaults to 10, capped at 50.
Set A Cluster Fee Override
Delete A Cluster Fee Override
| separators in key must be URL-encoded (%7C) when used as a path segment.
Cost Coverage
Cost-aware routing is only as good as the cost data behind it. A fitted model is trustworthy for some clusters and shaky for others, and routing decisions made on a shaky estimate can do more harm than good. Cost coverage is the honesty check: it tells you what fraction of a merchant’s real volume actually has a cost model solid enough to route on, so you know whether to lean on multi-objective routing or hold off until more settlement data arrives. Every fitted cluster is graded with one of three verdicts:GOOD— enough transactions (n ≥ 200) and a tight linear fit (per-transaction errorbps_rmse ≤ 15). These are the clusters cost routing trusts.THIN— too little settlement volume to fit confidently yet. More data over time promotes these toGOOD.NON_LINEAR— plenty of data, but the fee doesn’t follow a cleanpct × amount + fixedline (tiered pricing, surcharges, mixed assessments), so the linear estimate isn’t reliable.
THIN clusters that together carry a rounding error of GMV. good_gross_pct — the share of settled value sitting in GOOD clusters — is therefore the headline number. Everything outside a GOOD cluster simply falls back to plain success-rate routing, so a low coverage figure doesn’t break routing; it just means fewer payments get the cost lens. As a rule of thumb, wait for good_gross_pct to climb into a comfortable range before flipping the merchant-wide multi-objective flag.
The raw fields:
Answers “is cost estimation actually working for this merchant?” — the dashboard health-card summary. good_gross_pct (share of settled volume with a trustworthy model) is the headline number; everything not covered falls back to plain success-rate routing.
GOODclusters have enough consistent data to trust;THINhave too little volume;NON_LINEARhave a fee structure the linear fit can’t capture well.bps_rmse_p50/p90are the fit accuracy (basis-point error) of theGOODclusters.
Related
- Cost Ingestion: Connector Setup
- Cost Ingestion: Uploads
- Multi-Objective Routing
- Analytics Endpoints — see Cost Savings for the merchant-facing rollup.