Teknik, hosting & e-handelsløsninger

Svar: Alternativ Til QuickPay?

Cookie - John Hannover — Fri, 03 Nov 2017 22:55:11 GMT

herligt i deler jeres indsigt fint her - tillid giver det

vh John H

Svar: Alternativ Til QuickPay?

Thomas Jensen, QuickPay — Fri, 03 Nov 2017 22:02:16 GMT

Hej

Lige for at runde den her af - tror såmænd nok at de danske gateways både har prioriteret og har styr på callbacks. Men i både teori og praksis er det en lidt uhåndterbar størrelse - (se også hvad Ulrik skriver). Du tror det er løgn hvad man som PSP møder af skrammel af webservices på internet, elendige webservere m. urimelige svartider, fejlkonfigurerede firewalls og defekte cachede navneservere. Naturligvis er det altid PSP'ens skyld at kundes webhotel til 5,-/mdr. ikke får instant callback (ironisk smiley) - vi har set eksempler på kunder som har formået at DDOS'e sig selv m. den ene hånd og blame os m. den anden :)

Igen; ikke sagt for at fralægges os ansvaret for problemerne forleden dag, men blot pragmatisk betragtning.

I tidernes morgen havde vi implementeret callbacks i realtid - siden er vi blev klogere (og der er kommet en del flere transaktioner og øget kompleksitet). Men vi har nok også være for ringe til at kommunikere at, folk gerne må kigge på andre løsninger end callbacks.

vh

thomas jensen

Svar: Alternativ Til QuickPay?

Ulrik Moe — Fri, 03 Nov 2017 17:31:17 GMT

Hvis det er implementeret korrekt (i begge ender) kan det sagtens være en fin løsning til nogle systemer, men det er en antagelse som sjældent holder i den virkelige verden. Hvor mange af jeres kunders endpoints: bruger TLS, validerer signatures (timing safe) og er sikret mod injection/DoS angreb? Meget få gør det korrekt og mange bygger deres integration med dumme antagelser, e.g. at signatur validering kan erstatte input validering.

Polling er i sagens natur meget simplere end callbacks. I vores tilfælde er forskellen enorm. Vores database gemmer ændringer separat (transaktionsdata overskrives aldrig) og det er disse ændringer som kunden henter. Nye ændringer holdes i hukommelsen og skydes afsted med det samme. Meget lidt kan gå galt – og så er det lynende hurtigt. Hvis vi skulle tilbyde webhooks ville det, alt andet lige, have en højere fejlrate end polling.

@brandur fra Stripe har beskrevet nogle fordele og ulemper ved webhooks her.

Svar: Alternativ Til QuickPay?

skanse72 — Fri, 03 Nov 2017 12:30:42 GMT

Det må være et spørgsmål om prioritet, som sagt brugte vi en engelsk gateway i mere end 2 år uden problemer der var baseret på asynkrone callbacks. Det ser ud til, for de danske gateways vedkommende, at de ikke satser i samme grad på callbacks men er sat op til at kunden kalder ind på gateway serveren.

Jeg kan i øvrigt oplyse, at vi nu har implementeret og er online med vores nye løsning der via php/Curl kalder ind på QuickPays API, jeg må sige jeg er meget imponeret over hastighederne og de muligheder man har i API'et - det kører super hurtigt og stabilt indtil videre.

Svar: Alternativ Til QuickPay?

Thomas Jensen, QuickPay — Fri, 03 Nov 2017 11:37:03 GMT

Hej

Gætter på der tænkes på tidskritiske løsninger.

Men enig i at der er mange scenarier hvor callbacks/webhooks giver fin mening.

thomas

Svar: Alternativ Til QuickPay?

Tonni Tølbøll Lund Aagesen — Fri, 03 Nov 2017 09:35:35 GMT

Ulrik Moe:
Callbacks/webhooks er en dårlig løsning, særligt hvis man går op i driftsikkerhed.

Jeg må bekende mig lidt nysgerrig på, hvad det er, der gør callbacks/webhooks til en dårlig løsning ift. driftssikkerhed. Kan du uddybe det lidt? :)

Svar: Alternativ Til QuickPay?

Ulrik Moe — Thu, 02 Nov 2017 12:12:59 GMT

Callbacks/webhooks er en dårlig løsning, særligt hvis man går op i driftsikkerhed. Derfor valgte vi et andet paradigme hos Scanpay. Vores kunder modtager ét ’ping’ ved hver hændelse, f.eks. en ny betaling, men dog mindst 1 ping hvert 5. minut. Pings indeholder et sekvensnummer (’seq’), som stiger når der er sket en hændelse. Dvs. at når nummeret stiger er det fordi der er en hændelse, som du kan hente fra vores database. Vi holder ikke styr på hvilke hændelser du har hentet, men giver adgang til alle hændelser i din shops historie. (læs mere)

Fordelene er mange. Det giver højere driftsikkerhed og dataintegritet, bedre performance, lavere svartider og så er det simplere at implementere korrekt og sikkert. Du skal ikke være bange for at misse pings (f.eks. pga. nedetid) og du vil elske os hvis du en dag bliver nødt til at gendanne dit system fra en backup. Vores platform er i øvrigt programmeret i C.

Ift. kritikken af QuickPay. Der er mange dårlige PSPs, men QuickPay er ikke en af dem. De ved hvad de laver og har nogle dygtige udviklere. Nogle af de fejl som her tilskrives QuickPay er i virkeligheden helt uden for deres kontrol (skyld). Det er svært at danse med store banker, Visa/MasterCard og EU :)

Svar: Alternativ Til QuickPay?

mandeblad — Wed, 01 Nov 2017 13:50:38 GMT

Jeg bliver nødt til at bede dig om at pege på hvor der står at man ikke bør bygge tidskritiske løsninger (Jeg kan nemt have overset noget), nu prøvede jeg lige løst at kigge jeres tech-talk igennem, uden at jeg synes der står noget (Jo der står at det er asynkront, men vækker ikke nogen alarmklokker i mit hoved, tværtimod). Hvis jeg kigger under callback står der netop at det ikke vil forstyrre eller forlænge behandlingstiden.

Umiddelbart har vi ikke før nu fået af vide at callback måske ikke var den rigtige løsning, men vi vil kigge på om vi skal have ændret vores system så det er os der skal lave opslag for at finde ud af om betalingen er gået igennem, umiddelbart synes jeg bare at det virker som en tungere løsning for alle parter.

Tilbage i februar da der var et lignende problem, var der ingen der nævnte at vi skulle overveje at bruge en anden løsning selvom vi havde kontakt med jer :(

Der kan og vil opstå fejl, sådan er det med den slags teknik, og i den her omgang er mit indtryk også at i opdaterede jeres statusside passende, og som sagt så har vi desværre kun værre erfaringer med andre :) Men jeg synes at vi så småt har ramt det vi skal igennem for de næste par år (2x store callbacks problemer, problemer verified by visa/3d secure, problemer med mobilepay betalinger der registreres som betalt i app'en men ikke i quickpay, alt sammen i 2017 - Om der er mere vi ikke har opdaget tør jeg ikke at sige).

Svar: Alternativ Til QuickPay?

Thomas Jensen, QuickPay — Wed, 01 Nov 2017 13:40:12 GMT

Hej

Vi har så rigeligt 99.99% oppetid for callback-servicen.

Den typiske responstid måles i milisekunder.

Der er mange årsager til at callbacks ikke er fjernet - både historiske men også fordi det giver god mening i ikke tidskritiske services.

Vi skal beklage bøvlet endnu en gang - og det lyder godt at I vil optimere. Vi har for så vidt alle den samme interesse.

thomas

Svar: Alternativ Til QuickPay?

skanse72 — Wed, 01 Nov 2017 13:30:11 GMT

Tak for alle svar, jeg synes der er en masse man kan bruge fra jeres indlæg.

Efter at have kigget på løsningerne igen og læst indlægget her fra "Mandeblad"", så ser det ud til vi har valgt en forkert løsning med callbacks (aynkrone kald). Vi har i de sidste par år brugt en engelsk gateway, her fungerede deres asynkrone callbacks perfekt, de oplyste at 99.99% af deres callbacks kom frem indenfor 5 sekunder og det fejlede aldrig, herefter var det nemt at sætte vores system op til det, ingen API kald frem og tilbage, der var kun det enkelte callback, nemt og 100% stabilt.

Det lader til de danske gateways ikke har samme fokus på asynkrone callbacks, se også indlægget fra "mandeblad" i denne tråd, EPay har åbenbart samme problemer. Et godt råd til gateways, gør en af disse 2 ting:

1) Meld ud præcist og giv en garanti på jeres asynkrone callbacks så folk ved hvad de kan regne med

2) Ellers afskaf produktet, det skader jeres navn mere end det gavner

Vi går nu igang med at omkode vores løsning til at spørge ind på QuickPays API og helt afskaffer de asynkrone callbacks. Det ser ud til at vi har valgt en forkert løsning og ikke en forkert gateway.

Svar: Alternativ Til QuickPay?

Thomas Jensen, QuickPay — Wed, 01 Nov 2017 07:18:36 GMT

Hej

Allerførst: det er korrekt at QuickPay i går havde nogen forsinkelser på sit køsystem. De opstod pga nogen ændringer i køsystemet der er introduceret for at behage et større nordamerikansk shopsystem (shopify). Problemerne blev relativt hurtigt løst - og så gik der desværre nogen timer m. at få afviklet køen.

QuickPay i sin grundsubstans er klippestabilt. Tror godt jeg tør påstå at det by far er branchens mest stabile og skalerbare system.

Og når det så er sagt må jeg påpege at QuickPay alle steder gør opmærksom på at køssystemet _er_ asynkront og at man ikke bør bygge tidskritisk forretningslogik op om callbacks. Laver man tidskritistiske tid bør man spørge QuickPays API som på intet tidspunkt var presset.

Så inden man skyder m. spredehagl på leverandører m. services som er tænkt/designet til i periode at være asynkrone/havde svartider længere end instant bør man også overveje at kigge på egne applikationer og flow.

Dette ikke skrevet for at fralægge ansvaret for problemerne i går - dem står QuickPay fuldt ved, og annoncerede også mange gange gennem eftermiddagen. Men nogen gange er verden altså ikke helt sort/hvid og man kan godt selv gøre noget i egen ende.

Thomas Jensen, QuickPay

Svar: Alternativ Til QuickPay?

mandeblad — Tue, 31 Oct 2017 23:04:55 GMT

Vi gik for et snart par år siden fra Epay til Quickpay.

Årsagen var at vi i perioder havde callbacks der ikke virkede, og da vores opbygning er ret tidskritisk (Tidsfrister for bestillinger) var det tit et problem at næste kald først kom en time efter, der er det for sent.

Først meget langt inde i forløbet fik vi nogen fra Epay til at indrømme at det måske periodisk under pres kunne være deres system der fejlede fra tid til anden, indtil da havde vi haft MEGET fokus på vores webserver og kode, da Epay's fejlkoder ikke gav nogen hjælp (Eksempelvis 404, men det var ikke vores web der gav 404, fandt vi ud af...) og det tit bare var 3-4 ud af 500 betaligner der fejlede i løbet af en time - Vi kunne jo ikke udelukke at det var vores webserver/side der gav problemer.

Jeg skrev og ringede til dem af flere omgange, for at høre hvad vi kunne gøre og udtrykke min bekymring uden at det nogensinde blev taget seriøst. En af bekymringerne var da vi kunne dokumentere nogen af deres fejl, og de ikke opdaterede deres egen statusside - Det fik vi aldrig noget ud af at nævne.

Så selvom vi ikke gad bøvlet, så skiftede vi betalingssystem. Problemerne har været FÆRRE ved Quickpay, men der har været et par omgange, og det i dag har også givet os travlhed i telefon- og mailsupport, "thankyou Quickpay"...

Quickpay havde et større nedbrud i starten af året, vi kunne dokumentere at vi mistede omkring 15.000kr i omsætning på det (Meget nemt, se hvad der kommer på tilsvarende dage, og i hvilket tidsrum, og det er desværre ikke omsætning der kommer "senere", ikke pyntet på eller gjort større end det er, for at gøre det helt perfekt står vi med leverandører i den anden ende som vi må kompensere da forecast så ikke passer i en for stor grad), en meget stor mængde sure kunder og rigtig, rigtig mange timers support og brandslukning - Det hele blev beskrevet for dem, Quickpay takkede for at vi forklarede hvordan fejlen påvirkede os som kunde og reagerede ikke yderligere på det. Jeg forventede reelt heller ikke det store, men synes de burde havde gjort ... noget. (Den dag præsterede de også IKKE at opdatere deres statusside i meget længe, så vi stod i vildrede om hvor fejlen reelt lå - Så _alle_ måtte i gang med at fejlsøge, netværk, udviklere og server, så både vi og vores udbyder måtte på overarbejde).

Når det er sagt, så kører det til hverdag, og vi har brugt en del energi på at lave en lækker betalingsside med Quickpays betalignsvindue (Selvom det er bøvlet :D) og er meget glade for resultatet.

Vi har erfaringen at der desværre er MEGET stor forskel på kvaliteten af supporten ved Quickpay, alt efter hvem man får fat i :( Og ved af erfaring fra andre store kunder, at det har været sådan i mange år. Senest giver callbacks problemer, og de har fjernet funktioner fra API'et på området, og vi har endnu ikke kunne få et seriøst svar på hvad vi skal forvente, om det kommer igen eller hvad der sker.

Helt generelt, så ER vi tilfredse - Og fejl sker, men der skal ikke ske meget før vi er på niveau med vores oplevelse med Epay... Jeg ved ikke hvem vi skal skifte til hvis vi skal prøve noget nyt, vi har omkring 15.000 betalinger om måneden og behov for at kunne lave en fræk integreret betalingsløsning (Javascript-Iframe løsningen bruger vi nu).

DIBS har vi erfaring med fra andre projekter, det må også blive et nejtak.

Svar: Alternativ Til QuickPay?

Skovborg + Høgh ApS — Tue, 31 Oct 2017 22:51:16 GMT

Hejsa,

Jeg vil helt klart anbefale ePay. Det er nemt at kode op imod deres system og vigtigst af alt, så er det super stabilt. Jeg har aldrig oplevet problemer med dem. :)

Med venlig hilsen

Kristian Kristensen

Svar: Alternativ Til QuickPay?

Andreas — Tue, 31 Oct 2017 19:12:54 GMT

Jeg ved ikke om de kan sammen med Clearhaus, men Yourpay.io er vi fint tilfredse med.

Svar: Alternativ Til QuickPay?

Cookie - John Hannover — Tue, 31 Oct 2017 17:46:42 GMT

test evt egne priser per handel og antal per måned i www.kortgebyr.dk Både quickpay og e-pay får generelt pæne kommentarer men se evt hvad der er af muligheder med jeres handelsmønster
Test med og uden flueben i dankort

vh John Hannover