@bell
Forumsvar skapade
-
Inlägg
-
@JohnL 85400 wrote:
Hej
Av alla påbörjade transaktioner på Payson så slutförs ca 88-90 %.
Jag vet inte om du haft otur med dina 8 första kunder, eller om det helt enkelt är så att dom ångrat sig.
Med vänlig hälsning
John
Key Account Manager PaysonIntressant!
Räknar du med samtliga transaktioner i den siffran?
Även de nekade, de med error, de (av kunden) avbrutna och de där sessionen förfallit?
Blandar du transaktioner med och utan 3D Secure?
Jag har inte läst hela diskussionen, ber om ursäkt ifall jag missat något på grund av det.
@Kodmyran 81260 wrote:
Där tror jag du har problemet (men jag är inte 100 % säker utan det är min teori), för att skatteverkat ska godkänna systemet så gissar jag att du måste använda kassasystemets databas eller annan databas de har koll på så att de är säkra på att fusk inte kan uppstå, som master. Gissningsvis så ska den databasen då sakna möjlighet att radera transaktioner mm. Det är nog därför mycket svårt för kassasystem att säljas så att de ska fungera utan databas eller med valfri annan databas från annat system. Det är också därför kassasystem är väldigt låsta och inte har så stora integrationsmöjligheter. Du ska ju inte kunna förändra saker där på det sätt du kan göra i andra system. Alltför stora integrationsmöjligheter skapar utrymme för fusk och det vill nog både skatteverket och kassasystemsskaparna undvika
Ang krav från SKV så behöver det inte utesluta en master.
Den fysiska terminalen kan ha en sådan databas oberoende av master. Transaktionen lagras först hos master, därefter i terminalen. Mastern styr och kan manipuleras, medan terminalens databas fungerar som logg för SKV.
Eftersom det inte finns nån koppling direkt mellan terminalens databas och masterns, utan två parallella kopplingar (terminal <-> master, terminal <-> terminals db) så bör det inte vara nåt problem med SKV.
Kanske Kassalösningar för alla miljöer – Open Solution kan ha något?
Jag implementerade direktbank/direktbetalning i Finland för flera år sedan. Den betalväxeln hette Suomen Verkkomaksut. De verkar ha bytt namn, tror det är dessa: Shopping Anywhere | Paytrail. Kanske en hjälp med den finska biten.
Det finns ingen generell relation mellan höjd och bredd, beror inte bara på vilken font det är utan också vilka tecken.
Generellt så finns det inbyggda funktioner för att beräkna bounding box på en text i sin helhet. Beror på vilken teknik du använder. Om du bygger nåt för webben så kan du lösa det i Javascript. Finns också native-funktioner i SVG.
Om inte annat så finns den informationen per tecken i själva fonten (sk font metrics).
Beroende på hur kritiskt detta är så finns det en viktig sak som jag tror ni missar. Att på ett eller annat sätt reservera en vara i lagret och låta den reservationen ligga medan köpet genomförs är bra. Risken att detta missbrukas höjs naturligtvis ju längre tid reservationen är giltig och därför är korta reservationstider att föredra. Inte så mycket som en timme, men nånstans 10 – 15 minuter.
Problemet som jag tror ni missar uppstår när en reservation läggs och betalningen tar längre tid än vad reservationen är giltig. Att höja reservationstiden minskar denna risk, men ökar å andra sidan risken för missbruk.
Det en behöver göra är att i callback från PSP kontrollera reservationen och om den har gått ut a) reservera på nytt, om möjligt b) om det inte är möjligt (slutsålt / fullt) neka transaktionen från callback så pengarna går tillbaka och köpet avbryts (efter att det genomförts så att säga).
Det är inte så många PSP som har stöd för att neka transaktioner när de har gått igenom (en reverse från callback) men några har det, exempelvis Paynova som SJ kör med.
En vattentät lösning är alltså reservation med låga reservationstider + kontroll av reservation i callback. Om det är en vara som är svår att beställa mer av eller där det säljs i hundratal per timme vid peak så behöver en gå hela vägen med reverse i callback.
Alternativet att köra reservationstiden lika lång som sessiontiden hos PSP är en enklare väg men kan fallera ifall sessionstiden ändras (förmodligen inte något som PSP kommunicerar ut) eller fördröjningar eller fel hos PSP eller inlösare sker. En enklare väg men fler felkällor.
“Kundsidor”, “Mina sidor” eller dylikt, alltså där kunder kan logga in
Pressida
Jobbsida
NyhetsbrevssidaOch varför inte “cookiessida”
@Dan 48601 wrote:
Det är väl bara att först anropa kassan och ta emot en session eller cookie och sedan anropa scriptet?
Hur stoppar det missbruket? Om en vanlig användare kan anropa scriptet så kan en bot alltid också göra det?
Oftast räcker det med att anropa scriptet direkt och skicka med lite vad som i en cookie, då de flesta skydd mot CSRF bara kollar om cookie-n är satt utan att närmare validera hashen. Något som ändå är effektivt för CSRF.
Helt rätt alltså att det inte kommer att stoppa något missbruk, men i bästa fall kräver det mer av någon som vill missbruka.
Instämmer med Johan_W. Det är en beprövad approach för att förhindra så kallad CSRF.
Gissningsvis kommer ingen att missbruka detta löpande, utan snarare vid enskilda tillfällen för att utöka diverse dataregister till exempel. Således kan det vara en bra idé att även begränsa antalet förfrågningar per IP och dygn till 20 eller 30. Kommer inte störa någon vanlig besökare, men ytterliggare försvåra omfattande slagningar.
/Bell
@FredrikGust 32745 wrote:
Mitt råd är helt klart att du i så fall väljer den plattform som passar bäst och tar fram moduler dit i stället, så du inte behöver riskera projektet, budgeten och en massa annat för att man missar att utveckla något som redan finns i de färdiga systemen.
Det är ett gott råd. Men du kan även fundera över nödvändigheten i att lansera om två månader till priset av att ni då inte har den plattform som behövs.
Kan det vara bättre att lansera om 6 månader med rätt plattform, skynda långsamt? Vilka krav är absoluta för att verksamheten ska fungera?
Det är egentligen bara att räkna på lönsamheten i att ta fram en halvbra plattform först och senare ta fram en fullskalig plattform. Och naturligtvis överväga risken med att göra större investeringar på en obeprövad (?) affärsidé, som ett egenutvecklat system skulle innebära, eftersom det i de allra flesta fall är det dyrare att ta fram nya plattformar.
Jag tror att den här typen av menyer kommer bli allt vanligare, det är helt klart en trend.
@Joel 31648 wrote:
Jag såg att menyn som länkandes till i originalposten har en viss fördröjning innan den visas/döljs efter det att musen dras till/från den. Är det att föredra?
Jag tycker att det är att föredra men inte på det sättet som de gör det.
Om du drar musen snabbt över menyn så ska inte någonting triggas, deras meny däremot öppnas och stängs en gång. Att ingenting triggas om du drar musen snabbt över är klart att föredra och därmed behövs en fördröjning.
Deras meny är dessutom lite buggig och om en meny har stannat öppen, även om du inte har musen på den, så borde du kunna stänga ner menyn genom att klicka någonstans utanför den. Det går inte med deras.
Det sista felet som jag tycker att de gör är att deras meny inte har någon variation med hänsyn till musens känslighet. Om du drar musen till menyn och låter den stå still eller nästan still, så borde menyn triggas omedelbart. Att de inte gör det så leder till att deras meny upplevs som lite trög och segladdad.
/Bell
