Integration Guides
  1. Operations

Customer disputes

How customer-initiated disputes flow through Scan to Pay and the parties involved in resolution.

A customer dispute is what happens when a cardholder challenges a transaction — they don't recognise it, didn't authorise it, or claim they didn't receive what they paid for. The dispute lands at the issuing bank, who works with the acquirer and merchant to investigate and resolve.

Scan to Pay sits in the middle of this process. We don't initiate disputes (cardholders do, through their bank); we don't resolve them (issuing and acquiring banks do); but we provide the transaction evidence, status visibility, and refund mechanism that all parties need.

Who's involved

PartyRole
CardholderRaises the dispute with their issuing bank
Issuing bankReceives the dispute, investigates with the cardholder, opens a chargeback with the acquirer if warranted
Acquiring bankReceives the chargeback claim, queries the merchant for evidence, manages the financial side of the dispute
Merchant / PSPProvides transaction evidence (receipt, delivery proof, customer authorisation logs); processes refund if dispute is upheld
Scan to PayProvides transaction details, status visibility, and the refund mechanism. Surfaces dispute-related state changes via webhook

The cardholder almost never contacts the merchant or Scan to Pay directly — the dispute always flows through their issuing bank first.

The standard process

   Cardholder            Issuing bank        Acquiring bank        Merchant / PSP
   ──────────            ────────────        ──────────────        ──────────────
        │                       │                    │                    │
        │  raises dispute       │                    │                    │
        ├──────────────────────►│                    │                    │
        │                       │                                          │
        │                       │  investigates with the cardholder        │
        │                                                                  │
        │                       │  if warranted, opens chargeback          │
        │                       ├───────────────────►│                    │
        │                       │                    │                    │
        │                       │                    │  requests evidence │
        │                       │                    ├───────────────────►│
        │                       │                    │                    │
        │                       │                    │◄──── evidence ─────┤
        │                       │                    │      (or refund)   │
        │                       │                    │                    │
        │                       │  case adjudicated  │                    │
        │                       │◄───────────────────┤                    │
        │                                                                  │
        │  resolution           │                                          │
        │◄──────────────────────┤                                          │

The standard dispute process within your acquiring bank applies unchanged. Scan to Pay doesn't introduce a separate dispute workflow — we just provide the integration points.

What you do as a merchant or PSP

When your acquirer raises a chargeback against a Scan to Pay transaction, they typically ask for:

  1. Transaction evidence — proof the transaction occurred, with the customer authorising it
  2. Cardholder authorisation details — the PIN-based AMT auth or 3DS challenge that authenticated the payment
  3. Delivery / fulfilment proof — that you delivered what the customer paid for
  4. Customer correspondence — any contact history relevant to the dispute

Scan to Pay can help with (1) and (2):

  • Pull the transaction details via Querying transactions or look it up in the Portal
  • The bankResponse.authCode and retrievalReferenceNumber are the standard identifiers your acquirer will ask for
  • The clientMsisdn and authentication method (AMT vs 3DS) are recorded on the webhook payload

For (3) and (4), pull from your own systems.

Refunding to resolve

If you decide to refund rather than fight the dispute, use the standard refund flow — same API, same endpoint as any other refund. See Refunds and reversals.

A refund processed before the chargeback completes typically dissuades the cardholder from continuing the dispute, but doesn't automatically close the chargeback case at the acquirer. Coordinate with your acquirer's disputes team to ensure both sides are reconciled.

Scan to Pay's role

We're not a party to the dispute — the financial and contractual relationship is between the cardholder, issuer, acquirer, and merchant. What we provide:

  • Transaction history — full payload of every transaction, including authentication evidence
  • Webhook visibility — chargeback-related state changes (typically END_REVERSED or END_REFUNDED) flow through the standard webhook
  • Dispute Management Support — for technical issues, integration questions, or unusual cases, our Dispute Management team can advise. Email [email protected]. See Support.

We don't represent merchants in disputes, don't adjudicate, and don't have authority over your acquirer's process. We're a transaction record-keeper for this purpose.

Liability shift

For transactions authenticated via PIN-based AMT or 3D Secure, liability for fraud-related chargebacks shifts to the issuing bank in supported markets. This is a scheme rule, not a Scan to Pay-specific guarantee — but the platform's enforcement of authenticated transactions is what enables the shift.

In practice this means: if a cardholder claims they didn't authorise a transaction that you have on record as PIN-authorised, the issuer is typically liable rather than you. Your acquirer will be familiar with the rule and how it applies to your merchant category.

What's next

Updated 3 days ago