Fejlfinding

Generelt

BEMÆRK: Dette omhandler kun betalinger til DanDomain Betalingssystem.
Ved fejl bliver transaktionen tildelt en fejlkode, denne kode vises typisk ved forsøg på hævning af beløbet,
eller under “Aktivitetslog” på http://pay.dandomain.dk

Fra shop admin:

betalingsstatus

Fra Pay Manager:

payfejlkoder

Ved Brug af Pay Manager ( http://pay.dandomain.dk ):

  1. Tryk på “Aktivitetslog” for at se indgående transaktioner, vær opmærksom på dato intervaller i toppen.
  2. Forklaring af de forskellige fejl koder, tildelt af DanDomain kan ses HER.
  3. Ved fejl kode 4, er der kommunikeret med NETS, og transaktionen er afvist af NETS.
    De forskellige handlingskoder fra NETS er forklaret HER.

!En korrekt gennemført transaktion vil stå som Fejlkode “0” og Handling “0”.

Betalingsmetode Live eller Test

Er Status sat til Test kommunikeres der ikke med Nets. Testmiljøet er beskrevet i DanDomain Betalingssystem hjælp således:
Hvis parameter medtages og sættes = 1 kører systemet i testmode. Dvs. at det er muligt at teste implementeringen mod betalingsserveren, uden at der foretages en rigtig transaktion.

For at simulere en betaling kan der testes med følgende kortnr.:
1111111111111111 = Godkendt kort
2222222222222222 = Afvist transaktion

Da der ikke er tale om en rigtig transaktion kan den ikke ses i administrationsmodulet og der vil ikke blive trukket informationer fra betalingssystem administrationen for OkUrl og FailUrl. Disse kan dog sættes ind i html formularen istedet.(Valgfri)

Betalingsløsning kan i shoppen ændres således:
fejlfinding1

Forretningsnummer skal, hvis status er sat til Test, være 1234567

  • Ugyldig korttype.

    Såfremt der filtreres på korttyper der kan benyttes, er det vigtig at være opmærksom på følgende:

    • Korttypen Dankort alene, kan ikke benyttes ved brug af et dansk udstedt Visa/Dankort. Vælg da altid som vist på billedet nedenfor både Dankort og Visa/Dankort.

    • Mastercard og Eurocard mm. kan være dansk og internationalt udstedt. Det betyder, at der er forskel på for eksempel et Mastercard udstedt i Danmark i forhold til ét udstedt i Sverige. Gebyrer for transaktioner til NETS vil være forskellige.

fejlfinding2

Integreret betallingsvindue

For at integrere betalingsvindue i shoppen (i modsætning til at fremkomme enten i et nyt vindue eller som pop-up) skal følgende være opfyldt:

  1. Stier til billeder og andre elementer der vises sammen med betalingssiden, SKAL være relative, og ikke absolutte.Eksempel på absolut sti: http://www.minshop.dk/images/bundgrafik.jpg
    Eksempel på relativ sti: /images/bundgrafik.jpg
    Eneste undtagelse gælder flash filer. Disse skal, for at vises i alle browsertyper, altid linkes til via absolutte links.
  2. Billeder og andre elementer må ikke indeholde Æ, Ø eller Å i filnavn og andre specialtegn, samt mellemrum
  3. Inkluderes egne styles, eller stylesheets, skal URL’er angivet i stylesheet være quoted korrekt (Via tegnet: ‘ ):Eksempel ses herunder:
    Forkert: body {background-image:url(paper.gif)}
    Rigtigt: body {background-image:url(‘paper.gif’)}

Problematik vedrørende manglende færdiggørelse af ordre

En ordre indsættes i shoppens database, når slutkunden godkender ordren (bestil step3). Ordren indsættes med status ikke gennemført  (incomplete)

Hvis der IKKE er valgt en betalingsmetode der benytter en paygateway(Betalingsvindue) sendes den handlende direkte til bestil step4, hvor ordren bliver modificeret til at stå som gennemført og der sendes ordrebekræftelsesmail.

Hvis der ER valgt en betalingsmetode der benytter en paygateway sendes den handlende over til den valgte gateway og det er nu den aktuelle gateways ansvar at sende et svar tilbage til shoppens bestil step4, når betalingen er gennemført, så ordren kan blive sat som gennemført og der kan sendes emails.

De fleste typer gateways vil foretage 2 typer af kald tilbage. Et kald hvor det er selve clienten der redirectes (altså så brugeren rent fysisk lander på bestil step4 og kan se ordrebekræftelsen på sin skærm) og et kald direkte til shop serveren der foregår transparent for brugeren. Det skjulte ”callback” er en ekstra sikkerhed for at callback ikke forhindres af klienten feks. iform af sikkerhedsbegrænsninger for javascript. Af kendte issues med dette skjulte ”callback” kan nævnes betalinger foretaget med Danske Bank betalingsgateway, da deres system også foretager dette ”callback” clientside (hvorved der kan opstå scenarier, hvor klienten får blokkeret for callback )

Hvis der benyttes betalingsmetoder der anvender DanDomains paygateway er der indbygget et ekstra sikkerhedstjek, så ordren KUN sættes som gennemført, hvis kaldet kommer fra pay.dandomain.dk’s ip range.

Session udløber og dør

Fælles for ALLE ”callbacks” til shoppens bestil step4 er, at den browser sesssion som den handlende har foretaget sit køb i, SKAL være aktiv for at shoppen kan modificerer ordren og sende mails. HVIS sessionen af en eller anden grund IKKE er i live, så bliver brugeren sendt til forsiden, der bliver IKKE sendt mails og ordren vil forblive incomplete.

Kendte scenarier for at shoppens sessions udløber og dør er følgende.

a) Der benyttes ikke popup på betalingsmetoden, hvorved den handlende ”fysisk” forlader shoppen i betalingsprocessen.    Derved kan shoppen ikke holde sessionen i live, så hvis den handlende er mere end 20 min. om at gennemføre betalingsdelen vil shoppens session være udløbet.

b) Shopserveren mister sessions enten som følge af service genstart (planlagt vedligeholdelse eller programfejl).