Hvis du selger i EU, er reglene som styrer ansvar for svindel, refusjoner og autentisering i kassen i ferd med å slutte å variere fra land til land. Det kan virke som en liten teknisk endring. For en selger som kjører samme kasseløsning i flere medlemsstater, er det tvert om — det er slutten på å måtte forholde seg til separate forutsetninger for hvordan en tysk bank behandler en omtvistet transaksjon versus hvordan en fransk eller polsk bank gjør det.
Den 23. april 2026 publiserte Europaparlamentet og Rådet de avtalte tekstene for den nye betalingspakken: det tredje betalingstjenestedirektivet (PSD3) og, sammen med det, en ny betalingstjenesteforordning (PSR). Publisering i EU-tidende (Official Journal) forventes i juni eller juli 2026, og de fleste forpliktelsene gjelder generelt 21 måneder etter denne publiseringsdatoen — noe som legger den generelle anvendelsesdatoen til rundt mars eller april 2028, avhengig av den eksakte publiseringsdatoen. Noen bestemmelser, inkludert deler av rammeverket for åpne bank-API-er, kan gjelde etter en annen tidsplan — tidligere eller senere — enn den generelle datoen; sjekk den endelige teksten når den publiseres, i stedet for å anta at én dato gjelder for alt.
Dette er ikke et juridisk sammendrag. Det er en gjennomgang av det en selger faktisk må ta tak i: PSP-avtalen som ligger i din juridiske mappe, betalingsløsningen kundene dine ser, og tvisteprosessen support- og økonomiteamet ditt kjører når en chargeback dukker opp.
1. Hvorfor en forordning i stedet for et direktiv endrer risikoeksponeringen din
Under PSD2 ble de daglige atferdsreglene — tidspunkt for refusjon, ansvar for svindel, klagebehandling — fastsatt av et direktiv. Direktiver gjelder ikke direkte. Hver av de 27 medlemsstatene måtte innarbeide PSD2 i sin egen nasjonale lovgivning, og hver gjorde det med sin egen tidsplan, sine egne mangler og sin egen lokale tolkning. En selger som drev virksomhet i fem EU-land, opererte i praksis under fem litt forskjellige regelbøker, selv om alle hevdet å implementere «det samme» direktivet.
Den nye pakken deler opp arbeidet annerledes. PSD3 forblir et direktiv og dekker hovedsakelig lisensiering, tilsyn og markedsadgang for betalingsinstitusjoner — den typen som påvirker PSP-ens regulatoriske status, ikke kassen din. Atferdsreglene som faktisk berører selgere — ansvar for svindel, refusjonsforpliktelser, krav til autentisering, klagebehandling — flyttes inn i PSR, en forordning. Forordninger gjelder direkte og likt i hver medlemsstat, uten noe nasjonalt innarbeidingssteg og uten rom for lokale utformingsavvik.
Ifølge juridiske analyser av de avtalte tekstene er dette et bevisst svar på fragmenteringsproblemet PSD2 skapte — PSR er designet for å gi selgere og PSP-er én enhetlig regelbok i stedet for 27 lokale varianter (Freshfields' oversikt over de avtalte tekstene). For selgere betyr dette at etterlevelsesgjennomgangen du kjører for din tyske enhet, når PSR trer i kraft, bør gi samme svar som gjennomgangen for din irske eller portugisiske enhet. Det er en reell forenkling, men det betyr også at det ikke lenger finnes noe «den lokale tilsynsmyndigheten er lempelig på dette»-argument å falle tilbake på.
2. Hva som endres i ansvaret for svindel
PSD2s ansvarsregler var bygget rundt en ganske smal idé om en «uautorisert» transaksjon — en kunden ikke godkjente. Svindel har utviklet seg siden da. Sosial manipulasjon (social engineering), der en svindler utgir seg for en bankansatt eller overtaler en kunde til å autorisere en overføring direkte, produserer teknisk sett en «autorisert» transaksjon under det gamle rammeverket, noe som historisk har gitt kunden (og dermed selgeren som er avhengig av den betalingen) mindre å hente seg inn på.
PSR utvider ansvaret i flere retninger som er relevante for selgere:
- Spoofing-basert svindel — der en svindler utgir seg for en PSP-ens ansatte eller merkevare — flytter mer ansvar over på betalingstjenesteleverandørene, i stedet for å la kunden bære tapet.
- Svikt i å tilby eller korrekt anvende sterk kundeautentisering (SCA) legger ansvaret på hvilken part i kjeden som svikter i å anvende den korrekt, noe som inkluderer acquirere og, i noen flyter, selgere som omgår autentisering.
- Treg behandling av svindelrapportering hos en PSP kan i seg selv skape ansvar, noe som er ment å presse banker og PSP-er mot raskere behandlingstid for svindelrapporter, i stedet for å behandle hver klage som en langvarig undersøkelse.
For en selger er den praktiske effekten at svindeltvister i økende grad vil avgjøres av bevis på hva som skjedde under autentiseringen, ikke bare på om kunden hevder de ikke autoriserte betalingen. Det gjør autentiseringsloggene og SCA-utfallsdataene dine til en del av bevisgrunnlaget i tvister, ikke bare en etterlevelsesregistrering du oppbevarer og glemmer.

4. Krav til API-ytelse
PSD2 gav kontoførende banker to alternativer for å eksponere kontodata til tredjeparter: et dedikert API, eller et reservegrensesnitt bygget på deres eksisterende kundevendte nettbankskjermer. I praksis var reservegrensesnittene ofte tregere, mindre stabile og inkonsistent vedlikeholdt, noe som gjorde kasseløsninger basert på åpen bank — pay-by-bank-alternativer, kontoinformasjon for risikoscoring og lignende funksjoner — mindre pålitelige enn kortbetalinger.
Det nye rammeverket strammer inn på dette. Banker vil stå overfor klarere, mer håndhevbare forpliktelser rundt ytelsen til det dedikerte grensesnittet — nærmere en likestilling med påliteligheten til sine egne kundevendte kanaler, med definerte forventninger til oppetid og responstider, i stedet for den løst håndhevede «rimelig innsats»-standarden som kjennetegnet deler av PSD2-implementeringen (MoFos analyse av PSD3/PSR-utviklingen).
For selgere som tilbyr eller vurderer pay-by-bank eller andre konto-til-konto-alternativer i kassen, er dette relevant på to måter:
- Færre mislykkede eller tidsavbrutte autoriseringsforsøk bør bety færre forlatte handlekurver på overføringsbaserte betalingsmetoder, som historisk har underprestert kort på gjennomføringsgrad, delvis på grunn av grensesnittstabilitet.
- Hvis du er avhengig av kontoinformasjonstjenester for risikobeslutninger — å verifisere kontoeierskap eller sjekke saldo før forsendelse av høyverdibestillinger — bør disse datastrømmene bli mer konsistente å bygge arbeidsflyter rundt, i stedet for noe du må bygge forsøk-på-nytt-logikk og reservehåndtering for.
Ingenting av dette fjerner behovet for å teste integrasjonen din mot faktisk bankoppførsel når reglene trer i kraft. Det betyr at grunnlinjen for pålitelighet du tester mot, bør bli bedre.

5. Hva som faktisk må endres: avtaler, kasseløsning, tvisteprosess
Dette er den delen som ofte forbigås i de fleste juridiske sammendrag. Her er hva som endres på din side av bordet.
PSP- og acquirer-avtalene dine. Gå gjennom ansvarsfordelingsklausulene i dine eksisterende avtaler om betalingstjenester. Under avtaler fra PSD2-tiden forutsatte ansvarsformuleringene ofte den gamle, smalere definisjonen av «uautorisert transaksjon» og de gamle unntaksreglene for SCA. Når PSRs ansvarsbestemmelser trer i kraft, kan avtaler som ikke er oppdatert, referere til standarder som ikke lenger stemmer med loven, noe som skaper uklarhet nøyaktig når du trenger klarhet — midt i en tvist. Spør PSP-en din direkte om deres standard selgervilkår vil bli oppdatert for å reflektere PSRs ansvarsfordeling, og få svaret skriftlig i stedet for å anta at det er ordnet.
- Kasseløsningen din. Tre konkrete endringer å kontrollere:
- Bekreft at det juridiske navnet knyttet til oppgjørskontoen din stemmer med butikkens merkevarenavn, for å unngå unødvendige VoP-avviksvarsler på overføringsbaserte betalingsmetoder.
- Sørg for at SCA-utfordringsflyten din (3DS eller likeverdig) degraderer gradvis — en kunde som forlater et kjøp fordi et autentiseringssteg feilet teknisk, i stedet for at de avviste det, er nøyaktig det scenariet de nye ansvarsreglene er designet for å fange opp, og du vil ikke stå på feil side av det når en tvist blir vurdert.
- Hvis du tilbyr pay-by-bank eller andre konto-til-konto-alternativer, planlegg å teste gjennomføringsgrad på nytt når de nye kravene til API-ytelse trer i kraft — påstandene om pålitelighet du bygde reservelogikken din rundt, er kanskje ikke lenger den begrensende faktoren.
- Tvisteprosessen din. Bevisene som avgjør en svindel- eller chargeback-tvist er i endring. Der tvister fra PSD2-tiden ofte handlet om hvorvidt SCA ble anvendt i det hele tatt, vil tvister fra PSR-tiden oftere handle om hvordan den ble anvendt, om en VoP-kontroll ble kjørt og hvilket resultat den gav, og hvor raskt en svindelrapport ble eskalert. Det betyr:
- Supportteamet ditt trenger tilgang til logger for autentiseringsutfall, ikke bare transaksjonsstatus, når de svarer på en tvist.
- Dokumentasjonen for bevisinnsending bør oppdateres til å inkludere VoP-match/ingen-match-resultater som et standardfelt, når disse dataene finnes i transaksjonsregistrene dine.
- Interne SLA-er for å eskalere mistenkte svindelrapporter til PSP-en din bør strammes inn, siden forsinkelse i seg selv blir en ansvarsfaktor snarere enn et nøytralt administrativt steg.
Skiftet fra PSD2 til PSR handler mindre om at nye forpliktelser dukker opp ut av det blå, og mer om at eksisterende smutthull tettes.
Selgere som har behandlet ansvar for svindel, SCA og tvistebevis som «det den lokale banken sier», vil oppleve at det svaret ikke lenger holder når den samme forordningsteksten gjelder i hver medlemsstat. Arbeidet er administrativt — oppdatering av avtaler, kassetekst og bevismaler — men det må skje før generell anvendelse trer i kraft, ikke etter at den første tvisten under de nye reglene avslører hullet.
Ingenting av dette krever at du bygger om kasseløsningen fra grunnen. Det krever at du behandler PSP-avtalen din, dine registrerte kontodetaljer og bevismalene for tvister som levende dokumenter som trenger en gjennomgang etter en bestemt tidsplan — som er hele poenget med sjekklisten under.
6. Datert sjekkliste for beredskap
Den eksakte datoen for generell anvendelse avhenger av når den endelige teksten publiseres i EU-tidende, men sekvensen er fastlagt. Bruk dette som en arbeidstidsplan snarere enn en fast frist, og bekreft datoer når publiseringen i EU-tidende er bekreftet.
- Innen fjerde kvartal 2026 — Publisering i EU-tidende forventes (juni–juli 2026). Når den er publisert, beregn din faste 21-måneders dato for generell anvendelse og legg den inn i etterlevelseskalenderen din. Start gjennomgangen av PSP-avtalen nå, i stedet for å vente til fristen.
- Gjennom 2027 — Bekreft PSP-ens plan for å oppdatere selgervilkårene for å reflektere PSRs ansvarsfordeling. Kontroller det registrerte juridiske navnet på oppgjørskontoen din mot merkevarenavnet i kassen. Kartlegg hvilke av kasseløsningene dine som bruker SCA og dokumenter nåværende unntakslogikk, så du kan sammenligne den mot de endelige PSR-kravene.
- Tidlig 2028 — Test tvistebevisprosessen din fra start til slutt: kan supportteamet ditt faktisk hente ut SCA-utfall og VoP-matchdata for en transaksjon på forespørsel, eller krever det en teknisk henvendelse til utviklingsavdelingen? Rett opp dette gapet før det blir testet av en reell tvist.
- Ved generell anvendelse (anslått mars–april 2028) — Bekreft at oppdaterte PSP-avtaler er signert, at kassetekst reflekterer eventuelle krav til mottakernavn, og at tvistedokumentasjonen inkluderer de nye bevisfeltene. Behandle datoen for generell anvendelse som punktet der alt det ovennevnte allerede bør være i drift, ikke punktet der du starter.
Cost+ opererer med IC++ (Interchange Plus Plus)-prising nettopp fordi vi tror selgere tar bedre beslutninger når komponentene i en betaling — interchange, scheme fee og vår markup — er synlige i stedet for bundlet sammen. Samme prinsipp gjelder for regulatoriske endringer: jo tidligere du kan se hva som faktisk endrer seg i krav til ansvar og bevis, desto mindre forstyrrende blir overgangen. Hvis du vil diskutere hvordan din nåværende kasse- og tvisteoppsett stemmer med PSR-tidsplanen, ta kontakt med teamet vårt eller sjekk din nåværende gebyrstruktur mot den publiserte lav-risiko-prisingen på siden vår mens du gjennomgår avtaler.


