Credit Disputes
Access Prerequisites
- Permission (module):
creditDispute(open/update disputes). - License/Feature:
CREDIT_INVESTMENTSenabled on the tenant license (Vault). - Menu container: TOKENIZATION → group Tokenized Credit
What it is / when to use
The Disputes screen records and resolves contestations linked to a Charge — for example, the debtor claims they have already paid, or that the charge is fraudulent or duplicated. Each dispute has a type, reason, who opened it, a progress status, and, upon resolution, who resolved it and the resolution notes.
Use this screen to open a dispute against a specific charge and to update/resolve existing disputes (under review, resolved valid, resolved invalid).
Prerequisites
- Permission:
creditDispute(double permission — CPM enum + dynamic module in DB). - License/Feature:
CREDIT_INVESTMENTSenabled. Without it the group does not appear in the menu at all. - Dependencies from other screens: selecting an existing Charge (Charges) is required — the dispute is always linked by
chargeId.
Step by step
- Go to the menu Tokenized Credit → Disputes.
- Search and select a Charge (the search filters by reference code/ID).
- The disputes for that charge are loaded.
- To open a new one: choose the Type and describe the Reason, then click Create dispute (confirmed in the bottom-sheet).
- To handle an existing one: ⋮ → Update opens the dialog to change the Status and record Resolution Notes.
Filters and columns
| Filter/Column | What it shows | Data source |
|---|---|---|
| Charge (selector) | Charge selected to list its disputes | search over getCharges(); required |
| Charge (column) | Charge code/ID | Dispute.chargeId (resolved via chargeMap) |
| Type | DEBTOR_CLAIM, FRAUD, DUPLICATE, OTHER | Dispute.disputeType |
| Status | Progress: UNDER_REVIEW, RESOLVED_VALID, RESOLVED_INVALID (among other backend statuses) | Dispute.status |
| Opened at | Opening date | Dispute.openedAt |
| Resolved at | Resolution date | Dispute.resolvedAt |
Fields (dispute opening)
| Field | What it is | Required? | System/backend effect |
|---|---|---|---|
| Type | Nature of the contestation | Yes | Stored in disputeType; default DEBTOR_CLAIM. |
| Reason | Free text describing the dispute | No | Stored in disputeReason. |
| Opened by | Operator who opened it | Automatic | openedBy = logged-in operator ID (or system). |
Update (dialog)
| Field | What it is | Required? | System/backend effect |
|---|---|---|---|
| Status | UNDER_REVIEW / RESOLVED_VALID / RESOLVED_INVALID | Yes | updateDispute(id, { status }); without a status the update is blocked. |
| Resolution Notes | Justification for the decision | No | Stored in resolutionNotes; resolvedBy = logged-in operator. |
Actions and modals
- Select charge / Clear: sets the
chargeIdthat filters/opens disputes. - Create dispute:
createDispute(chargeId, { disputeType, disputeReason, openedBy })after confirmation. Requires a selected charge. - Update (dialog):
updateDispute(id, { status, resolutionNotes, resolvedBy }); resolving asRESOLVED_VALID/RESOLVED_INVALIDcloses the dispute.
Opening/resolving disputes may trigger step-up (password + MFA, X-Step-Up-Token) depending on the environment.
Business rules / cautions
Attention
- Charge is required. A dispute is always tied to a charge; without selecting one, the screen blocks creation/listing.
- Resolving is a merit decision.
RESOLVED_VALID(the contestation is upheld) vsRESOLVED_INVALID(dismissed) have distinct downstream effects — record the resolution notes for audit purposes. - A valid resolution may trigger a buyback/adjustment. A valid fraud/duplicate dispute frequently leads to a Buyback or deal cancellation.