4.8.10 Fejlfinding

 

Generelt

Når du har modtaget forretningsnummer fra PBS, samt mail fra DanDomain der indeholder koder mv., kan du logge ind her:

 

 https://pay.dandomain.dk

 

og du er klar til at oprette kreditkort betalingsmuligheden i shoppen.

 

Ved fejl ved kreditkort transaktioner gælder, at PBS sender en fejlkode tilbage: PBS Action Code.

Følgende kan benyttes som en checkliste for fejlrettelser.

 

 

Er metoden sat til Test vil der ikke ske kommunikation med PBS, men udelukkende intern test. Testmiljøet er nærmere beskrevet i DanDomain Betalingssystem hjælp således:

Hvis denne parameter medtages og sættes = 1 kører systemet i testmode. Dvs. at det er muligt at teste implementeringen op mod betalingsserveren, uden at der foretages nogen form for rigtig registrering.
For at simulere en betaling kan der testes med følgende kortnr.:
1111111111111111 = Godkendt kort
2222222222222222 = Afvist transaktion

 

Bemærk! Der genereres ikke nogen rigtig transaktion - dvs. at transaktionen ikke kan ses i administrationsmodulet.
Bemærk: Da der er tale om en test implementering, vil der ikke blive trukket informationer fra betalingssystem
administrationen for OkUrl og FailUrl eksempelvis. Disse kan dog sættes ind i html formularen istedet.
(Valgfri)

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

 


 

Forretningsnummer skal, hvis status er sat til Test, altid udfyldes med 1234567
 

 

Eksempel på oprettelse af validering på dansk udstedte Dankort og Visa/Dankort:

 

Procedure ved fejl:

Ved fejl, vil der som regel være mulighed for at finde en fejlkode. Denne kan findes således:

 

  1. Start med at lave en testordre i din shop.
     

  2. Gå frem til betalingsvinduet og test betalingen med eget kreditkort.


     

  3. Skulle der opstå en fejl:



    kan du altid finde fejlkoden ved:
     

 

 

Beskrivelse af problematik vedrørende manglende færdiggørelse af ordre

 

En ordre bliver indsat i databasen i shoppens  bestil step3 – (dvs. der hvor man godkender ordren). Ordren bliver indsat med status som værende ikke gennemført  (incomplete)

 

Hvis der IKKE er valgt en betalingsmetode der benytter en paygateway 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 paygatway er der indbygget et ekstra sikkerhedstjek, så ordren KUN sættes som gennemført, hvis kaldet kommer fra pays 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)