Skip to main content

Pega Marketplace Terms of Use

Payment Exception Recovery – Model Workflow

Represents a model workflow that can be used by our clients to rapidly deploy a non-card payment exception process.

By using or submitting listings via the Pega Marketplace, you agree to our Terms of Use.


Payment Exception Recovery Model Workflow is a structured way for our clients to easily expand their payment exception processing based on their business needs. The model workflow provides standard exception stages and steps with configuration options that allow our clients to define, design and quickly deploy new payment exceptions to answer their business and market needs. Payment Exception Recovery focuses on standard disputes and fraud processing steps and stages as well as two case types. The first case type is Claim Case to support the customer level content and to align transactions to the claim details. Payment Exception Recovery also delivers a Transaction Case to deliver individual resolutions to the transactions that are part of the claim case. The model expects the business to configure the questions that are required for each case type, the processing steps that are part of each payment type as well as the options that are possible for recovery or resolution based on our client needs. Pega Product Development confirmed the value of the Payment Exception Recovery model workflow when we used it to add Zelle Exceptions to Pega Smart Dispute Issuer 8.7.

Key Features

Claim case type is used for the below actions:

  • Select account: The search is initiated through an account or card number.
  • Select transaction: List of transactions associated with the account or card are displayed in the transaction grid as radio buttons. The relevant exception transaction is selected to proceed further in the Payment Exception Recovery processing.
  • Collect supplemental information: The response to the question about customer participation determines the possible fraudulent activity. If the customer participated in the transaction(s) within the claim it is considered as non-fraud. If the customer did not participate in the transaction(s) in the claim, the claim is considered fraud. Basic fraud and non-fraud questionnaires are displayed to the customer service representative based on the response.

Transaction case type is used for below actions:

  • Evaluate duplicate: The application searches for duplicate cases to ensure that the dispute is not processed more than once by the client 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 claim and the transactions against the business defined threshold for low dollar write-off. In the case of the disputed item each transaction is reviewed for write-off. If the claim is determined to be fraud the claim is reviewed for low dollar write-off to maintain the full details of the fraudulent transactions associated with the claim.
  • Customer interview: This is used to select the reason and sub reason for the disputed transaction and answer the questionnaires specific to the reason for the exception and questions necessary to complete the case details. . The DisputeReasonMatrix data type provides the information about the exception reason for a payment network. 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 the payment type mandated validation and conditions applicable for the selected exception reason code. The validations data type provides the information about the exception validations available for a specific exception reason. Clients can also add new exception validations or remove exception validations. 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 the failed validations. Users can 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 exception transaction based on the configuration in the decision table. Provisional credit is an interim credit that the bank provides to the customer for the exception amount while the case is under investigation. The system uses a configurable decision table to evaluate the eligibility for PC based on exception type, product type, transaction type, reason code and transaction amount.
  • 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 the counterparty based on their processing requirements.
  • Accounting: 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 that are specific to their institution or the payment type.
  • Customer communication: Customer Communication generates an automatic correspondence acknowledging the receipt of the exception claim for processing to the payor. Clients can configure the correspondence according to their needs.
  • Configurations: There are currently three configurations available for Payment Exception Recovery under the Configuration set “Payment Exception Configurations”.
    • Duplicate Search – Confirming if identical or similar claims have been entered previously to avoid duplicate cases in process.
    • Enable Accounting – Part of the claim and transaction cases resolution includes accounting messages for the required debits and credits that are delivered to the client internal systems based on configuration.
    • Enable External Accounting – If there is a requirement for accounting messages to be sent to an external system or 3rd party chart of accounts this configuration is possible during deployment.
  • Extensions: The Payment Exception Recovery 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.





Compatible with

Pega Platform 8.7

Product Owner

Kiran Kumar Kolluru

Last updated

June 30, 2022

Product Capability

Case Management


Screenshot 5 Screenshot 4 Screenshot 3 Screenshot 2 Screenshot 1
Share this page Share via x Share via LinkedIn Copying...

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us