---
title: "Get latest clearing rules configuration"
method: GET
path: "/v1/rules"
tags: ["Clearing rules"]
---

# Get latest clearing rules configuration

`GET /v1/rules`

## Request

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

Return the latest stored config JSON with metadata for the requested organization

## Query parameters

- `orgId` string, required

## Response `200`

Configuration found

- GetConfigResponse: Latest clearing rules configuration for the requested scope, with its version metadata
  - `checksum` string: SHA256 checksum of the stored configuration, prefixed with `sha256:`. Used to detect configuration changes.
  - `config` ClearingRulesConfig: 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.)
  - `description` string: Note explaining why the configuration changed, stored with the version for auditing
  - `orgId` string: Organization that owns the 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

## Other responses

- `400`: Invalid parameters
- `403`: Forbidden
- `404`: Configuration not found
- `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)