Vad är det som är oklart? Att överhuvudtaget varna för ett företag innan man kollar fakta är fel. är det så svårt att förstå?

Lite frågor:

Vilka är "vi"?

Vad hände med detta påstående från första inlägget? Vad jag vet, också från vad jag tycker är tillförlitliga kontakter, så har storbankerna inget emot Pay&Read. Utveckla gärna...

Lustigt, när vi kör deras system så används SSL. :o

Du kallar det "varna", jag kallar det att sprida rykten. Om det nu är något svenskt (vilket jag inte tycker det är iofs...) att man inte ska sprida ogrundade rykten utan att först kolla upp dessa, så tycker jag nog det bara är ganska trevligt att vara svensk. Det är ju lite poppis för tillfället att skylla på "svenskheten" i olika sammanhang, dock...


Visste ni förresten, att om man söker på Pay & Read på Google så har företaget Samport köpt reklam med det sökordet. Företaget Samport som är konkurrent till Pay&Read, och som driver TellusPay, vilka båda av någon anledning är stora favoriter hos nicce... <_<

Och var det inte nicce som utfärdade en "varning" för något annat betalningssystem för någon tid sedan? Gällande sms-betalningar? Vad hände med det? Hm...


Menar inte detta som någon form av angrepp på nicce, vill bara föra fram lite bakgrundsinfo som kan vara bra att veta när man bedömer värdet av dessa inlägg om Pay&Read...

Ok, jag har förstått att det finns företag här som står bakom Pay&Read till fullo, vilket va lite av det som jag va ute efter när jag skrev "Om någon har mer information tas den emot tacksamt. " i första inlägget.

För att svara på Henriks frågor:

1. Vi är jag och mina kollegor som sitter här och utvecklar mot olika transaktionssystem.

2. Vi har kunder som vid uppstart ej fick använda Pay&Reads lösning med Babs, utan dem hänvisade till Debitech. Samma sak med Handelsbanken.

3. SSL skyddar ENDAST om sidan du anger kortuppgifterna på OCH serversidan som tar emot uppgifterna ligger under krypteringstekniken. Se över din lösning igen ;)

4. Ja, jag ville varna, jag ber om ursäkt för det. Jag skrev klart och tydligt i första inlägget att jag väntade mer FAKTA, men det va tydligen för känsligt ämne.

5. Jag är själv svensk och stålt över det, men det finns nog en grund i att det är poppis att skylla på svenskheten. Tycker du att det gå bra för oss? (ett helt annat ämne och forum)

6. Om du söker på Pay & Read får du upp samport. Har du provat att söka på samport, telluspay, debitech, netgiro eller paynova? Alla köper sponsrade länkar.


Det du skriver mellan raderna är att jag skulle arbeta för samport för att sprida skit om Pay & Read, det va ett bra tag sedan jag gick på dagis och hade in tänkt lägga denna diskussionen i dem nivåerna.

För tillfället är netgiro och samport stora favoriter, inget jag förnekar. Dem kompletterar varandra bra och och är ungefär lika stora. Tillsammans är dem EMEA's största betalväxel och i det finner jag en oerhörd trygghet. Dem är de enda betalväxlar i Sverige som är certifierade av VISA och MASTERCARD för AISSDP.

Att över huvud taget räkna Pay & Read som konkurenter är helt fel då dem (som jag förstår det) har någon form av plåmbokslösning i sverige. Pay & Reads konkurrenter som jag ser det är Paynova. Att bedömma min trovärdighet utifrån detta är helt..... jag hittar inte ord för det.

Du har nog inte läst mitt inlägg om SMS, där förklarar jag att det är bättre att gå direkt mot källan istället för att ta en 3:e parts lösning.

Det är självklart upp till var och en att själva bedömma Pay & Read, och jag håller med Henrik om att man åtminstone kan ta en kontakt med dem om man letar betallösning för att bilda sig en egen uppfattning. Det är inte alls min mening att smutskasta, och jag ber om ursäkt om det upplevs som det. Eftersom jag är i branschen ser jag allt som händer, ibland kanske man har lite för stora ögon.

Jag kommer i alla fall avråda från Pay & Read tills dess att dem är certifierade. Först då är motsatsen bevisad, i alla fall för mig.

Det där låter konstigt...

Det bör inte vara något säkerhetsproblem att ha ett formulär som visas via HTTP, och postas krypterat via HTTPS..

Vad menar du egentligen?

OT:
"Helt otroligt hur det svenska samhället ser på saker och ting"

I mina ögon en helt befängd kommentar, av oerhört låg nivå.
Jag brukar gnälla på denna typ av kommentarer, inget mot dig personligen.
Blir lika irriterad när folk klämmer ur sig "jantelagen" osv.

Enligt vår Trust avdelning är det endast då den publika nyckeln för SSL certifikatet blivit utdelad som säker kommunikation kan upprättas. Därför måste formuläret där känslig data hämtas först, för att nyckelutbyte skall ske. När detta är gjort skickas denna publika nyckel till informationsservern tillsammans med formulärdata. Först här blir kommunikationen krypterad.

Det är ganska enkelt att testa själv. Prova att posta data till en SSL-sida från en ICKE SSL-sida och sätt din brandvägg på fullständig loggning. Du kommer då (beroende på brandvägg, har själv testat på en WatchGuard 4500) få upp fullständiga formuläruppgifter i klartext.

Med anledning av ovanstående brukar man endast uppge okänsliga uppgifter i steg ett, ex U/P, email osv. och sedan kortnummer och annan känslig data i stegen efter.

Det som händer är:

1. Formuläret visas över HTTP. Eventuella standardvärden, hidden-inputs eller liknande man har är naturligtvis inte krypterade i detta skede.
2. Användaren matar in data, och skickar formuläret.
3. Webbläsaren ansluter via HTTPS, utbyter nycklar, och skickar datat krypterat.
4. Eventuellt svar från webbservern visas krypterat, (om den inte försöker med en redirect/refresh till en okrypterad sida naturligtvis)

Jag vet inte om du tänker fel, förklarar fel, eller fått det fel förklarat för dig. Sidan som (initialt) visar formuläret behöver inte vara krypterad, däremot så måste svaret naturligtvis skickas via HTTPS.

OM du gjort ovanstående, och den skickat ut data okrypterat så har det varit ett allvarligt säkerhetshål i din webbläsare, eller på webbsidan. Kanske något spyware? :P

Mkt intressant, jag ska genast köra lite tester. Jag har fått det förklarat såhär för mig, testet har jag dock gjort själv.

Detta är en oerhört intressant fråga. Om det är som du säger så finns det uppenbarligen en brist för detta i vissa webbläsare. Kan det vara så att alla webläsare inte hämtar den publika nyckeln vid första initieringen?

Det korta svaret är nej. Eftersom hela grejen är att den går till en annan sida som är krypterad så kan den inte skicka någon data om den inte lyckats med HTTPS-anslutningen och utbytet av nycklar.

@nicce, du är otroligt dåligt insatt i ämnet Pay&Read så jag kan bara hålla med dom övriga om att ditt första inlägg var avsett för att smutskasta ett mycker seriöst företag som Pay&Read.

Du tror ju t.o.m att Pay&Read kör ett system som är att jämföra med ett plånbokssystem ala Paynova. Jag tycker att du ska ta reda på fakta innan du vräker ur dig skit om konkurrerande företag.

Vad ditt syfte var får alla ha sin egen uppfattning om. Det är verkligen dålig stil att bygga sina (falska) fakta på att "jag har hört" och "kompisen vet" och det visar bara på hur dåligt insatt du är och har något annat syfte än att sprida riktiga fakta.

Ta reda på relevant fakta och info om systemet innan du vräker ur dig vad du "har hört".