---
title: "Update clearing rules configuration"
method: PUT
path: "/v1/rules"
tags: ["Clearing rules"]
---

# Update clearing rules configuration

`PUT /v1/rules`

## Request

- Base URL: `https://sandbox.pismolabs.io/clearing-rules`
- URL: `https://sandbox.pismolabs.io/clearing-rules/v1/rules`
- Auth: HTTP bearer

Updates the latest configuration for a given scope, organization or program, and returns the new version and checksum. Persistence is asynchronous—the endpoint publishes an event and the immutable snapshot is written afterward, so it isn't guaranteed at response time. The [Pending transactions sent](https://developers.pismo.io/events/docs/networktransactions-pending-transactions-2) event reports clearing events that these rules route to the DLQ, and you can reprocess them with [Perform clearing reconciliation](https://developers.pismo.io/pismo-docs/reference/performclearingreconciliation). For background on the clearing flow, see [Clearing/Base II](https://developers.pismo.io/pismo-docs/docs/clearingbase).

## Request body

- PutClearingRulesRequest: Clearing rules configuration to create or update for an organization or a program.
  - `config` PatchableConfig, required: Clearing rules configuration shared across request and response models
    - `account_status` boolean: Route the clearing event to pending transactions when the account status isn't `NORMAL`? (If `false`, the platform processes the clearing normally.)
    - `card_not_found` boolean: Route the clearing event to pending transactions when the card isn't found in Pismo's records? (If `false`, the platform discards the event.)
    - `card_region_restriction` boolean: Route the clearing event to pending transactions when an international transaction was made with a domestic card? (If `false`, the platform processes the clearing normally.)
    - `clearing_with_zero_amount` boolean: Route the clearing event to pending transactions when the clearing amount is zero? (If `false`, the platform discards the event.)
    - `conciliation_deadline` integer: Maximum number of days after the authorization date in which the clearing transaction can still be received and processed. Past this deadline, the event goes to pending transactions
    - `different_processing_code` boolean: Route the clearing event to pending transactions when the clearing processing code doesn't match the authorization processing code? (If `false`, the platform discards the clearing.)
    - `installment_plan_verification` boolean: Route the clearing event to pending transactions when the installment plan differs from the authorized installment plan? (If `false`, the platform processes the clearing normally.)
    - `invalid_card_mode` boolean: Route the clearing event to pending transactions when the card mode is incompatible with the transaction type, such as credit or debit? (If `false`, the platform processes the clearing normally.)
    - `invalid_julian_date` boolean: Route the clearing event to pending transactions when the transaction carries an invalid Julian date? (If `false`, the platform uses the clearing date instead.)
    - `mcc_amount_exceeds_authorization` MCCAmountExceedsAuthorizationConfig: Merchant category codes and percentage tolerance used when the cleared amount exceeds the authorized amount
      - `mcc` string[]: List of merchant category codes sensitive to an amount mismatch between the authorization and the clearing
      - `percentage` integer: Percentage tolerance applied to the difference between the authorized and cleared amounts
    - `mcc_authorization_not_found` string[]: List of merchant category codes routed to pending transactions when the matching authorization isn't found. Codes outside this list keep the platform's current behavior
    - `not_permitted_operation` boolean: Route the clearing event to pending transactions when the operation isn't permitted for the program or the processing code? (If `false`, the clearing is discarded.)
    - `not_refundable_authorization` boolean: Route the clearing event to pending transactions when a cancellation is invalid or out of order? (If `false`, the cancellation is retained or discarded according to the current rule.)
  - `orgId` string, required: Organization that owns the configuration
  - `description` string: Note explaining why the configuration changed, stored with the version for auditing
  - `programId` string: Program the configuration applies to. Send it only for a program-scoped configuration.
  - `scope` 'ORG' | 'PROGRAM': Level a clearing rules configuration applies to: `ORG` covers every program in the organization, `PROGRAM` covers a single program
  - `updated_by` string: User or service account that requested the update.

## Response `200`

Configuration updated or no changes detected

- union
  - ClearingRulesResponse: Version metadata for the configuration that was created or updated
    - `checksum` string: SHA256 checksum of the stored configuration, prefixed with `sha256:`. Use it to detect configuration changes.
    - `orgId` string: Organization that owns the configuration
    - `programId` string: Program the configuration applies to. Returned only for a program-scoped configuration.
    - `scope` 'ORG' | 'PROGRAM': Level a clearing rules configuration applies to: `ORG` covers every program in the organization, `PROGRAM` covers a single program
    - `updated_at` string: Date and time the configuration was updated, in UTC. Format = yyyy-mm-ddThh:mm:ssZ.
    - `updated_by` string: User or service account that requested the update
    - `version` integer: Version assigned to this configuration, increased by one on every change
  - object
    - `message` string

## Other responses

- `201`: Configuration created
- `400`: Validation error
- `403`: Forbidden - orgId does not match x-tenant header
- `500`: Internal server error

---

[API](https://skmtc.dev/pismo/apis/pismo-clearing-rules-engine.md) - [All operations](https://skmtc.dev/pismo/apis/pismo-clearing-rules-engine/llms.txt) - [OpenAPI document](https://skmtc.dev/pismo/apis/pismo-clearing-rules-engine/revisions/cf5b0d750a38?raw)