Verkflo is in early access. Book a demo

Chargeback and dispute automation for card issuers

The agent reads each cardholder dispute and gathers the statement and transaction data. It maps the claim to a reason code under your scheme rules, checks the timing against your policy and hands the proposal to an analyst.

Book a demoSee how it runs

Works with

  • Card processor · via Custom REST
  • Core banking · via Custom REST

and any system with an API via Custom REST

What is chargeback and dispute handling for issuers?

  • The procedure

    When a cardholder disputes a transaction, the issuer decides whether to raise a chargeback. An analyst reads the claim, checks the statement and transaction data, picks a reason code and confirms the dispute is in time under your policy. If the merchant answers with a second presentment, someone weighs the two sides again.

  • What the agent does

    • Pulls the cardholder's statement and transaction data from the card processor

    • Maps the claim to a reason code per your scheme rules

    • Checks the age of the dispute against your policy

    • Compares the merchant's evidence with the original claim

  • What your team decides

    • Approving each chargeback proposal

    • Any provisional credit, under your policy

    • Whether a dispute is fraud, and what happens to the card

    • Whether to go to pre-arbitration

Example runs for disputes analysts, card operations and fraud teams

Sample data

Dispute Agent

Prepares each cardholder dispute from your scheme rules and policy.

  • API
  • Google Drive
  • +1

Trigger: Inbound webhook · new dispute

From a procedure Disputes · v1.5

Diego

A cardholder disputes a Lumen Print charge. Prepare the case.

Dispute Agent

  1. Pulled the cardholder's statement and the transaction data from the card processor through Custom REST
  2. Mapped the claim to a reason code, per your scheme rules
  3. The dispute is within the time your policy sets dispute.age_days <= policy.max_age_days
  4. Saved the statement and the transaction data to the case folder
  5. Asked an analyst to approve the chargeback proposal Waiting for a reviewerMaya: approved, raise the chargeback

Proposal ready. Maya approved the chargeback proposal, and your team raises the chargeback. The mapping, the timing check and the evidence are on the record.

5 steps · 1 review

Dispute Agent

Prepares each cardholder dispute from your scheme rules and policy.

  • API
  • Google Drive
  • +1

Trigger: Inbound webhook · new dispute

From a procedure Disputes · v1.5

Tom

The cardholder says they did not make a Harbor Lane card payment. Prepare the case.

Dispute Agent

  1. Pulled the card status, device and authentication data from the card processor through Custom REST
  2. The cardholder reports the transaction as not authorized dispute.claim == "not_authorized"
  3. Applied your fraud rules: the device and authentication data are new to this card device.known == false
  4. Asked the fraud team, because your rules route fraud disputes to a person Waiting for a reviewerPriya: treat as fraud, block the card per procedure
  5. Saved the card and device data and the decision to the case folder

Routed to fraud. The fraud team took the case and decided how to proceed under your procedure. The data checked and the decision are logged for reporting.

5 steps · 1 review

Dispute Agent

Prepares each cardholder dispute from your scheme rules and policy.

  • API
  • Google Drive
  • +1

Trigger: Inbound webhook · second presentment received

From a procedure Disputes · v1.5

Marcus

The merchant has answered the Corvid Freight dispute. Compare the evidence.

Dispute Agent

  1. Pulled the merchant's evidence and the original claim through Custom REST
  2. Read the merchant's documents in the case folder
  3. The merchant's evidence addresses part of the cardholder's claim merchant.evidence_covers_claim == "partial"
  4. Queued the pre-arbitration decision for an analyst Waiting for a reviewerDiego: take it to pre-arbitration

Decision queued. Diego chose to proceed to pre-arbitration under your policy. The comparison of the two sides is attached to the case.

4 steps · 1 review

Setting up the Dispute Agent

Connect your systems

Read disputes, card status and transactions from your card processor through Custom REST, keep case evidence in Google Drive, and connect other systems that have an API.

  • Google Drive
  • Sumsub
  • ComplyAdvantage
  • Card processor · via Custom REST
  • Core banking · via Custom REST

Write the rules

Which claims map to which reason codes, and which disputes go to the fraud team or an analyst, are CEL rules written into your procedure.

Sample data
dispute.age_days > policy.max_age_daysAsk an analyst
dispute.claim == "not_authorized"Route to the fraud team
merchant.second_presentment == trueQueue pre-arbitration decision

Add reviewers where the procedure says

An analyst approves each proposal before anything is raised, with the cardholder's claim and the data side by side. Any provisional credit follows your policy and is decided by a person.

Sample data

Review requested: chargeback proposal

Claim
Cardholder disputes a charge
Rule
proposal requires analyst approval
Procedure
Disputes · v1.5

Approve proposalRequest more information

Start it from the event

A new dispute from your card processor starts a run by webhook, and so does a merchant's second presentment. A daily schedule lists disputes close to the deadline your policy sets.

  • Inbound webhook · new dispute
  • Daily at 06:00 · disputes near your policy deadline
  • Inbound webhook · second presentment received

Version and evaluate

Test the reason-code mapping on disputes your team has already decided, such as goods not received, an unauthorized card payment and a partial merchant response. Failing cases block publishing.

Sample data

Disputes · v1.5Published

12/12 scenarios passed

Disputes · v1.2 Superseded

Disputes · v1.1 Superseded

Share with the team

Disputes analysts approve proposals, the fraud team reviews the disputes routed to it, and card operations can read each case. An Author keeps the reason-code mapping in the procedure.

  • Admin
  • Author
  • Reviewer
  • Auditor

Questions about chargeback and dispute automation

Does the agent raise chargebacks?

No. It prepares the proposal and an analyst approves it. Your team then raises the chargeback with your card processor.

Is this for merchants or issuers?

Issuers. The agent works from the card issuer's side of a cardholder dispute: the claim, the statement and the scheme rules you follow.

How does it pick a reason code?

Your procedure maps claim types to reason codes as CEL rules. The agent applies that mapping and shows it to the analyst with the claim.

What happens with a fraud claim?

A claim the cardholder did not authorize goes to your fraud team, as in the second example. They decide on the card and the case under your procedure.

Controls your auditors will ask about

These controls apply to each agent you build. Sample data

Related use cases

See all use cases

Run this procedure as an agent

Book a demo with your own version of this procedure, and we'll show it running with each step logged.

Book a demo