# Public payment API documentation benchmark — rules 1.0

This is a documentation review method, not a live security test. The six sample rows are synthetic and example.invalid is not an evidence source.

## Population
Set a cutoff date. Include a distinct merchant payment API offered for use in Nigeria only when its legal entity is matched to a CBN financial institution list at that date. Save list/product URLs, entity name, category, inclusion decision, aliases, and exclusions. Unresolved entity matches are excluded pending resolution. Eligible products without documentation stay in the dataset as unclear.

## Decision rules
Read public-api-benchmark-rules-v1.csv. Present requires all stated parts. Absent needs an explicit public statement that the feature is unavailable. Missing/partial/conflicting/inaccessible sources mean unclear, with reason code missing_document/partial_rule/conflicting_sources/inaccessible_source. These six rules are Simpa Labs study rules, not an OWASP certification scheme.

## Evidence and review
Record product/API version, rule version, URL, read date, exact section, factual note, reviewer ID, and permitted snapshot hash. Retain attempted URLs for missing documents. Two reviewers score independently. Preserve initial decisions; a third reviewer resolves disputes against saved sources and rules. Unresolved evidence remains unclear. Cutoff-date sources support corrections; later docs belong in a new release.

## Release
Publish population file, all rows, rule file, source notes, review log, and correction history. Report three counts for each rule against every eligible product. Do not treat unclear as absent or rank live security from documentation. The sample has one invented product and six rule rows: 3 present, 1 absent, 2 unclear. This total is a worked profile, not a per-rule result. Each rule has a denominator of one product in this sample.

Sources: https://www.cbn.gov.ng/Supervision/finstitutions.html ; https://docs.stripe.com/api/idempotent_requests ; https://docs.stripe.com/webhooks/signature ; https://www.rfc-editor.org/rfc/rfc9116

License: CC BY 4.0. Credit Simpa Labs and identify changes. Updated 2026-10-01.

## Freeze a review plan
Before collection, record study_id, release_id, cutoff_date, collection_start, collection_end, included CBN list categories, product eligibility rule, and reviewer IDs. Define a merchant payment API as a server API that lets a merchant create or collect a customer payment. A payout-only API, consumer app without a merchant API, or private integration is outside this population. Search every entity in the chosen lists and publish the search steps; a convenience list of familiar brands is not a census.

The unit is one distinct API product, not one endpoint or one brand alias. Choose its active production version at the cutoff. Keep obsolete versions outside the main counts and record the exclusion. If a product has several active versions with different documentation, score each as a separate product-version unit and state that choice before review. A licensed entity match establishes study eligibility only; it does not show that every product has regulatory approval.

## Data files and keys
A population row needs study_id, product_id, legal_entity, entity_list_url, list_category, product_name, api_version, product_url, cutoff_date, eligibility, exclusion_reason, and aliases. Use eligibility values included, excluded, or unresolved. product_id must be unique within a release. Unresolved matches are listed but stay outside the scored denominator.

A final score row needs study_id, release_id, product_id, api_version, rule_version, rule_id, score, reason_code, source_url, read_date, source_section, evidence_note, snapshot_sha256, reviewer_a, score_a, reviewer_b, score_b, adjudicator_id, and final_reason. A product_id plus rule_id identifies exactly one final row per release. Store multiple source references in a linked evidence table with an evidence_id. Retain both initial scores even if they agree. The sample CSV demonstrates decision fields with invented evidence; it cannot stand in for a real collection file.

Use score values present, absent, or unclear. Reason codes are all_elements_met, explicit_unavailable, missing_document, partial_rule, conflicting_sources, or inaccessible_source. Empty fields mean not recorded; they must never mean absent. Explain a missing snapshot if storage permission or retrieval failed. Dates use YYYY-MM-DD. SHA-256 values identify saved bytes; they establish file identity, not whether the source is true.

## Apply the same source search
For each product, read its public API reference, linked developer help, security policy, and security.txt. Search those sources for each rule's terms and record the pages visited and search terms. Record retrieval failures and a second attempt on a later collection day. A login-only source is inaccessible for this public review. Document scope and version must match the scored product; a general blog statement cannot replace an API-specific requirement without a clear link to that product.

Evidence must exist by the cutoff. A page first captured after the cutoff with no dated archive cannot establish its earlier contents. Keep it outside the frozen release and record that limit. For conflicting sources, record both passages and dates; do not choose the more favorable one. Missing docs use missing_document; a known page that cannot be opened uses inaccessible_source. Partial instructions use partial_rule even when the reviewer believes the feature works.

## Check a release before sharing
For N included products, require exactly 6 × N final rows, six known rule IDs per product, no duplicate keys, and one rule version. For each rule, present + absent + unclear must equal N. Excluded and unresolved products do not enter N. List corrections with the old score, new score, source, date, and reason. Zero included products means no percentages can be calculated. Report reviewer agreement as agreeing initial pairs divided by all paired rows, with the numerator and denominator; agreement is not proof of correctness.
