Jag använder bl.a. svenska Payer.se som betalningstjänst till en butik som riktar sig mot skandinaviska marknaden, och har tidigare använt t.ex. https://www.2co.com och https://www.worldpay.com för internationella butiker.
Nu är det en ny butik på gång, riktad mot USA. Skulle kunna använda Payer (och samma konto som till den svenska butiken) men deras möjlighet att folk ska kunna pröjsa via internetbank och telefonfaktura kommer att ställa till bekymmer för folk i USA. Och jag gillade aldrig https://www.2co.com (deras villkor) eller https://www.worldpay.com (världens krångligaste GUI).
Har dessutom inte haft koll på senaste tidens utveckling inom den där branschen, så jag vet inte riktigt vilka nya aktörer som kommit.
Jag har använt Payer i ett butiksprojekt och är på väg att lämna dom för Samport.
Tack för tips! Hade ingen aning om att dom ens fanns. Kollade deras webplats. Tyvärr kör dom med en grej som får mig att härskna till ordentligt och som jag anser att man bara kör med om man inte är riktigt ärlig: Dom mörkar priserna. Jag klickade runt en del, men kunde inte hitta nånstans där man fick redan på vad det kostar. (n)
Spook skrev:
Mestadels för att man inte verkar kunna ha sin egen design på betalsidan längre.
Sen att jag har lite andra funderingar kring det företaget.
Skvallra gärna lite...jag har också känt en del (men väldigt små än så länge) dåliga vibbar...
Tack för tips! Hade ingen aning om att dom ens fanns. Kollade deras webplats. Tyvärr kör dom med en grej som får mig att härskna till ordentligt och som jag anser att man bara kör med om man inte är riktigt ärlig: Dom mörkar priserna. Jag klickade runt en del, men kunde inte hitta nånstans där man fick redan på vad det kostar.
Vadå, du menar på Samport-sidan? Klicka på 'tjänster' och sen t ex på 'kortbetalning på webb' och där har du ju pdf:er med produktblad och prislistor. Jag tycker Samport verkar schysst, har inte testat det men det är ok priser och man kan sätta upp ett demokonto i två veckor där det verkar som att man kan testa det mesta.
Vad behöver man för att kunna installera API-lösningen? En egen server eller finns det något bra webbhotell som fixar sånt? Man kommer ju onekligen ner i pris ganska rejält om man väljer den lösningen framför den hostade lösningen.
Vad behöver man för att kunna installera API-lösningen? En egen server eller finns det något bra webbhotell som fixar sånt? Man kommer ju onekligen ner i pris ganska rejält om man väljer den lösningen framför den hostade lösningen.
Du måste också ha ett "inlösenavtal" med din bank. Det är inte gratis. Vill man slippa strulet med det, så är färdiga lösninga som t.ex. Payer inte alls fel.
Alltså, jag tror att du missuppfattar. "API" är kopplingen mellan en webbutik och betalningstjänsten och den ordnas av företaget som sköter betalningstjänsten (Payer eller Samport eller...). Dvs en koppling som gör att betalningstjänsten får rätt (och alla) uppgifter från din butik. Det finns egentligen inga "hostade" såna om du inte tänker på webbplatser som erbjuder kompletta butiker och där du får använda deras betalningstjänst (och därmed API).
Tänk på att om du använder API-lösningen så måste din egen sida vara säkrad med SSL (https), vilket inte alla webbhotell kan bistå med (bl.a. beroende på att SSL inte lirar ihop med virtual hosts, och därmed kräver ett eget IP)
Vad behöver man för att kunna installera API-lösningen? En egen server eller finns det något bra webbhotell som fixar sånt? Man kommer ju onekligen ner i pris ganska rejält om man väljer den lösningen framför den hostade lösningen.
1. Du behöver ha ett säkert system för att hantera kundernas kortinformation. Citat Samport: "Du som driver webbutiken samlar in kortinformationen och strukturerar betalningen. Samport auktoriserar köpet, men sedan sköts all hantering genom ditt datasystem. Detta ställer krav på säkerheten i dina system och att all korthantering följer PCI standarden." 2. Du behöver ha SSL. 3. Du behöver ha ett inlösenavtal med en bank (=fast och rörlig kostnad).
Payer är därför betydligt enklare att komma igång med. Du slipper allt ovanstående och har ingen startkostnad, men du har förstås betydlig mindre möjlighet att bestämma hur betalsidan ska se ut (du kan styra sidans/textens färger och typsnitt med css och byta ut ett par gif:ar).
Edit: Ursäkta, jag måste ha suttit med en gammal version av sidan då jag inte såg att flera svarat samma sak redan :)
Men medge att dom var liiiiite väl undanstoppade? En aning i alla fall?
Okejdå, lite gömt var det ;)
Danne V:
Det finns egentligen inga "hostade" såna om du inte tänker på webbplatser som erbjuder kompletta butiker och där du får använda deras betalningstjänst (och därmed API).
Payer är därför betydligt enklare att komma igång med. Du slipper allt ovanstående...
När jag skriver hostad lösning menar jag den som finns hos Samport, kanske funkar på samma sätt som Payer, jag vet inte:
"I den s k hostade betallösningen tar Samport över allt ansvar för transaktionen. När betalningen görs kontrolleras kortnummer och övrig information av oss och all hantering av kortinformation sker enligt gällande PCI standard. Fördelarna med en hostad lösning är att säljföretaget slippper ansvara för en server och SSL-certifikat."
Danne V: indell.se:
När jag skriver hostad lösning menar jag den som finns hos Samport, kanske funkar på samma sätt som Payer, jag vet inte:
"I den s k hostade betallösningen tar Samport över allt ansvar för transaktionen. När betalningen görs kontrolleras kortnummer och övrig information av oss och all hantering av kortinformation sker enligt gällande PCI standard. Fördelarna med en hostad lösning är att säljföretaget slippper ansvara för en server och SSL-certifikat."
Dom där företagen har generellt sett jäkligt dåliga på att kommunicera så att man fattar om man inte är expert eller har pysslat med webbutiker en hel del. (n)
Jag är absolut ingen expert jag heller, men så här har jag fattat att hela flödet är upplagt (uppifrån och ner):
Butik
|
API, alltså "gränssnittet" mellan butiken och betalningstjänsten som gör att uppgifterna från butiken hamnar rätt hos betalningsföretaget.
|
Betalningstjänsten (Payer eller Samport osv), som kollar kreditkortet, att det är OK osv. Dom tar också emot stålarna här innan dom skickas vidare
|
Inlösenfunktion med bank. Två alternativ: Antingen har betalningsföretaget redan ordnat med detta eller så får man fixa det själv. Om betalningsföretaget redan grejat det (typ Payer, 2checkout.com, osv) så kostar det lite extra. Om dom INTE har det (typ Samport? och DIBS) så grejar man det själv med nån bank, och får betala banken (eller dess dotterbolag) en slant.
|
Bankkonto. Hit kommer så småningom pengarna.
Skillnaden i behovet av SSL för egen del eller inte ligger i VAR kunden lägger in sina kreditkortsuppgifter. Om man har en butik där kunden lägger in dessa uppgifter för att SEDAN skickas via betalningsföretagets API och in i deras system, så måste butiken ha ett SSL-cert för att uppgifterna ska kunna skickas säkert. En del webbhotell har redan det. Man kan antingen dela på ett certifikat som andra på samma hotell använder, eller så kan man skaffa ett eget (kostar pengar). Nackdelen med ett delat certifikat tror jag bl.a. är att namnet på det pekar på webhotellet och inte på ens butik, vilket kan vara förvirrande för kunder.
Men om man INTE tar kundernas kreditkortsuppgifter i själva butiken, utan bara uppgifter om vad dom vill köpa osv innan dom slussas över till betalningstjänstens gränssnitt, så behövs INTE nån SSL (om man inte är extremt ängslig). Kundens kreditkortsuppgifter kommer ju in först då, där betalningstjänsten redan har SSL och andra säkerhetslösningar.
Nåt sånt....
275 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
