Project

General

Profile

Bug #4382

MobilPay: Samme gebyr betalt to gange.

Added by Nino Tiainen 3 months ago. Updated 11 days ago.

Status:
Needs analysis
Priority:
None
Assignee:
Target version:
Estimated time:
URL med eksempel:
Kategorier:
Min konto - Mellemværende

Description

En låner har betalt gebyr på bibliotek.kk.dk via MobilePay og har fået gennemført to betalinger af samme beløb. Se nedenstående screendump. Låneren har også dokumenteret trækket. Det burde som udgangspunkt ikke kunne ske.

 

Vi har været i dialog med DIBS om sagen og de giver forklaringen nedenunder:

 

”Ifølge DIBS er betalingen sendt frem 2 gange og det mener de kan ske hvis hjemmesiden ikke medsender parameter om at orderid skal være unic.

Der kan læses mere om dette på DIBS tech-site.”

 

Vil I undersøge om der er forhold ved DDB CMS håndtering, som er årsag til ovenstående fejl?

transaktion.jpg (43.7 KB) transaktion.jpg Nino Tiainen, 06/12/2019 12:54 PM
indstilling-DIBS-DING.png (29.6 KB) indstilling-DIBS-DING.png Steen Larsen, 06/22/2019 03:45 PM
bibkkIndstillinger.png (28.3 KB) bibkkIndstillinger.png Nino Tiainen, 09/10/2019 11:07 AM

History

#1 Updated by Rolf Madsen 3 months ago

  • Status changed from New to Ready for development
  • Assignee set to Christel Krabbenhøft
  • Priority changed from Normal to Urgent
  • Target version set to Release 31 - bugfixes

@Christel, jeg synes vi skal prioritere analyse af denne højt, og jeg vil foreslå vi får Reload til at kigge på den.

#2 Updated by Benjamin Rasmussen 3 months ago

  • Status changed from Ready for development to Development
  • Assignee changed from Christel Krabbenhøft to Benjamin Rasmussen

#3 Updated by Benjamin Rasmussen 3 months ago

  • Status changed from Development to Needs code review
  • Assignee changed from Benjamin Rasmussen to Gitte Barlach

Jeg har et PR klart:

https://github.com/ding2/ding2/pull/1466/files

MEN

Jeg har ikke fundet nogen måde faktisk at teste det lokalt.
Jeg har undersøgt sagen i DIBS' dokumentation, og de skriver at vi bare skal have ?uniqueoid=yes med i URL'en til http://payment.architrade.com

Det er dog EKSTREMT VIGTIGT at denne testes virkelig grundigt!

Måden dette fungerer på er at hvis en betalingsid bliver sendt flere gange, så vil alle andre end den første blive nægtet.

I teorien bør det være fint, men der er et par problemstillinger som jeg ikke rigtigt kan sige noget om da jeg ikke har haft mulighed for at teste:

  • Hvad hvis nogen tester på fx. upgrade-fbs og der bliver genereret et payment ID? Så kan dette payment ID jo ikke bruges på produktion. Måske burde der være noget kode der prefixede et ID med miljø info, så ID'er ikke vil blive genbrugt på tværs af miljøer?
  • Forhåbentligt er det ikke et problem, men hvis nu cachen er sat op forkert, så kan det også være et problem der har "virket" indtil nu, som så ikke vil virke længere
  • Gad vide hvad der faktisk sker når en betaling bliver nægtet af architrade? Bliver fejlen vist på en pæn måde i DDB?

 

Jeg synes at det vil være rigtigt fedt at få en eller flere garvede DDB udvikler indover her for at se på mine bekymringer ovenfor.

Hvis dette merges, så ændrer worst-case fejl scenarie fra "En bruger kan komme til at sende penge mere end en gang" til "En bruger kan få nægtet sin betaling"

#4 Updated by Steen Larsen 3 months ago

Jeg antager at Mobilepay via DIBS fungerer på samme måde som betaling med betalingskort?

Den foreslåede ændring findes allerede i forvejen (se nederste del på vedlagte).

De rigtige indstillinger er netop som de viste (findes også i manualen):
Calc fee: "Nej"
Capture now: "Nej"
Unique order ID: "Ja"

Opsætningen findes på DIBS-indstillinger->Ding DIBS debts payment ( /admin/config/payment/dibs/edit/ding_dibs/1 )

Hvilken opsætning har bibliotek.kk.dk haft her?

 

Hvis man overhovedet skal gøre noget, så kunne man måske kigge på at visse variable (heriblandt de viste) allerede er indstillet på forhånd og ikke kan ændres?


Mht at teste på staging og samtidig undgå at få et allerede benyttet orderid?
Her kan man med fordel benytte variablen "Order ID prefix" og så have noget passende, f.eks. "STG" på staging lagt ind der?
(evt. som en del af local.settings.php men det er hosting-udbyderen der skal gøre det - jeg har ikke det præcise navn på variablen her)


Vær i øvrigt opmærksom på at rettelser på admin-siden skal "gøres hurtig" - på samme side gemmes næste orderid og dét nummer vil jo blive ændret når nye betalinger på hjemmesiden foretages af lånerne. Er man for længe om det kan orderid måske blive opdateret til et allerede brugt nummer - sandsynligheden er forhåbentlig lille.


En betaling i DIBS gennemføres først, når FBS har kvitteret for betalingen (hvis min antagelse ovenfor holder), så det lyder virkelig mærkeligt at der er dobbelt-betaling ved den korrekte opsætning.


De fejl jeg oplever ved betalingen på hjemmesiden (NB: ikke app'en) er

  • hvor en låner har forsøgt flere gange og hvor én betaling er gennemført og resten havner i DIBS's fane "Nye/afventer" - hvor man så - manuelt - kan annullere.
  • hvor en låner betaler men FBS fejler (og derved også DIBS). Betalingen kan så manuelt betales i FBS og gennemføres i DIBS.
  • hvor en låner betaler men pga timeout afsluttes betalingen ikke af ddbcms. Dvs den kan være betalt i FBS men skal gennemføres i DIBS (findes på fanen Nye/afventer).

Rydder man ikke op, vil vi nok ikke høre nogle klager fra lånerne, men biblioteket kan evt. miste betalingerne.

I øvrigt vil man i DIBS kunne hente eller få tilsendt transaktionerne med en liste over regningsnumrene - det er ret nyttigt i forhold til fejlsøgning.

#5 Updated by Benjamin Rasmussen 3 months ago

  • Status changed from Needs code review to Needs analysis

Hej Steen

- Ja umiddelbart så er det ikke et problem med mobilepay, men med payment gateway'en (http://payment.architrade.com)

- Ah, jeg vidste slet ikke de indstillinger kunne findes inde i Drupal. Selvfølgelig er det en bedre løsning at det bliver styret der igennem. Jeg undrer mig dog over hvordan det skulle virke, da koden som jeg har rettet i ser ud til at hardcode værdierne istedet?

- De her ændringer til admin siden - er det ikke noget vi burde kunne ligge i en Drupal feature som så automatisk kom med? Eller er der behov for at forskellige biblioteker har forskellige opsætninger

#6 Updated by Steen Larsen 3 months ago

Der er flere moduler i spil bl.a. et generelt DIBS-modul så det er måske i dét modul det indstilles?

Mht test:

Når man som låner er på mellemværende-siden (A) og klikker på betal skifter siden til en videresendelse-side (B) der sender browseren videre til dibs-siden (C). Det er muligt at C også er viderestillet men det er mindre vigtigt.

Hvis du skal teste så gennemfør betaling til og med C men vent med at udfylde felterne med kortnummer m.m.
Åbn ny tab og vis historikken og klik på B der derefter åbner en ny tab med DIBS. Herefter udfyldes/gennemføres første fane. Når 2. fane udfyldes/gennemføres vil denne fejle og der vises en fejlmeddelelse omkring det med unikt ordernummer.
Metoden virker i Google Chrome.

Mht konfiguration:

Alle biblioteker med FBS skal have samme indstilling som beskrevet ovenfor mht fee/capture now/unikt orderid.
Hvordan det evt. kan implementeres vil jeg ikke blande mig i.

Check gerne om bibliotek.kk.dk faktisk er korrekt indstillet?

 

 

 

#7 Updated by Gitte Barlach 28 days ago

  • Assignee changed from Gitte Barlach to Nino Tiainen

Nino, vil du se om Jeres indstillinger på bibliotek.kk.dk er korrekte?

#8 Updated by Gitte Barlach 13 days ago

Hej Nino 
Har du haft mulighed for at se på denne ?

#9 Updated by Nino Tiainen 12 days ago

Hej Gitte: Se vedhæftede. Så vidt jeg kan se, er indstillingerne korrekte. 

#10 Updated by Toke Leth Laursen 12 days ago

Vi har i Silkeborg oplevet det to gange indenfor den sidste uge, at en låner med kortbetaling betalte det samme gebyr to gange. 

Hende vi har talt med, synes det tog for lang tid og trykkede opdater i browseren og betalte igen.

 

Vi havde værdien "Capture now:" sat til "Ja"  ( /admin/config/payment/dibs/edit/ding_dibs/1 )

Det er nu rettet til "Nej"

Men jeg er usikker på om dette skabte problemet, eller om det er det samme som denne sag. 

#11 Updated by Steen Larsen 11 days ago

KK's indstillinger er korrekt nu.

Hvis Capture now er sat forkert vil det netop give anledning til gentagne hævede beløb.

Jeg vil foreslå at sagen afsluttes.

#12 Updated by Nino Tiainen 11 days ago

Hej @steen: Indstillingen var også som vist på screendumpet, på det tidspunkt hvor brugeren oplevede fejlen. 

#13 Updated by Rolf Madsen 11 days ago

  • Assignee changed from Nino Tiainen to Steen Larsen
  • Priority changed from Urgent to None

#14 Updated by Christel Krabbenhøft 11 days ago

  • Assignee changed from Steen Larsen to Rolf Madsen
  • Target version changed from Release 31 - bugfixes to Release 32 - Bugfixes

#15 Updated by Toke Leth Laursen 11 days ago

Steen Larsen skrev:

KK's indstillinger er korrekt nu.

Hvis Capture now er sat forkert vil det netop give anledning til gentagne hævede beløb.

Jeg vil foreslå at sagen afsluttes.

 

Bemærk at min kommentar var fra Silkeborg og ikke relateret til den oprindelige sag.

 

mvh.

Toke

#16 Updated by Steen Larsen 11 days ago

Den oprindelige sag er mere end 3 måneder gammel og er det overhovedet muligt at fejlsøge yderligere?

En oplysning som mangler er hvordan de to transaktioner ser ud i dibs ( DIBS administaion / Betalinger / Rapport ) - kan man udlede noget ud herfra? Rapporten kan hentes for en vis perioden og så kan man søge regningsnumrene frem - de må jo være der to gange.

Men hvis vi ikke kan sætte fingeren på noget konkret (indstilling, kode, workflow) som forårsager fejlen eller hvis vi ikke kan genskabe fejlen kan det være svært at rette.

Jeg har i note-6 beskrevet hvordan man kan teste at betalingen faktisk fejler som forventet hvis man forsøger at betale flere gange og på den måde kan man se at indstillingerne er korrekte som vist i administrationen. Men er indstillingerne korrekte kan man jo nok ikke afvise at der kan opstå fejl pga andre (ukendte) årsager.

Also available in: Atom PDF