Orders a background check under a payer-payee record. Either seat may order — the payer directly, naming a packageId; the payee, the contractor the check is run against, only against a requirementId, which is what authorises it. The calling Account must BE one of the two seats. Both Accounts are resolved from payerPayeeId, so neither is named in the body.

Placing the same order twice returns the existing active check rather than a duplicate: the order is keyed on the payer-payee record and the package. A payer who resets the requirement behind a check overrides that and gets a genuinely new order, because a reset is a demand for a fresh one.

A requirementId is a gate, not a link. It is checked and then discarded — the BackgroundCheck returned here does not reference it, and binding the Requirement to the check is a separate step. When it is supplied, the package comes from the Requirement's own configuration, and it overrides any packageId a payer sent alongside it. A payee sending one gets 422 instead — the configuration is not theirs to choose.

Supplying an externalId already in use for this account returns 409 ResourceConflict — create is not an upsert. externalId is not an order key either: the duplicate-order check above is keyed on the payer-payee record and the package, so a repeat order returns the existing check carrying whatever externalId it was ordered with.

409 ResourceConflict has two other causes, and they want opposite responses. Concurrent orders for one record and package are serialised, and a request that waits out that window without reaching the front gets a 409 meaning an earlier request is still in flight: retry it under a NEW Idempotency-Key, because reusing the old one replays this same 409 from the idempotency cache rather than placing the order. Separately, a requirementId whose definition names no configuration also gets a 409; that one is a misconfigured Requirement and retrying never clears it.

This operation answers 404 too, which is unusual for a create. The causes: the payerPayeeId names no record; the calling Account is not itself a seat on the one it names; the Requirement's configuration no longer resolves; or the package is not orderable — inactive, or scoped to a different payer. That last one is the commonest in practice and it reaches a payee too, whose Requirement may point at a package the payer has since deactivated. An Account that can read a record through an organization's branch is not thereby a seat on it and cannot order against it.

400 comes first for a payee. ANY request from the payee seat without a requirementId answers 400, whatever else it carries — there is nothing authorising it, so the fields are not examined. Send the requirementId before reading the 422s below.

422 covers the request shapes the record cannot support: a payer naming neither packageId nor requirementId; a payee who DID send a requirementId and also sent packageId, externalId or metadata, none of which are theirs to set on the payer's order; a record seating one Account on both sides; and — the everyday one — a record whose counterparty has not linked yet, which has no second Account to seat the order against.