Flowchartskabelon til refusionsproces
Flowchart for refusion med berettigelse, beløbsgodkendelse, idempotent indsendelse, statusforespørgsel efter timeout, dubletkontrol, sikker gentagelse og afstemning.
Hvad er flowchartskabelon til refusions?
En refusionsproces skal forbinde en kundevendt beslutning med den efterfølgende betalingshændelse. Skabelonen begynder, når en kunde anmoder om refusion, eller forhandleren tager initiativ til den, og registrerer derefter årsag, ønsket beløb og transaktionsreference før et forsøg på matchning. Når den oprindelige transaktion er fundet, gennemgår forhandlersupport dens status og den aktuelle refusionspolitik. Diagrammet holder politikbaseret berettigelse, behandling af undtagelser og beløbsberegning synlige som særskilte trin, så teamet kan forklare, hvorfor en refusion fortsatte eller ikke fortsatte, og om beløbet svarer til hele transaktionen eller kun de berettigede poster og reguleringer.
Godkendelse er betinget, ikke universel. Et rutinemæssigt beløb kan gå direkte til en registreret beslutning, mens et beløb eller en undtagelse, der kræver en ekstra kontrollant, går til banen Refusionsgodkender. Indsendelsen bruger en stabil refusionsreference og har tre særskilte resultater: accepteret, endeligt fejlet eller timeout og ukendt. Et ukendt resultat behandles aldrig som en fejl. Driften henter status med de oprindelige refusions- og transaktionsreferencer for at afgøre, om refusionen afventer, er gennemført, ikke findes, er fejlet eller stadig er uafklaret.
En refusionsanmodning, der er endeligt fejlet eller bekræftet som ikke-eksisterende, kan rettes, men den må ikke indsendes igen, før dubletkontrollen dokumenterer, at ingen refusion findes, og at en kontrolleret gentagelse er sikker. Accepterede og afventende refusioner går til kommunikation og opfølgning på afvikling; forsinkede resultater går tilbage til statusforespørgslen frem for indsendelsen. Gennemførte refusioner afstemmes med afvikling og finansbog, mens en uløst status sættes i bero til specialistvurdering uden endnu en gentagelse. Udbyderstatusser, idempotensadfærd og behandlingstid varierer, så den konfigurerede API-kontrakt og hændelsesprocedure skal levere den faktiske dokumentation og kontrollerne.
Hvad dette flowchart dækker
I denne skabelon
- Kundens anmodning eller forhandlerens initiativ, registrering af transaktionsreference, opslag og rettelse af oplysninger, der ikke matcher
- Vurdering af berettigelse efter politikken, håndtering af undtagelser og en tydelig vej for sager, der forbliver uløste
- Beregning af fuldt eller delvist beløb, betinget godkendelse og en varig registrering af beslutningsgrundlaget
- Indsendelsesstatusserne accepteret, endeligt fejlet og timeout eller ukendt med statusforespørgsel ud fra de oprindelige referencer
- Dubletforebyggelse før kontrolleret gentagelse efterfulgt af opfølgning på afvikling, afstemning eller vurdering af uløst status
Hvornår du skal bruge skabelonen
- Kundeservice, betalingsdrift og økonomi bruger forskellige definitioner på, hvornår en refusion er gennemført
- Teams skal skelne mellem godkendelse efter politikken, vellykket indsendelse og senere afvikling
- Delvise refusioner eller undtagelser beregnes uensartet eller når godkendere uden tilstrækkelig kontekst
- Fejlede, forsinkede eller ukendte refusioner gentages, før deres oprindelige status og dubletrisiko er afklaret
- En forhandler definerer ejerskab for refusioner under onboarding af en betalingskunde eller en API-implementering
Sådan fungerer det
Erstat politikporten med jeres regler
Definér de transaktionsstatusser, produkter, tidsfrister og den dokumentation, der påvirker berettigelsen i jeres forretning. Hold undtagelser adskilt fra den rutinemæssige vurdering, navngiv den der må vurdere dem, og undgå at fremstille en udbyderspecifik regel, som om den gælder for alle betalingsveje.
Definér fulde og delvise beregninger
Dokumentér, hvilke poster og reguleringer der kan refunderes, og hvordan tidligere krediteringer eller refusioner påvirker restbeløbet. Brug samme beregningsregistrering i support, godkendelse og økonomi, så værdien ikke genfortolkes ved hver overlevering.
Fastlæg ejerskab for betinget godkendelse
Angiv, hvilke beløb eller typer af undtagelser der kræver en ekstra godkendelse, og hvilken rolle der kan give den. Hvis rutinemæssige refusioner ikke kræver godkendelse, beholdes den direkte gren og politikgrundlaget registreres, frem for at hver sag får en symbolsk gennemgang.
Kortlæg afklaringen af indsendelsesstatus
Kortlæg udbyderstatusserne accepteret, endeligt fejlet, gennemført, afventende og ukendt. Definér, hvordan driften henter status med de oprindelige refusions- og transaktionsreferencer, og omsæt aldrig en timeout til en fejlet indsendelse eller en ny anmodning.
Beskyt enhver gentagelse
Kræv før genindsendelse dokumentation for, at den oprindelige refusion ikke findes eller er endeligt fejlet, gennemfør dubletkontrollen, og bekræft, at gentagelsen er idempotent og kontrolleret. Test accepterede, gennemførte, afventende og fortsat ukendte resultater gennem afstemning eller specialistvurdering.
Ofte stillede spørgsmål
Hvad er hovedtrinnene i en refusionsproces?
Registrér og match den oprindelige transaktion, vurder berettigelsen, beregn beløbet, indhent en eventuel nødvendig godkendelse, og tildel en stabil refusionsreference. Indsend én gang, og skeln mellem accepteret, endeligt fejlet og timeout eller ukendt status. Forespørg på ukendt eller forsinket status med de oprindelige refusions- og transaktionsreferencer. Gentag kun efter bekræftet fravær, dubletforebyggelse og dokumentation for, at den kontrollerede gentagelse er sikker. Følg accepterede refusioner til afvikling, og afstem gennemførelsen.
Er en accepteret refusion det samme som en afviklet refusion?
Ikke nødvendigvis. Accept betyder normalt, at den indsendte anmodning passerede næste system- eller udbyderport, mens afvikling eller gennemførelse senere bekræftes ud fra de relevante betalings- og finansdata. De præcise statusser og tidspunkter afhænger af den anvendte vej. Når punkterne holdes adskilt, bliver en kundevendt bekræftelse ikke fejlagtigt behandlet som dokumentation for, at økonomi har afstemt resultatet.
Hvornår bør en refusion kræve godkendelse?
Brug den bemyndigelsesmodel og politik, der gælder for forhandleren. Godkendelse kan være relevant for bestemte beløb, undtagelser eller risikoforhold, men bør ikke vises som en universel betalingsregel. Diagrammet har derfor både en direkte vej og en godkendelsesvej. Definér grænsen, godkenderen, dokumentationen og en stedfortræder under onboarding af betalingskunden eller udformningen af proceduren.
Hvad skal der ske efter timeout ved indsendelse af en refusion?
Behandl refusionen som ukendt, bevar de oprindelige refusions- og transaktionsreferencer, og brug den understøttede statusforespørgsel før enhver gentagelse. Hvis udbyderen bekræfter accept eller gennemførelse, fortsættes opfølgning eller afstemning. Hvis udbyderen bekræfter fejl eller fravær, rettes anmodningen, og dublet- og idempotenskontroller gennemføres før en kontrolleret gentagelse. Hvis status forbliver ukendt, sættes genindsendelse i bero, og sagen sendes til undersøgelse.
Hvor denne proces passer ind
I de fleste virksomheder sender denne proces videre til Flowchart for betalingsafstemning fra data til afvikling.
Kommer efter
- Flowchart for betalingsafstemning fra data til afvikling — Skabelon til betalingsafstemning med fuldstændige kilder, transaktions- og afviklingsmatch, klassifikation af forskelle, kontrollerede rettelser og revisionsspor.