Provider rates

Settings → Provider rates. What each provider call costs, and what this account has set.

Requires provider_rate.view to read and provider_rate.manage to change.

Why it exists

Every provider call is recorded as a ProviderFetchRun. Until recently none of them recorded what it cost, so "what did onboarding this merchant cost us" had no answer — and a Wathq retry loop was invisible at 11 SAR a turn.

Rates were then transcribed into a Ruby constant, which meant a renegotiated price needed a deploy and a rate that changed mid-month could not be expressed at all. This screen is the answer to both.

Published, and yours

Verity ships the published rate sheet. A rate set here replaces it for this account, and the screen shows both:

Full commercial registration data | published 11.00 SAR | in effect 9.50 SAR [Your rate] | from 2026-08-17

Both numbers are shown deliberately. A screen showing only the effective rate leaves nobody able to tell a renegotiated 9.50 from a transcription error; one showing only the published rate would be a lie about what is pricing the runs.

Setting a rate records a new one

Setting a rate does not edit the old one. It records a new rate from a date, and the previous rate stays readable.

Why not just edit it

Cost is written onto each run when the run happens. A run priced last month keeps its amount — and if the rate it was priced under were overwritten, that stored number would become unexplainable.

Guarding against re-pricing on the run and then allowing it here would be pointless.

A rate dated in the future prices nothing until it arrives. Each row carries its own history: what it was, from when, who set it, and why.

Changing a rate is recorded in the audit trail with the previous value, because a trail saying a rate changed but not from what cannot answer why last month's total differs.

An unknown cost is blank, never zero

This is the rule the whole feature rests on, and this screen is where somebody types a number.

Charged	An amount above 0
Nothing is charged	Exactly 0 — a real zero, for a call that invoices nothing
Cost unknown	Blank

Zero and blank are different claims

A cost nobody knows, recorded as 0.00, flows into a total that looks complete and reads low. It is the same failure as a screening that reports "clear" because nobody looked.

Enforced three times: the form does not default the field, the model explains the refusal in a sentence, and a check constraint guarantees it against a console or a future importer.

A blank amount also drops its currency — "SAR" beside an empty number reads as 0.00 SAR.

Six of the seventeen priceable calls have no known cost today: Focal screening, Wathq GOSI, Wathq related registrations, Elm digital ID, and Sijilat. Every total containing one is a floor, and says so.

Which "why" you can set

Only four of the eight bases can be configured:

Basis
positive_inquiry	Charged at the rate
negative_inquiry	Charged for a provider error
no_external_cost	Genuinely 0.00 — no biller exists
no_published_rate	Unknown

The other four — the call never finished, it failed in a way no rate covers, nobody put it on a card, no call was made — are conclusions about one particular run, not properties of a rate. Offering them would invite recording a run's outcome as a price.

The override works both ways

• You can price a call the shipped sheet does not price at all (Focal, Sijilat)
• You can declare a call unknown that the sheet prices — and it will not fall back to our number, because you are saying you have never been billed the rate we wrote down

Failed calls

Held against the provider, not the service. Watheq bills a fixed 0.25 SAR for a 400 or 404 — a registration that came back not-found still costs money — and it bills the same whichever endpoint produced it, so pinning it to one service would be wrong and repeating it on each would be six copies of one number.

A configured failure rate still only applies to the statuses that mean the provider answered with a refusal. A 500, a timeout, or a request that never left the building stays unknown rather than being written down as free.

Subject-priced services

Elm charges by who is looked up: 3.96 SAR to verify a Saudi citizen, 3.12 for a resident. Those appear as separate rows, and a subject-specific rate you set overrides your own general one.

An identifier type matching neither prices as unknown rather than falling back to the cheaper of the two.

Where the cost shows up

• Entity page — a "Cost of checks" section, totalling this merchant's calls including retries and failures, with the caveat attached to the number
• Provider run page — the amount and its basis

A retry is a second invoice, so every call is counted. A reused screening made no new call and costs nothing.

The rate card

Confirmed against the Moyasar biller sheet. Full commercial registration and the company formation contract are 11.00 SAR each; national address 2.00; Neotek IBAN 0.30; Elm Yakeen 3.96 / 3.12.

RateCard::EFFECTIVE_ON dates runs priced from the shipped defaults. The sheet carries no printed effective date, so it is the transcription date — largely moot now that a configured rate carries its own.