Use cases

Sort payment dispute claims by what really happened

UK, EU and US rules. Tells fraud from scams, merchant failures and unknown names, and flags words that contradict the form. People decide liability.

Ask for an invite

Try it on this example

Example · Fraud picked in the form, for a free trial the customer cancelled

Market (UK, EU or US): EU

Channel (form, chat, email or call transcript): form

Reason picked in the dispute form (empty if none): Fraud: I did not make this transaction

Transaction as it appears on the statement: VIDORA*PREMIUM 3120555

Customer's description of the problem

I did not allow these payments and I want my money back. In June I signed up for the 7 day free trial of Vidora to watch one series. I cancelled it in the app settings on day 5 and I have the confirmation email from them saying "your subscription has been cancelled". But they took 12,99 EUR on 1 July, 1 August and 1 September. I only saw it now when I checked my statement. I emailed Vidora support twice last week and got no answer. My card is still in my wallet and nobody else uses it. I can send the screenshot of the cancellation email.
  1. Which description best fits what the customer says happened with the transaction?Cancelled but still charged100%
  2. Does the customer say a payment, charge or transfer was not made or allowed by them, or is wrong?Yes99%
  3. Does the claim text describe a different problem from the reason picked in the dispute form?Text contradicts the reason98%
  4. Does the customer say the card, the card details or the phone holding the card were lost, stolen or taken?No91%
  5. Does the customer say they tried to sort out the problem with the merchant first?Yes98%
  6. Does the customer say they shared card details, a one-time passcode, a PIN or a login, or approved a prompt in the app, because someone asked them to?No91%
  7. Does the customer say or suggest that someone in their family or household may have used the card or account?No94%
  8. Does the customer mention evidence they hold, such as receipts, emails, a cancellation confirmation, tracking or screenshots?Yes99%
  9. Is there enough in the claim to tell which kind of dispute it is?Yes91%

These are real answers stored from one run on this example.

The prism behind it

Sort payment dispute claims by what really happened9 questions

Fields

  • Market (UK, EU or US)
  • Channel (form, chat, email or call transcript)
  • Reason picked in the dispute form (empty if none)
  • Transaction as it appears on the statement
  • Customer's description of the problem

Context

These are dispute claims from cardholders and account holders of a card issuer, sent through our app, a partner's app, chat, email or a call. The customer describes a transaction they say is wrong. Each claim is read on arrival so it reaches the right team: the fraud disputes team for payments the customer did not make or allow, the scam claims team for payments the customer made because they were tricked, the chargeback team for problems with a merchant, and the customer help team when the customer may simply not recognise a charge that is theirs. The market field says which rules apply. UK rules (Payment Services Regulations 2017): the customer must tell us about an unauthorised or incorrectly executed payment without undue delay, and no later than 13 months after the debit date. We refund an unauthorised payment by the end of the business day after we become aware of it, unless we have reasonable grounds to suspect fraud by the customer and report it. A payment the customer made themselves because they were tricked is not an unauthorised payment; it goes to the scam claims team, where the rules on scam reimbursement apply. EU rules (the second Payment Services Directive, PSD2, Articles 71, 73 and 74, as the member state has put it into law): the same shape. The customer notifies without undue delay and no later than 13 months after the debit date. We refund an unauthorised payment immediately, and no later than the end of the next business day after we note it or are told of it, unless we have reasonable grounds to suspect fraud and give those grounds to the national authority in writing. The customer may have to bear up to EUR 50 of the loss from a lost, stolen or misappropriated card, and all of it only if they acted fraudulently or, with intent or gross negligence, failed to keep the card and its security details safe or to report its loss. Where we did not require strong customer authentication, the customer bears no loss unless they acted fraudulently. A person decides any of this. US rules: for debit cards and accounts (Regulation E), a notice of error may be oral or written, and we investigate within 10 business days, or within 45 days if we give provisional credit within those 10. For credit cards (Regulation Z), a billing error notice is written and must reach us within 60 days of the first statement that shows the error; goods or services not delivered as agreed count as a billing error. Card schemes group disputes into families such as fraud, authorisation, processing errors and consumer disputes, each with its own reason codes and time limits. The chargeback team picks the reason code from the transaction data. These answers never pick a reason code, decide liability, or approve or refuse a refund. Dates, amounts, business days and which clock applies are worked out by code from the market, the card type and the time the claim arrived. Card numbers are masked before the text reaches us.

Questions

  1. Which description best fits what the customer says happened with the transaction? Choice

    Judge from what the customer describes, not from the reason picked in the form. Choose one option. "Made it but was tricked" is for a payment the customer made or approved themselves; "Did not make or allow it" is for a payment made by someone else without the customer taking part.

    • Did not make or allow it Someone else used the card, the card details or the account, and the customer did not make, approve or agree to the payment.
    • Made it but was tricked The customer made or approved the payment themselves, to someone who turned out to be a scammer or because someone posing as the bank, the police or another trusted body talked them into it.
    • Goods or services not received The customer paid a real merchant for goods, a service, a booking or a subscription and did not get it.
    • Not as described or faulty The customer got the goods or service, but they were faulty, damaged, counterfeit or different from what was described.
    • Cancelled but still charged The customer cancelled a subscription, a free trial, a booking or a recurring payment and was charged after cancelling.
    • Charged twice or wrong amount The customer made the payment, but was charged more than once for it or charged a different amount from the one agreed.
    • Refund promised but not received The merchant agreed to a refund or issued a credit note, and the money has not reached the customer.
    • Cash not dispensed A cash machine took the amount from the account but gave out less cash, or none.
    • Does not recognise the name The customer does not know what the charge is or who the merchant is, and does not say anyone else used the card. It may be theirs under a different trading name.
    • Not a dispute The customer asks a question, asks about a pending payment, or makes another request without saying any transaction is wrong.

  2. Does the customer say a payment, charge or transfer was not made or allowed by them, or is wrong? Yes / No

    Count a customer who says a payment, charge or transfer was not made or allowed by them; was taken twice, for the wrong amount or after they cancelled; paid for goods or services that never arrived or were not as agreed; or that a promised refund or cash from a machine never reached them. Count it however it is worded, including "I don't recognise this payment", and a question such as "what is this charge?" when the customer also says it is not theirs. Do not count a plain question about a payment the customer accepts. This can be the notice that starts a legal or scheme clock: code decides which clock applies, and people decide whether the claim is valid. Yes: The customer says a payment is not theirs or is wrong in one of these ways. No: The customer disputes no payment, or only asks about one they accept.

  3. Does the claim text describe a different problem from the reason picked in the dispute form? Choice

    Compare the reason selected with what the claim text describes. A form reason of fraud or "I did not make this" next to a text describing a subscription, a purchase or a merchant problem is a mismatch, and so is the reverse.

    • Text matches the reason The claim text describes the same kind of problem as the reason picked, or adds detail consistent with it.
    • Text contradicts the reason The claim text describes a different kind of problem from the reason picked, for example fraud picked for a charge the customer signed up for.
    • No reason picked The reason field is empty, so there is nothing to compare.

  4. Does the customer say the card, the card details or the phone holding the card were lost, stolen or taken? Yes / No

    Count a lost or stolen card, a stolen phone with the card on it, details taken in a data breach the customer mentions, or a card that never arrived. Yes: The customer says the card, its details or the device holding it were lost, stolen or taken. No: The customer says they still have the card, or says nothing about it being lost or taken.

  5. Does the customer say they tried to sort out the problem with the merchant first? Yes / No

    Count emails, calls, chats, returns or complaints to the merchant about this transaction, whether or not the merchant answered. Yes: The customer says they contacted the merchant about this transaction. No: The customer does not say they contacted the merchant.

  6. Does the customer say they shared card details, a one-time passcode, a PIN or a login, or approved a prompt in the app, because someone asked them to? Yes / No

    Count giving any of these to a caller, a website or a message, reading out a code, or tapping approve on a payment prompt at someone's request. A person reviews every such claim; this never decides a refund. Yes: The customer says they shared or approved something of this kind at someone else's request. No: The customer says they shared nothing, or does not mention sharing anything.

  7. Does the customer say or suggest that someone in their family or household may have used the card or account? Yes / No

    Count a child, partner, relative or flatmate who had access to the card, the phone or a device where the card was saved, or a game or app used by someone at home. Yes: The customer says or suggests someone they live with or are related to may have made the transaction. No: Nothing points to someone in the customer's family or household.

  8. Does the customer mention evidence they hold, such as receipts, emails, a cancellation confirmation, tracking or screenshots? Yes / No

    Count any record the customer says they have or can send: receipts, order or cancellation confirmations, emails or chats with the merchant, tracking numbers, photos or screenshots. Yes: The customer mentions at least one such piece of evidence. No: The customer mentions no evidence.

  9. Is there enough in the claim to tell which kind of dispute it is? Yes / No

    Read every field together. One clear sentence can be enough. Yes: The claim says enough about what happened to choose a dispute type with confidence. No: The claim is too short, vague or contradictory to tell what happened, for example "wrong charge pls fix".

Lens columns

dispute_type, dispute_type_probability, payment_dispute, payment_dispute_probability, reason_mismatch, reason_mismatch_probability, card_lost_or_stolen, card_lost_or_stolen_probability, contacted_merchant, contacted_merchant_probability, shared_credentials, shared_credentials_probability, household_use, household_use_probability, evidence_mentioned, evidence_mentioned_probability, enough_information, enough_information_probability

Run it on your own text

Add this prism in the app, change any question, and test it on a file of your own.

Ask for an invite