Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Functional overview of payment exception recovery

Updated on June 22, 2022

The Payment Exception Recovery model workflow consists of a claim and transaction exception case types. The claim case is used for account and the transaction selection and capturing basic information about the exception transaction. The payment exception case type is created and assigned to fraud or non-fraud exception based on the supplemental information collected at the claim case level. The transaction exception case type continues the exception processing until the case is resolved.

Pega Foundation for Healthcare

The Claim case type is used for the following actions:

  • Select account: The search is initiated through an account or card number.
  • Select transaction: A list of transactions associated with the account or card are displayed in the transaction grid. The relevant transaction is selected to proceed with exception processing.
  • Collect supplemental information: The response to the question about customer participation helps to determine when an investigation into possible fraudulent activity is needed. If the customer participated in the transaction, then the claim is treated as a non-fraud case, otherwise the claim is treated as a fraud-related case. Basic fraud and non-fraud questionnaires are displayed to the customer service representative based on the response. The bank has the ability to add or change questions based on its policies and procedures.

The Transaction exception case type is used for the following actions:

Evaluate duplicate

The application looks for duplicate cases in exisiting claims to ensure that the dispute is not processed more than once by the customer service representatives. If any case is identified as a potential duplicate, the user can close the current case as a duplicate with status as Resolved-Duplicate or choose to ignore the duplicate case and continue with the dispute.

Low value write-off

The application evaluates the transaction against a bank-configured threshold condition and writes off a transaction if the disputed amount is less than the defined threshold.

Customer interview

The customer interview is used to select a main reason and sub reason for disputing the transaction. Questionnaires specific to the reason for the exception are presented to gather the details necessary to complete the intake. The DisputeReasonMatrix data type provides the information about the exception reason for a payment network. It also allows clients to add a new exception reason or remove a dispute reason. This data type is a configuration point for the client to add, update, or remove exception reasons for a specific payment network.

Exception validation

This is used to validate the transaction against a payment type mandated validation and conditions applicable for the selected exception reason. The validations data type provides the information about the validations available for a specific exception reason. Clients may configure validations based on the payment network they are implementing using the Payment Exception Recovery model workflow. If any validations fail or have an inconclusive status, then the case lands on the exception validation screen for users to either proceed with liability processing (write-off the case or mark it as customer liable) or continue to raise the exception regardless of any failed validations. Users may review the validations in the footer section with the statuses against each validation rule.

Evaluate provisional credit

This is an option to provide Provisional Credit (PC) for the disputed transaction based on the business rules the bank will configure in a decision table. Provisional credit is an interim credit that the bank provides to the customer for the disputed amount when the exception is under investigation. As shipped, the system evaluates the eligibility for PC based on the combinations exception type, product type, transaction type and reason code along with the transaction amount configured in a decision table. This logic can be extended by the bank based on its policies.

Submit to counter party

This process is a placeholder step with pre-processing or post-processing extension points for the clients to configure the exception and submit to a counterparty based on requirements for the payment network being implemented.


Accounting generates standard accounting entries for each action such as Provisional credit, Write-off, and Cardholder liable. Clients can update the entries with their chart of accounts and can customize them for policies or processing requirements.

Customer communication

Automatic correspondence acknowledging the receipt of an exception claim for processing is generated to send to a customer. Clients can configure the correspondence according to their needs and bank approved verbiage.


The following configurations are available for Payment Exception Recovery under the Configuration set Payment Exception Configurations:

  • Duplicate Search - Boolean data type with default value true
  • Enable Accounting - Boolean data type with default value true
  • Enable External Accounting - Boolean data type with default value true


The Payment Exception model workflow contains extension points for clients to extend the functionalities specific to the issuer’s requirements. For more information on extension points, refer the implementation guide.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us