Skip to main content

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 overrideconnector overridelearned 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

Both 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.
Narrow to one connector’s latest snapshot, or one exact ingestion:
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

The | 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 error bps_rmse ≤ 15). These are the clusters cost routing trusts.
  • THIN — too little settlement volume to fit confidently yet. More data over time promotes these to GOOD.
  • NON_LINEAR — plenty of data, but the fee doesn’t follow a clean pct × amount + fixed line (tiered pricing, surcharges, mixed assessments), so the linear estimate isn’t reliable.
Coverage is reported by volume (money), not by cluster count, because that’s what matters economically: a merchant can have hundreds of tiny 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.
  • GOOD clusters have enough consistent data to trust; THIN have too little volume; NON_LINEAR have a fee structure the linear fit can’t capture well.
  • bps_rmse_p50/p90 are the fit accuracy (basis-point error) of the GOOD clusters.