Case study: Når betalingerne afvises

Jeg har også fundet det i en præsentation fra NETS om fremtidig mulig udvikling af Dankort.

Så lærte jeg noget nyt, tak for det. Det lyder umiddelbart som en rigtig god idé.

Nej, de får det nye kortnummer, uanset om det skifter PAN og måned/år opdateres også. Banken skal også understøtte det. Pt. gør Nordea og nogle af bankerne, der deler central - mener det er Bankdata. De har de samme kortvilkår, så man skal søge efter en specifik formulering, og så kan man hurtigt finde de banker, der understøtter det. Stort set alle amerikanske banker har understøttet det i årevis, men herhjemme er vi lidt mere sløve. Jeg har også fundet det i en præsentation fra NETS om fremtidig mulig udvikling af Dankort.

https://www.nordea.dk/privat/produkter/kort/automatisk-opdatering-af-kortoplysninger.html

Vi har dog opdaget, at Stripe automatisk modtager opdaterede kortoplysninger direkte fra visse kortudstedere, når kundens kort udløber, og de får et nyt. Det er ret genialt, og det gamle mandat udløber ikke, så kunden mærker intet ift. selv at skulle huske på at opdatere sine kortoplysninger. Det sker helt automatisk.

Er du sikker på, det ikke blot er fordi visse kortudstedere genbruger kortnummeret ved fornyelse - og Stripe ikke checker udløbsdato ved gentagne hævninger?

Det var bl.a. noget, vi så, da vi anvendte islandske Valitor som indløser - her var der tilsyneladende ikke check af udløbsdato, og vi kunne derfor hæve penge på visse udløbne kort, fordi kortholderens bank havde udstedet et nyt kort med samme nummer.

Jeg har på nuværende tidspunkt kun positive ting at sige om Clearhaus og OnPay, som vi bruger som hhv. indløser og betalingsgateway. Begge parter virker servicemindede og løsningsorienterede, modsat Nets, som jeg kun har dårlige erfaringer med.

Jeg kan ikke udtale mig om OnPay, men ellers helt enig. Desværre kommer man ikke rigtigt uden om NETS. Vi prøvede i en årrække at køre uden Dankort, men det var ikke rigtigt holdbart.

Vi bruger primært Quickpay, men kører stadig med en mindre andel kunder via Stripe. Vi har dog opdaget, at Stripe automatisk modtager opdaterede kortoplysninger direkte fra visse kortudstedere, når kundens kort udløber, og de får et nyt. Det er ret genialt, og det gamle mandat udløber ikke, så kunden mærker intet ift. selv at skulle huske på at opdatere sine kortoplysninger. Det sker helt automatisk.

FirstCard har konsekvent indrulleret 3D Secure forkert på tværs af deres mange kunder. Jeg har personligt haft fat i FirstCard, og det kommer virkelig an på, hvem man får fat i, om de overhovedet gider tjekke. Det er længe siden, at vi har været i kontakt med en kunde med et FirstCard, så problemet er måske løst nu?

Ah ja, det problem løb vi også ind i.

Clearhaus var i dialog med Nordea, og det endte med at problemet blev løst omkring den 20. april i år.

Jeg har på nuværende tidspunkt kun positive ting at sige om Clearhaus og OnPay, som vi bruger som hhv. indløser og betalingsgateway. Begge parter virker servicemindede og løsningsorienterede, modsat Nets, som jeg kun har dårlige erfaringer med.

Hej Yoel, Vi oplever selv samme problemer med Quickpay/Clearhaus her et par år efter. Fandt I nogensinde en løsning eller et workaround?

Vi fik indsnævret problemet til ca. 100 stk. MasterCard, og det viste sig, at alle disse kort blev clearet af BEC, som afviste vores transaktioner, uanset om vi brugte Clearhaus eller Nets som indløser på de pågældende kort.

Vi tog derfor fat i BEC, men det var naturligvis spild af tid: Vi fik at vide, at betalingerne blev afvist jf. BEC's aftale med kundernes banker, og at kunderne selv måtte tage fat i deres bank. Og de pågældende banker kunne naturligvis ikke sige noget som helst om, hvorfor betalingerne blev afvist.

Efter en trussel om anmeldelse til Finanstilsynet til BEC, blev problemet dog umiddelbart løst - vi fik ikke nogen konkret tilbagemelding fra BEC, så jeg ved ikke, hvad der var galt.

Det er jo en ret gammel artikel, men vi ser kun meget sjældent fejl efterhånden. Fejlen ligger efter vores erfaring ofte et sted ved banken, og de løser det generelt rimeligt hurtigt uden brugerinvolvering. Pludseligt en dag virker det bare.

Ifm. indførslen af obligatorisk 3D Secure får vi konsekvent fejl ("Additional authentication required") med Mastercards fra Nordea af typen 'FirstCard', som de har outsourcet til et andet firma.

FirstCard har konsekvent indrulleret 3D Secure forkert på tværs af deres mange kunder. Jeg har personligt haft fat i FirstCard, og det kommer virkelig an på, hvem man får fat i, om de overhovedet gider tjekke. Det er længe siden, at vi har været i kontakt med en kunde med et FirstCard, så problemet er måske løst nu?

Helt generelt kan man sige, at hvis kunden får fejl ved tilmelding af betalingskortet til SMS-løsningen på Nets hjemmeside, så ligger fejlen ved banken eller Nets, og betalinger vil derfor afvises, når det er over ca. 225 kr., eller hvis der er tale om en abonnementsbetaling:

https://enroll.3dsecure.no/nets-nemid-enroller/EnrollSite

Det er lykkedes at komme en smule nærmere problemets årsag i samarbejde med Clearhaus.

Løsningen er ikke at regulere Nets, men at fjerne deres monopol.

Måske man i højere grad skulle kigge på organisationskulturer fremfor bonusordninger til cheflagene for vindinger på den korte bane.

Tak fordi I deler jeres historie hos QuickPay.

Der er mange, der har holdninger til den måde, Nets driver forretning på, herunder også de store bonusprogrammer til ledelsen, især personificeret ved topchefen med det geniale pressefoto.

Personligt er jeg af den holdning, at Nets må gøre hvad de vil, så længe deres kunder har friheden til at stemme med fødderne, hvis de er utilfredse.

Som jeg ser det, er det primære problem med Nets, at det er en traditionel monopolvirksomhed, som efter der er kommet (lidt) konkurrence på betalingsmarkedet har slået sine kløer i nye monopolforretninger - herunder NemID/MitID.

Løsningen er ikke at regulere Nets, men at fjerne deres monopol. Der er ingen grund til, at en enkelt finansiel virksomhed skal have eneret på at udbyde Dankort, NemID eller noget som helst andet i den stil.

Det er lykkedes at komme en smule nærmere problemets årsag i samarbejde med Clearhaus.

Det ser ud som om, vi har to cases: Afviste Visa-kort, som virker igen, når de tilmeldes, og afviste MasterCard, der godt kan tilmeldes igen, men hvor der ikke kan hæves det normale beløb.

Når visse Visa-kort bliver afvist, men virker igen, når de tilmeldes, skyldes det sandsynligvis en nidkær implementation af SCA (strong customer authentication). Kundens bank konstaterer, at der er tale om en recurring transaction, hvor den første transaction ikke er kørt igennem den samme indløser, og afviser den derfor.

Hvis tesen er rigtig, og bankens forståelse af betalingsdirektivet i øvrigt er korrekt, må jeg konkludere, at SCA sker på bekostning af konkurrencen på betalingsmarkedet: Det vil være ualmindelig svært for en netbutik med abonnementsbetalinger at skifte indløser, hvis man samtidig skal sige farvel til et par procent af kunderne, fordi man er nødt til at have dem til at tilmelde deres betalingskort igen.

I forhold til MasterCard, der bliver afvist efter gen-tilmelding, ser det foreløbig ud som om, der muligvis er en fraud-algoritme hos kortholders bank, der aktiveres på de specifikke kort.

Det kræver en forklaring: En betaling består som bekendt af en authorization og en capture. Tanken er, at når en kunde bestiller en vare i en netbutik, reserveres beløbet på kundens kort (authorization), og når netbutikken sender varen, hæves beløbet på kortet (capture).

Når en kunde tilmelder sit betalingskort til Mit Kviknet, opretter vi et abonnement på kortet hos vores betalingsgateway OnPay.

Det sker i praksis ved, at OnPay gennemfører en authorization på 1 krone, der umiddelbart efter annulleres (void). Herved oprettes en transaktion, vi kan referere til, når vi skal trække penge fra kortet, hvilket vi så gør med en ny authorization + capture.

Ved de fejlede MasterCard har vi en spøjs situation: Når kortet er gen-tilmeldt, kan vi oprette en authorization på både 1, 2 og 10 kr. En authorization på 249 kr. (typisk abonnementspris) afvises derimod af banken - og da vi ikke kan se, hvad der foregår i bankens systemer, må vi antage, at bankens algoritme kommer frem til, at der er for stor afvigelse mellem den første abonnementstilmelding på 1 krone og en efterfølgende hævning på 249 kr.

Skal en abonnementstilmelding have samme beløb som efterfølgende hævninger?

Det er der efter sigende nogen, der mener, men det holder ikke i virkeligheden. Der vil være forskel på, hvilke ydelser, abonnementsbetalingen dækker, og desuden er der nogle få banker, der konsekvent viser abonnementstilmeldingen som et trukket beløb på den enkelte kundes konto, selv om der er tale om en authorization uden efterfølgende capture. Derfor har vi valgt 1 krone, da det sjældent vælter læsset for nogen, mens en ekstra trækning på fx 249 kr. for manges vedkommende vil være et problem.

Mine betalinger til Kviknet blev også afvist pludselig ved sidste betaling, og blev afvist et par gange inden jeg reagerede. Kviknet support var dog hurtig til at anbefale jeg sletter og tilføjer kortet igen, og så trak pengene normalt.

Jeg er dog kunde hos Lunar/Nykredit Bank, og ikke de ovenstående banker.

QuickPay har efterflg. modtaget en undskyldning fra Nets omkring håndteringen af problemerne ved Secure by Nets. Og sågar på skrift. Det er første gang i QuickPays 15-årige historie noget sådant sker.

Når vi er kommet os over frustrationerne ved at forsøge at slå døre ind hos supertankeren med masser af legacy-systemer og høj kompleksitet, kan vi også tolke det som om der begynder at blæse ny vinde om imødekommenhed og erkendelser.

Men men - der er langt igen.

Måske man i højere grad skulle kigge på organisationskulturer fremfor bonusordninger til cheflagene for vindinger på den korte bane.

Så selv for betalingsgateways er det altså småt med kvalificeret information fra NETS om problemårsager. Se den udmærkede forklaring fra Quickpay her <a href="https://status.quickpay.net/incident/327">https://status.quickpay.net/i…; om hvordan de måtte bypasse NETS for at få afklaring omkring problemet.

Men det er da klart, at sådan et firma ud over at have snablen nede i vores bankkonti også skal drive en SSO-service for os alle sammen.

Lad mig forsøge at afklare problemstillingen lidt.
Det hele "skyldes" formodentligt EU 2018/389 populært kaldet SCA. Denne delegerede forordning trådte i kraft 14 september. Den gælder kun i EEa (EU plus nogle lande).

Du har muligvis ret i, at der kan være en sammenhæng med SCA.

Men i og med det kun er en meget lille del af vores kunder, der er ramt, taler sandsynligheden for en teknisk fejl - Jyske Bank (og Nordea, hvis de er omfattet) må alt andet lige formodes at være bank for rigtig mange af vores kunder, langt flere end de ca. 80 kunder, der er ramt.

Der har for nylig været et problem med en teknisk ændring hos en underleverandør til NETS, der bevirkede at Quickpay ikke kunne håndtere "Secured by Nets" (altså SCA) på Dankort i ca. 2 døgn. Så selv for betalingsgateways er det altså småt med kvalificeret information fra NETS om problemårsager. Se den udmærkede forklaring fra Quickpay her https://status.quickpay.net/incident/327 om hvordan de måtte bypasse NETS for at få afklaring omkring problemet.

Lad mig forsøge at afklare problemstillingen lidt. Det hele "skyldes" formodentligt EU 2018/389 populært kaldet SCA. Denne delegerede forordning trådte i kraft 14 september. Den gælder kun i EEa (EU plus nogle lande). En af de ting den påbyder er et krav om "stærk kundeautentifikation" (SCA). Det betyder at en masse af det man før godt måtte/kunne, ikke længere er tilladt/afvises. Da det har været uklart hvordan det skulle fortolkes for e-handel har der været ønsker om udskydelse af datoen. Derfor har finanstilsynet i Danmark udskudt ikrafttræden for e-handel. For at gøre forvirringen lidt større så har forskellige lande i EU udsat dele af PSD2 i forskellig grad.

For at en transaktion skal behandles som e-handel kræver det dog at transaktionen fra forretningen side er sat rigtigt op. Det er så noget forretningen / forretningens bank skal sørge for.

Hvis transaktionen afvises vil det være kundens bank der afviser. Her kan forskellige banker være forskelligt langt med indførelsen af SCA.

Herudover er der så en "elastik" i Artikel 18. " ...betalingstjenesteudbydere har mulighed for at undlade at anvende stærk kundeautentifikation, hvis betaleren initierer en elektronisk fjernbetalingstransaktion, som betalingstjenesteudbyderen anser for at indebære en lav risiko i henhold til de transaktionsovervågningsmekanismer..." suk (læs selv den fulde tekst).

Det er ærligt at man ikke kan få et par tusind kunder til at sagsøge nets for et eller andet.

Jeg som udlandsdansker har altid på et eller andet tidspunkt hvor jeg besøger Danmark, et problem. Mit alm. debit Mastrocard bliver afvist og jeg bliver så nød til at bruge mit Mastercard (eller Visa) til at betale, hvilket er betydelig dyre.

Det eneste der er tilfælles er at det er Nets ... det virker nogle gange, men ikke altid, og det er ikke genialt.

Jeg har prøvet at spørge Nets om hvorfor der er et problem, vi alle kender til hvor meget man få ud af det, og min egen bank ser ikke engang at der er indgået en forspørgsel på betaling.

Skumle....

...Så længe bare man ikke modtager pengene fra LuNAR, går alt let.

Deres ledelse er fuldstændig skruppelløse, ja vanvittige, hensynsløse kyniske mennesker.

Der direkte hul igennem til Putin via. dem (ikke at amerikanerne er meget bedre)

Deres umenneskelige metoder til at tjene penge vil med garanti føre til en større skandale end hvad vi har set i klassiske banker (Og det ikke småpenge!)

Pas på jeres børn og hold jer væk fra Lunar

En enkelt kundes account manager hos Jyske Bank oplyste os, at der var tale om et problem med dataudveksling mellem Nets og Visa, og at der blev arbejdet på højtryk på at løse problemet.

For et godt stykke tid siden fik jeg også afvist to faste betalinger af Jyske Bank. Den ene HostEurope, en tysk hostingleverandør, der heldig vis var flinke og ingen drift blev forstyrret. Den anden var Musikhaus Thomann (også tysk) som blot ventede med at sende mine varer. Jeg havde allerede dengang et mangeårigt kundeforhold med begge. Der var intet nyt i at jeg brugte mit kort dér og rigeligt med penge på kontoen.

Efter en del arbejde kunne min bankrådgiver give præcis samme besked som i citatet.

Det er virkeligt frustrerende at stå og ikke kunne betale noget og det skulle tage mange dage at få en forklaring.

Hosting betaler jeg nu via PayPal. Selvom jeg er dybt uenig i meget af det de gør, så gik betalingen igennem.

De her betalingssystemer er nogle kollodser, der har et utal af integrationspunkter og skal tage hensyn til årtier af bagudkompatibilitet og finurligheder. Det er ikke nemt at lave. Men når man samtidig er afhængig af at det virker og de bare viser én finger nr. 3 er det meget frustrerende.

I vores virksomhed benytter vi PAYMILL til de udenlandske forhandlere, der hellere vil betale med kreditkort end med en SWIFT-bankoverførsel.

Ind imellem afvises betalinger fra forhandlere på det amerikanske kontinent med en "Declined by issuer or card scheme"-lignende fejlkode, og det skyldes som regel, at kreditkortholderens banks systemer til forhindring af kreditkortsvindel afviser betalingen. Løsningen er her, at kreditkortholderen kontakter sin bank om problemet med transaktionen og beder banken åbne kreditkortet for betalingerne til os.

mvh Morten Brørup CTO, SmartShare Systems

• at de rigtige kunder, kortindehaveren, er taber og risikerer lukkede tjenester, rykkergebyrer, og alt muligt lignende.

Løsningen må være, at meddele kunderne at det IKKE har været miligt at løse problemet på grund af pbstruktion i banksystemerne OG opfordre dem til at klage til xxxxxx. Mon xxxxx er Pengeinstituternes Ankenævn eller hvad mon ?

Det må være en konfrontation mellem den sagesløse kunde og deres bank. Ifølge almindelig dansk ret er der TO parter i en aftale, nemlig disse. Og tredieparter, i dor, af Nets osv. er ubefkommende. Prøv lige den.

Hvis det er en god, solid, kunde, som er kendt, så giv ham kredit indtil sagen løses.

Den blev afvist i begge tilfælde med fejlen "Declined" i vores gatewaylog. Til sidst blev han så frustreret (desværre), at han sendte et billede af kortet. Betalingen gik igennem med det samme, da jeg tastede det gennem backend.

Her tænker man jo lidt, at der nok er en form for algoritme, som måske har detekteret nogle ting hos kunden, som får dem til at tro, der er tale om fraud.

Fx hvis kunden tilfældigvis deler IP-adresse med en Tor exit node, en inficeret PC, der er del af et botnet eller lignende, som har forsøgt at køre mange falske betalinger igennem.

Men hvor ville det dog være nemmere, hvis man kunne få den rigtige forklaring fra indløseren. Gad vide, hvor mange menneskers tid, der bliver spildt rundt omkring, fordi man mener det højner sikkerheden at stange en generisk, intetsigende fejlkode ud.

Jeg tænker, at det må ligge i koblingen mellem de tokens, som indløseren får fra udstederen, og så koblingen til de rigtige PANs i en eller anden database. Det skulle ikke undre mig, om det er NETS som administrerer tokenization af BIN/PAN numrene i Danmark for visse banker, og at fejlen ligger i en database ved dem.

Det lyder plausibelt, at der er en databasefejl hos Nets - men hvordan får man dem til at løse problemet?

I bund og grund er det jo vores kunde, som skal klage til sin bank, som så skal tale med store bogstaver over for Nets, men gæt selv, hvem der bliver taberen i det spil.

Skal man have fat i Finanstilsynet - eller har Nets en "NOC", man kan tage fat i?

Det lugter jo, om ikke af direkte chikane, så i hvert fald af grov negligering af problemer, som tilfældigvis rammer konkurrenterne. Nogle ville kalde det markedsforvridende adfærd.

Vi kører med QuickPay på min arbejdsplads.

Vi havde på et tidspunkt, at der var nogle MC-Debitkort fra Danske Bank, der blev afvist, selvom kunderne skrev ind (og i flere tilfælde vedhæftede screenshots), at der altså VAR penge på kontoen.

Jeg sad også med en her den anden dag, som var rigtig mystisk (Nordea, Visa-Debit). Vi har vores hovedkortindløser (QuickPay) og en backup (Stripe). Vi prøvede at køre betalingen igennem begge kortindløsere, og hver gang indtastede kunden kortoplysningerne påny. Den blev afvist i begge tilfælde med fejlen "Declined" i vores gatewaylog. Til sidst blev han så frustreret (desværre), at han sendte et billede af kortet. Betalingen gik igennem med det samme, da jeg tastede det gennem backend. Netop denne kunde har haft problemer med betaling før, selvom det bare ligger som et token i vores backend, og selvom der er penge på kontoen. Det strækker sig meget længere tilbage end d. 12. november, for det var samme tid sidste år, at der var problemer med det.

Det er rigtigt lang tid siden, at vi har oplevet nogen med kort fra Danske Bank. Jeg tænker, at der desværre ikke rigtigt er andet at gøre end at vente. Vi er i hvert fald for lille en virksomhed til at tage kontakt til kundernes banker.

Jeg tænker, at det må ligge i koblingen mellem de tokens, som indløseren får fra udstederen, og så koblingen til de rigtige PANs i en eller anden database. Det skulle ikke undre mig, om det er NETS som administrerer tokenization af BIN/PAN numrene i Danmark for visse banker, og at fejlen ligger i en database ved dem.