jeg har i mellemtiden leget lidt med at kører dem i loop om mod dibs, da vi nødigt vil midste deres logo (trykhed for kunden) og da det er muligt for mig at hæve noget der ligner 2,5 ordre pr. sekund, tror vi beholder DIBS lidt endnu. Dermed ikke sagt at problemmet ikke vokser, for 2,5 ordre/sek. sætter jo også en grænse for hvornår det ikke længere er praktisk at hæve på den måde.
Vi er et udvikler virksomhed som har i gennem de sidste ti år lavet meget inden for web og webshops.
Vi har lavet auto systemer til Europæiske og Telmore, der kan hæve mange tusinde ordre af gangen.
Ikke nok med det, bliver du så stor en dag, at du har flere transaktioner kan vi skabe et sammenarbejde med dig der gør at du slet ikke bruger PBS og dermed spare en del penge.
Ring til mig 70 20 11 04 > Spørger efter Robert
/ Robert Radut
rr@webia.dk
www.webia.dk
70 20 11 04
Jeg har siddet og kigget lidt på denne tråd, og har til jer hos MovieZoo et spørgsmål til hvordan jeres arbejdsgang er opbygget? Når I sender kundens vare, sker det så ikke automatisk i form af I blot scanner en stregkode og får pakken ekspederet med Post Danmark eller et andet fragtselskab? I kunne eventuelt lægge en procedure ind, der hævede ordren med det samme produktet er overdraget til 3.mand, og på den måde hæve jeres ordre løbende mens de bliver behandlet. Hos ePay har vi en række kunder med høj volume, som vi har hjulpet med at implementere denne løsning, hvilket kunderne har været ganske tilfredse med. På den måde bliver kundernes økonomisystem også opdateret med det samme ordren er shipped. Information om vores API (Webservices) kan findes her: http://www.epay.dk/support/docs.asp?solution=3. Løsningen gør også belastningen spredes ud over arbejdsdagen og dermed ikke belaster jeres system.
Hvis det ikke kan lade sig gøre at hæve jeres betalinger løbende, så tilbyder vi hos ePay, for alle vores produkter, batch-capturing i form af CSV filer, der sendes med FTP til os, og svar der ligeledes foregår gennem CSV. Hvis vi snakker om 10.000 capture på én gang kan jeg ikke anbefale brugen af vores API da der er et alt for stort overhead i transmissionen via HTTP + SOAP. Der er hos ePay ikke noget krav om at capture (hævning) kun må ske om natten, da vi har et system opsat til dette alene, og dermed ikke belaster resten af ePay. Udseendet af filerne er dynamisk, og vi kan tilpasse det kundens behov, således eksisterende systemer ikke behøves at blive ændret. Dette har vi ind til videre kun haft positiv respons overfor.
10.000 transaktioner i døgnet er ikke noget problem.
Typisk løses det ved at uploade en batch fil til en betalingsudbyder (en såkaldt IPSP). Denne betalingsudbyder vil så sende transaktionerne parallelt til "banken". Udfordringen er, i samarbejde med "banken" (indløser, acquirer, etc. - kært barn har mange navne), at blive enige om hvor mange samtidige transaktioner man må sende til dem.
Vær naturligvis opmærksom på at selvom en "bank" tillader 5 samtidige transaktioner, så tager en transaktion op til cirka 5 sekunder per styk. M.a.o. så er 5 samtidige transaktioner reelt kun 1 transaktion i sekundet. Er det svært at få overtalt "banken" til at modtage det krævede antal samtidige transaktioner vil man typisk sende transaktionerne til flere forskellige "banker" samtidig. Dette er også en fornuftig sikring af ens forretning - teknisk såvel som økonomisk.
Vi har mange års erfaring inden for området - du er velkommen til at kontakte mig hvis du har brug for et par uforpligtende råd.
Bliv gratis medlem
Opret bruger