24. september 2008 - 11:26Der er
28 kommentarer og 2 løsninger
Web shop hvor skal jeg starte
Hej allesammen.
Nu har jeg prøvet og lavet en ret avanceret bruger system til min hjemmeside. Samt et fotogalleri, nyhedssystem, forumsystem, kalender, auto tlf liste.
Men nu vil jeg gerne prøve og lave en web shop til min side. Jeg været lidt rundt på nettet og søge om det, og man kan købe sig adgang til afskillige rundt omkring. Men med de erfaringer jeg har fra programmering, har jeg haft KLART mest glæde for at selv at lærer de forskellige ting, frem for "bare" at kopiers andres koder. For det lærer man ikke rigtig noget af.
Derfor ville jeg høre om hvor svært det er og lærer sådan noget, hvor lang tid det tager, hvad det kræver og hvor man evt. kan finde guider til opbygning henne?
Har kun programmeret i følgende "sprog":
html css php mysql
Men kræver det andre sprog for at kunne programmere en sikker webshop?
For som sådan kan jeg jo godt lave hele delen med lagerbehodning, sætte varer ind på siden, flytte varene ind i en kurv hvis kunden ønsker dette (Går ud fra at dette kan gøres via en session f.eks.) osv. Det er faktisk kun betalingsdelen som jeg ikke har en jordisk anelse om hvordan man laver?
Næ. Det kræver ikke viden om andre sprog for at kunne kode en webshop. MEN! jeh vil klart anbefale dig at lære noget javascript. Det kan blive nyttigt ved varevisning og den slags. Men som sagt er det slet ikke et krav. Dog er der en enkelt fordel ved at bruge javascript når vi snakker sikkerhed. Dette kommer vi tilbage til.
Der er to måder du kan "angribe" tingene på(hvis vi KUN snakker PHP/MySQL). 1) Med Sessions. 2) $_SERVER[] arrayet.
Jeg vil anbefale dig at benytte sessions, da server arrayet i tilfælde af brugeren blot lukker browseren, ligger og holder på en masse informationer som kan konflikte med dynamikken senere. Omvendt er det her et javascript kommer ind i billedet. Du kan jo lave et tjek på om brugeren forsøger at lukke browseren. Gør han det, så skal en bestemt url kaldes som nulstiller serverarrayet for den respektive bruger.
Derfor er sessions nemmere. Dog har sessions den ulempe at du ikke kan lave "live" lager styring. Forestil dig en vare der kun er én tilbage af. En bruger har valgt denne sidste vare til sin kurv, og surfer rundt efter flere varer. Imens ligger endnu en kunde denne vare i kurven, og surfer går til kassen. Når han tjekker ud, opdateres lageret og varen er bestilt. Den første kunde gør det samme, men nu er der så en vare i underskud. Altså kan der være et problem her.
Der findes sikkert andre måder at gøre det på, men man kunne nu også kombinere de to. Det der er "fælden" er at holde informationerne i indkøbskurven når brugeren surfer rundt på siden og undersiderne, men samtidig også sig ajour med lager antal og beløb.
Mybad. i har begge svaret før jeg fik sendt dette svar.
betalingssiden er der meget strikse krav til hvis du skal kunne samarbejde med PBS. Dette kan du læse dig frem til. Spørg mig ikke om hvor. Men en god bog til dette, som hvis man følger den til punkt og prikke, ender op med en webshop inkl. godkendt betalingsside(server), er "PHP And MySQL, from novice to professional".
En anden løsning er efterkrav only, eller bankoverførsel. I dette tilfælde kræver det blot en informationsside. Du kan jo holde dig ajour med det hele ved hjælp af en database og informationerne i sessions, kan gemme de præcise beløb og kundeoplysninger.
Okay ja. Tak for en super god kommentar kkrasmussen. Kan godt se at der lige kan være nogle problemer mht. til det der med én varer og to kunder. - Men alligevel virker det som om det er den mest overkommmelige del af det. Kan ikke se hvorfor jeg ikke skulle kunne finde ud af denne del kan man sige.
Fik også lige snakket med en ven om at jeg- som i også sagde "bare" kunne benytte mig af en af f.eks.: oscommerce. Hvor han havde været en 6 uger om at opbygge en hjemmeside igennem, som nu, næsten var klar til brug. Men igen, på den måde lærer man jo ikke 100% selv hvordan man gør.. Men som han siger, så er det næsten også umuligt selv og lave en webshop som bare funktions- og sikkerhedsmæssigt, og specielt det sidst nævnte som bare er 10 procent så godt som det system de har fået udviklet..
Ja okay, men hvis man skal lave en ordenlig webshop, går det ikke at man kun kan levere med efterkrav, kan man sige. Så skal jo det andet igennem lige meget hvad..
Derudover tror jeg nu godt at man kunne ordne det der problem med hensyn til 2 kunder der ønsker 1 produkt. Man kunne jo bare lave et form for "optaget". Så lige så snart en kunde har langt produktet i kurven er det pågældende produkt optaget. Hvis handler så ikke går igennem, fristilles dette produkt igen, efter x antal tid..
hvis du kun vil køre med visa- eller mastercard, kan du gå uden om pbs og bruge fx. Paypal. Man kan få en løsning der så folk betaler med fx. visakort gennem deres side og indsat på din konto.
Ellers synes jeg ikke at pbs' krav er super strikse. Hvis du benytter en allerede godkendt betalingsgateway er kravene fx at din adresse står på siden samt at dankortlogoet er synligt. Det er til at overkomme :)
Personligt bryder jeg mig ikke så meget om det der Paypal..! Så den løsning vil jeg self helst undgå..
Med en allerede godkendt betalingsgateway, mener du sådan et system som oscommerce. Eller hvad? Men ja, det vil jeg da give dig ret i. Det virker ikke særligt krævende..
mange af dem giver guidede eksempler, og jeg ved at man hos nogle kan vælge flere forskellige muligheder afhængigt at hvor man man selv kan programmere eller man gerne vil redirectes til deres side.
Men det koster abonnement. Tilgengæld billigere oprettelse hos pbs.
Man programmere selv hele siden, med lagerstying, varerfremvisning, varerudplukning via session f.eks. alt lige ind til at folk har valgt deres produkter de ønsker at købe.
Og her kommer deres modul så ind i billede, og skal kun sørge for selve betalingen. Som så kan foregå via deres hjemmeside, eller ens egen, hvis man kan finde ud af at integerer det i ens side..?
Hvis det er tilfældet, så er det jo mest den løsning som jeg er ude efter kan man sige.
Ja sådan vil jeg mene det skal forstås. Du kan evt. læse videre om deres tekniske krav de de respektive sider der hoster gateways.
Jeg tror, hvilket at du ikke må hænge mig op på, at man kan ansøge om at blive godkendt hos pbs som gateway og dermed selv programmere ALT. Det koster vist nok bare en del mere i oprettelse og abonnement. Samt hosting af SSL mm..
Husk du skal have en betalingsløsning hos PBS hvis du vil bruge dankort på din side, om du så selv har en betalingsgateway eller bruger en anden løsning.
Okay ja. Og er der nogle som ved hvad sådan nogle priser nogenlunde koster? Altså hvad det koster at blive godkendt hos PBS? Og er det et engangsbeløb eller en månedligydelse?
Okay ja, men kan man så ikke bare nøjes med at benytte sig af betalingsløsningen hos PBS? Eller hvad er forskellen?
Jeg mener det koster 1000+moms for dankort alene, hvilket er en årlig ydelse. Og mener det er det samme i oprettelse. Dette er et særskilt abonnement. Så skal du abonnere på en betalingsløsning ud over det også, hvilket pbs også kan levere. Tror dog ikke på at de er billigst, men ved det ikke :/
Men jeg vil tro du kan læse mere om det på deres hjemmeside..
Okay ja, var lige inde og læse lidt om det. Det ser jo super ud kan man sige :o)
Så kunne jeg jo som sådan bare nøjet med sådan et betalingsmodul fra PBS for 1000 kr pr. år. og så integerer det i min hjemmeside ik.
Okay, ved godt at jeg stiller lidt de sammen spørgsmål flere gange. Men det er bare for at få det helt på det rette.
Nu kan jeg f.eks. bare begynde og programmere selve hjemmesiden med følgende funktioner:
- selve siden (Hvor man kan se varerne) - admin del (hvor man kan indsætte varer i ens net butik) - Så skal jeg lave så man kan kigge på varerne og smide dem i en kurv - og så lave en knap der hedder f.eks. "gå til kassen". - Lave en funktion hvor folk enten kan logge ind på siden, hvis de har handler i butikken før, eller oprette en ny bruger. - når dette er sket skal de trykke f.eks. "gå til betaling". - og her overfører jeg så prisen til PBS betalingsmodul. Som er integeret på min side. - Når kunden så har indtastet oplysningerne ind. og tyrkker f.eks. "aflyst". - Så sørger jeg for at der bliver lavet en fakturer til kunden. samt bliver sendt en mail f.eks. til mig selv om at der er kommet end ordre?
Mht PBS, så er omkostningerne fordelt på to dele: 1) Oprettelse (250,-) + årsabonnement (1.000,-). Oprettelsen er et engangsbeløb, mens abonnementet betales hvert år. 2) Løbende omkostninger: Leje af betaligsgateway (typisk et fast månedsbeløb) + omkostninger pr. transaktion
Med hensyn til udviklingen af din shop, så har du lavet en "tjekliste" ovenfor som i princippet ser fornuftig ud. Vær dog opmærksom på, at du skal tænke fleksibilitet ind i løsningen, så du forholdsvis nemt kan ændre din shops navigation / håndtering, hvis du mener at det kan give flere kroner i kassen :-) Eksempelvis kan det være at du bygger det sådan at når en kunde smider en vare i kurven, så er han fortsat på samme vare-side. Pludselig finder du ud af, at det faktisk giver flere ordrer, hvis kunden automatisk ryger til "vis-indkøbskurv-og-start-bestillings-flow" siden hver gang han lægger en vare i kurven. I det tilfælde er det vigtigt, at du nemt kan ændre bestillingsproceduren... Hvis du sælger varer, hvor du forventer at der typisk kun sælges en vare pr. ordre, f.eks. hvis du sælger espressomaskiner..., så kan du ligeså godt sende brugeren videre til bestillingsflowet med det samme, for han skal nok kun have en :-) Sælger du derimod tøj, kan det være at kunden skal have vist dit udvalg af bælter, når han nu lige har smidt et par nye jeans i varekurven... Dette er kun to scenarier, og der er mange.
For hvert ekstra klik kunden skal igennem, vil du miste kunder og hvis kunderne selv skal finde din gå-til-kassen knap, så mister du også kunder. Tro mig - folk er dummere end man tror... (Og det skal den super-gode designer/udvikler have forståelse for). Vurder derfor hvad der passer bedst til din forretning => byg fleksibelt, så du altid kan ændre det og tænk i brugervenlighed og forventning til handlestruktur, og byg så systemet efter det.
alex15 >> Den specielt højt begavede designer ved naturligvis, han er bedre begavet end de fleste af sine brugere. Langt de fleste af de designere, jeg har kendt og arbejdet sammen med, har dog været ganske almindelig begavet.
Deres begavelse har tilgengæld rakt rigeligt til at afholde dem fra vildfarne forestillinger om deres brugere, som værende 'dummere end man tror' - og til at vide, at præcis den holdning er designerens sikre vejviser til Arbejdsformidlingen.
Naturligvis skal du have respekt for dine brugere og deres intelligens - og undlade at tillægge dig den slags 'højrumpede' selvopfattelser! At undervurdere - og/eller tale ned til - dine brugere er noget af det værste, du kan gøre
Lad mig præcisere udtalelsen: Når jeg siger at folk er dummere end man tror, så taler jeg ikke om at folk er uintelligente, og taler ikke om dem som "personer" - og det er slet ikke en udtalelse om at man skal være højrøvet.
Istedet taler jeg om brugere som individer, der skal finde ud af at navigere rundt på websitet - og det er ofte noget af det sværeste for en designer, der ofte blot vil have at designet ser super godt ud. Design er ikke kun den grafiske fremstilling, men også måden der navigeres rundt på, så det er intuitivt og let forståeligt. Et godt design tager højde for alle aspekter og ikke kun det grafiske. Folk ved ikke nødvendigvis at man skal klikke på logoet for at komme til forsiden (som det er tilfældet på mange websider), de ved ikke nødvendigvis at 'Videre' betyder 'Her kan du begynde bestillingsflowet og gennemføre bestillingen af din vare'.
Eksempler: http://www.gouda.dk/ - prøv at bestille en rejseforsikring herinde (afbryd før du gennemfører :-)) Tæl antallet af klik, men læg i høj grad mærke til hvad det er for nogle spørgsmål og hvor mange der er i forbindelse med et bestillingsforløb - forhindringer for ende til anden, hvor man tvinger brugeren til at tage stilling til en hulens masse, som man ikke fatter noget som helst af - man vil bare gerne have en rejseforsikring. Når du har gjort det, så tjek http://www.europaeiske.dk/ og sammenlign - hvem tror du der har de bedste konverteringsrater?
Min personlige holdning er at det grafiske design på Gouda er langt federe end det på Europæiske, men jeg ville til enhver tid købe hos Europæiske for det kan jeg finde ud af. Og er det ikke for at få handlen i hus, at vi laver webshops?
Jeg håber jeg har forklaret pointen, så jeg ikke fremstår som det arrogante røvhul jeg ikke er eller nogensinde ønsker at være, men istedet som en der blot beder folk der vil drive professionel virksomhed om at overveje, hvordan deres website skal indrettes, så man hjælper brugerne og sig selv :-) Til alles gavn.
Så er det vel API versionen som jeg ønsker at benytte mig af, er det ikke korrekt? Mener jeg ønsker ikke at kunden skal forlade min side for at betale for varen. Personligt synes jeg det har været noget underligt noget de gange jeg selv har været udsat for det. Og dernæst er det jo ikke modul'et som jeg ønsker at benytte mig af. Da jeg selv vil stå for programmeringen af selve web shoppen.
Men hvor svært at det at integerer et sådan system til ens webshop. Umildbart havde jeg forestillet mig at man bare købte sig adgang til deres koder med en månedlig ydelse. Og så kunne man nærmest bare tage og kopirer følgende "boks" ind i ens betalings vidue:
Mht API'et, så er jeg lidt rusten i det, for det er efterhånden et godt stykke tid siden jeg rigtig har arbejdet med det, men hvis du er nogenlunde programmør, så er det ikke en stor opgave. Det kræver selvfølgelig at din shop kan producere de data, der skal bruges til gatewayen :-) Og så kan jeg huske at jeg brugte lang tid på at fifle med at ordrenummeret SKAL være 4-cifret. En detalje jeg ikke først havde lagt mærke til... Det kostede nogle timer.
Du skal have en indløsningsaftale med PBS, og hvis der kommunikeres korrekt med din betalingsgateway, så sker det hele automatisk. Du skal typisk (alt efter hvad du sælger) selv ind og gennemføre transaktionerne manuelt i Quickpay, da du først må trække beløbet når varen er afsendt til kunden. Sælger du eksempelvis fildownloads, hvor kunden får filerne med det samme, så kan du muligvis godt trække med det samme og derved undgå den manuelle proces - tjek selv lige reglerne herfor hos PBS.
Du har vel lige husket, at hvis du vil bruge API modellen så skal din forbindelse til serveren være krypteret. Så skal du lige ud og købe et certifikat, samt have mulighed for ssl på serveren. Uden ssl kryptering så kan du ikke have noget som helst betalingssystem på siden. Det er også af samme grund at flere sider vælger at guide brugeren over på betalinggatewayen, hvor der er ssl kryptering, for at indtaste kortnumre og bekræfte købet.
Ja, det er korrekt. Arbejder ikke rigtig med betalingsløsninger og shop mere, men er der i øvrigt ikke også noget med at der netop er kommet nye regler fra PBS?
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
