Alternativ Til QuickPay?

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 :)

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.

vh

thomas

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.  

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

herligt i deler jeres indsigt fint her - tillid giver det

vh John H