Flowchart for betalingsindsigelsesproces

Skabelon til betalingsindsigelser med transaktionsspørgsmål, tidlig afklaring, formel berettigelse, svar, finansielle reguleringer, afstemning og afslutning.

Brug denne skabelon

Hvad er flowchart for betalingsindsigelses?

En kortindehaver, der sætter spørgsmålstegn ved en betaling, kan have brug for en forklaring, en anmodning om refusion hos forhandleren, en tidlig indsigelsesdialog eller en formel indsigelse. Behandles alle fire som samme chargeback-forløb, opstår der unødige sager og uklare løfter. Skabelonen begynder med én registrering, som kortudstederen ejer, med transaktion, problem, datoer, kontaktoplysninger og tidligere servicetiltag. Manglende oplysninger sendes tilbage til kortindehaveren, mens en fuldstændig registrering først afklarer, om kortudstederen kan forklare eller løse spørgsmålet som en forespørgsel.

Hvis kortudstederens afklaring ikke løser spørgsmålet, kontrollerer processen, om der findes en tidlig indsigelses- eller refusionsvej for transaktionen. Resultatet kan afslutte sagen uden regulering, afslutte den med en aftalt regulering eller føre den videre. Kun en uløst sag når den særskilte port for formel berettigelse, hvor kortudstederen anvender de aktuelle regler for den pågældende betalingsvej. Når tilgængelighed og berettigelse holdes adskilt, forveksles en utilgængelig tidlig vej ikke med formel manglende berettigelse, og en mulig forespørgsel fremstilles ikke som en garanteret indsigelsesret.

Den formelle gren er bevidst en kompakt overlevering: åbn og fordel sagen, orientér forhandleren, indhent et målrettet svar ved behov, og gennemgå resultatet. Det økonomiske arbejde deles efter afgørelsen. Kortudstederen ejer posteringen på kortindehaverens konto, mens betalingsbehandleren eller indløseren håndterer den tilsvarende regulering på forhandlersiden. Kortudstederens medarbejdere kommunikerer resultatet, og økonomi afstemmer sags-, konto- og afviklingsreferencer. Denne kundevendte indgang kan overlevere den detaljerede chargeback-drift til chargebackhåndteringsprocessen uden at kopiere dens sagskø og porteføljekontroller.

Hvad dette flowchart dækker

I denne skabelon

  • Kortindehaverens transaktionsspørgsmål, fuldstændig registrering hos kortudstederen og en løkke for manglende transaktions- eller kontaktoplysninger
  • Kortudstederens afklaring og forklaring før en særskilt kontrol af, om en tidlig indsigelses- eller refusionsvej er tilgængelig
  • Formel indsigelsesberettigelse først efter, at en tidlig løsning ikke har afsluttet spørgsmålet, vurderet efter de gældende sagsregler
  • Formel sagsfordeling, forhandlerens accept eller dokumentation, fuldstændighedskontrol og et registreret resultat
  • Separate reguleringer for kortindehaver og forhandler, kommunikation fra kortudstederen, økonomisk afstemning og afslutning

Hvornår du skal bruge skabelonen

  • Kortindehaveres transaktionsspørgsmål flyttes mellem service- og indsigelsesteams uden en ensartet registrering ejet af kortudstederen
  • Enkle transaktionsforklaringer, refusionsanmodninger til forhandlere og formelle indsigelser åbnes gennem samme driftsvej
  • Teams forveksler muligheden for en forespørgsel eller tidlig indsigelse med berettigelse til en senere formel sag
  • Kommunikationen om resultatet angiver ikke, hvem der ejer posteringen hos kortindehaveren, og hvem der håndterer reguleringen hos forhandleren
  • Organisationen har brug for et leverandørneutralt indgangsflow, før den detaljerede chargebackhåndtering begynder

Sådan fungerer det

  1. Byg én fælles indgang

    Angiv de transaktions-id'er, kortindehaverens problem, kontaktoplysninger, kontokontekst og tidligere refusions- eller servicetiltag, som kortudstederen skal bruge. Markér, hvilke manglende felter der sætter afklaringen på pause, og lad kortudstederens team beholde ejerskabet, mens oplysningerne indhentes.

  2. Definér løsning gennem afklaring

    Dokumentér, hvilke transaktionsspørgsmål kortudstederen kan forklare eller løse ud fra konto- og betalingsdata. Registrér forklaringen og resultatet, så en afsluttet forespørgsel ikke havner i en tidlig eller formel indsigelseskø, blot fordi kortindehaveren kontaktede indsigelsesteamet.

  3. Adskil tilgængelighed fra berettigelse

    Kortlæg først de tidlige forespørgsels- eller refusionsveje, der er tilgængelige gennem hver betalingsbehandler eller indløser. Definér derefter den formelle berettigelseskontrol, som kun bruges, når den tidlige løsning mislykkes, herunder aktuelle sagsregler og kilden til den sagsspecifikke frist.

  4. Hold den formelle gren fokuseret

    Navngiv den, der åbner og fordeler den formelle sag, hvad forhandleren modtager, og hvilke transaktions-, autorisations-, leverings- og kommunikationsdata der belyser problemet. Send ufuldstændig dokumentation retur til rettelse, før kortudstederen registrerer det formelle resultat.

  5. Placér ejerskabet for reguleringer

    Angiv posteringen på kortindehaverens konto hos kortudstederen og den tilsvarende regulering hos betalingsbehandleren, indløseren eller forhandleren for hvert økonomisk udfald. Hold kortudstederens kommunikation adskilt, og afstem derefter sags-, konto- og afviklingsreferencer før afslutning.

Ofte stillede spørgsmål

Hvad er hovedtrinnene i en betalingsindsigelsesproces?

Registrér kortindehaverens transaktionsspørgsmål, og indhent manglende oplysninger. Forsøg først kortudstederens egen afklaring, og kontrollér derefter, om en tidlig indsigelses- eller refusionsvej er tilgængelig. Hvis den ikke løser problemet, vurderes formel berettigelse, sagen fordeles, et eventuelt forhandlersvar indhentes, og resultatet registreres. Gennemfør de særskilt ejede reguleringer på konto- og forhandlersiden, kommunikér gennem kortudstederen, afstem registreringerne, og afslut sagen.

Betyder en tilgængelig tidlig indsigelsesvej, at en formel indsigelse er berettiget?

Nej. Tilgængelighed handler om, hvorvidt en forespørgsel, en refusion hos forhandleren eller en tidlig indsigelsesdialog kan forsøges for transaktionen. Formel berettigelse er en senere og særskilt afgørelse, som kun træffes, hvis den tidlige løsning ikke afslutter spørgsmålet. Den følger de regler og frister, der gælder for netop sagen. Den ene port må ikke bruges som bevis for den anden.

Hvordan adskiller en betalingsindsigelsesproces sig fra chargebackhåndtering?

Betalingsindsigelsesprocessen begynder med kortindehaverens spørgsmål og omfatter kortudstederens forklaring, tidlige forespørgsels- eller refusionsveje og beslutningen om at åbne en formel sag. Chargebackhåndtering begynder med en operationel sag og går dybere ned i ejerskab, sagsdatoer, kontakt til forhandleren, indsendelse af svar, statusopfølgning og porteføljetendenser. De to kan forbindes, uden at alle transaktionsspørgsmål behandles som chargebacks.

Hvem skal kommunikere og bogføre resultatet af en betalingsindsigelse?

Kortudstederen eller dennes udpegede indsigelsesteam bør eje kommunikationen med kortindehaveren. Det økonomiske ansvar skal være tydeligt: Kortudstederen bogfører posten på kortindehaverens konto, mens betalingsbehandlerens eller indløserens vej håndterer den tilsvarende regulering hos forhandleren, når det er nødvendigt. Økonomi eller afviklingsdriften afstemmer derefter sags-, konto- og afviklingsreferencer før afslutning.

Hvor denne proces passer ind

I de fleste virksomheder sender denne proces videre til Flowchart for chargebackprocessens deltagerforløb.

Den er ét trin i Tvister og chargebacks.

  1. Trin 1: Flowchart for betalingsindsigelsesproces Du er her

    Skabelon til betalingsindsigelser med transaktionsspørgsmål, tidlig afklaring, formel berettigelse, svar, finansielle reguleringer, afstemning og afslutning.

  2. Trin 2: Flowchart for chargebackprocessens deltagerforløb

    Overordnet skabelon til chargebackprocessen fra kortindehaverens formelle indsigelse gennem kortudsteder, netværk, indløser og forhandlersvar til bogføring og afslutning.

  3. Trin 3: Flowchart for chargebackhåndtering

  4. Trin 4: Flowchart for chargeback-representment

Del af

QueryChart-funktioner til denne proces

Brug denne skabelon

Browse all Betalings-SOP'er, workflows og processkabeloner