Nye krav til sikkerhed fra PBS?

[haps]

Øv - det må du nok sige Danauktion - skriv endelig tilbage om det gik godt - og i givet fald gerne hvor og hvad du ændrede i koden. Jeg kan sagtens finde rundt i Oscommerce filerne og også noget php, men jeg er ikke ørn i "placeholders" og secure dit og dat.

[dinmc]

Hej,

Lad endelig høre fra dig hvis du finder løsning for WF betaling som virker og kan godkendes - jeg tror der er mange der vil glædes over en løsning for WF - og jeg har desværre ikke selv evner til at finde løsningen. Rettelse kan jeg lave hvis jeg får "kogebog" men jeg magter desværre ikke udvikling. Øv!

MVH
Lars

[pertho]

[dinmc]

Hej,

Jeg har spurgt hos Wannafind på løsning - og de sender mig dette link til ændringer der skal laves. Side 5 skulle fortælle om de nødvendinge ændringer - så mangler der blot en som kan omsætte det til rettelser i OScommerce dankort-modulet. Det kan jeg desværre ikke selv klare!

Link:

http://webmail.wannafind.dk/download.ph ... ach=0&sid={48AD3834A3598-48AD3834A3D65-1219311668}&tid=0&lid=4

MVH
Lars

[pertho]

[TP_9000]

På opfordring fra flere brugere, vil vi hos ePay her kommenterer de nye regler fra PBS og dette indlæg.

Nye krav fra PBS betyder at du som butik ikke må sende kritiske kreditkortoplysninger omkring dit eget system før det sendes videre til din betalingsgateway. Dette sker normalt gennem API løsninger (webservices eller lignende).

De nye krav som PBS er kommet med er defineret som:

- POST forward metoder må ikke finde sted (API løsninger).
- Den side hvor kunderne indtaster kreditkortoplysninger på skal være SSL sikret enten ved brug af eget SSL certifikat eller via et SSL certifikat udstedt af en betalingsgatway (relay-script).

ePay overholder disse krav ved at tilbyde 2 måde at integrerer sig med systemet. Den ene er en popup løsning, hvor alle kritiske oplysninger behandles på vores sikkerhedsgodkendte systemer. Den anden løsning er ved at sende data via POST direkte til ePay systemerne, der skal se fra ens egen side (eget layout). Her skal ens egen side dog være SSL sikret via eget SSL certifikat eller ved brug af ePays certifikat (relay-script).

Læs om ePay Standard Betalingsvinduet her: http://www.epay.dk/support/integration.asp?solution=1.

Læs om egen betalingsformular her (eget layout): http://www.epay.dk/support/integration.asp?solution=2.

Læs om sikring af egen betalingsformular via ePay SSL certifikat (relay-script) her: http://www.epay.dk/support/docs.asp?solution=5.

Eftersom disse godkendte teknologier benyttes til de moduler som ePay udvikler til OpenSource systemerne (osCommerce, Joomla / VirtueMart, ZenCart, Magento osv.), opfylder ePay samtlige sikkerhedskrav som PBS har.

En lille note til brugen af et eget SSL certifikat, så kræver PBS nu at hvis denne løsning vælges, skal ens hjemmeside sikkerhedsscannes en gang hvert kvartal. Dette kan dog undgås hvis vores SSL certifikat i stedet benyttes (vores relay-script). Dette certifikat får vi sikkerhedsscannet løbende jævnfør PCI reglerne, som vi er underlagt som betalingsgateway.

En anden kommentar til API løsninger (webservices) tilbyder vi hos ePay mulighed for behandling af betaling gennem webservices (hæve, slette, tilbageføre osv.). Dette er fuldt lovlig jævnfør kravene udstedt af PBS. Her sendes kritiske kreditkortoplysninger ikke over internettet men blot det unikke nummer, der hos ePay identificerer en betaling, der er oprettet via en af de 2 integrationsformer som vi hos ePay tilbyder.

Dvs. bruger du en af ePay løsninger/moduler, uden brug af egen SSL certifikat, skal du ikke foretage dig noget i forbindelse med de nye regler.

Skulle man have behov for uddybende forklaring til de nye regler fra PBS eller kommentarer til ovenstående, må I endelig kontakte os på info@epay.dk eller telefon: 9813 9040.

[Kennith]

Ja så kan vi jo se hvem der har service og ikke har, og dem der hellere vil have en discountløsning de må jo så bruge deres tid på at slås med deres udbydere. Jeg kan fortække at en betalingssøsning gennem BGsys koster jer omkring 400 mere om året. Hvor meget tid vil du bruge for at spare det? ePay er en smule dyrere men tilgengæld er de mig bekendt også de eneste der løbende udvikler deres modul selv.

[agentjensen]

spørgsmål til TP_9000 (Thomas) som jo ved en del om dette


- kører fribetaling ikke på samme måde som jeres "integrerede løsnion" - altså når man kører i samme layout.

Det forgår jo også gennem fribetalings egen ssl krypterede side - jeg tror faktisk det er meget lignede epays måde at gøre det - ikke at jeg laver en direkte sammenligning.

/mvh

Michael

[TP_9000]

[agentjensen]

Fair nok - de er jo desværre bare ikke så gode til at svarer

Mvh

Michael.

[agentjensen]

Og jeg fik sku et svar indenfor 24 timer - stort...

Her er hvad frivetaling har svaret mig anående denne tråd:

***********
Hej Michael,

Tak for info.

Vi kan ikke se, at der skulle være noget problem i forhold til FRIbetaling.
Kortinformationerne sendes jo helt udenom forretningen, direkte til FRIbetaling - så efter vores bedste overbevisning er der intet problem i vores løsning - hvis altså man følger implementationsvejledningen på vores website.

Med venlig hilsen
FRIbetaling
*********

Så håber vi den holder.

Mvh

Michael.

[Powertrading]

[smh@wannafind.dk]

Vi har udviklet en PHP5 klasse til brug sammen med Wannafind Betalingsgateway. Den ligger online i vores download sektion på Wannafind.dk - direkte link: . Med denne PHP klasse følger et eksempel, samt en lille readme til hvordan man nemmest integrerer Betalingsgatewayen.

Denne nye sikkerhedsoptimering kræver desværre ændringer for alle vores kunder, da alle input felter altid vil blive fjernet i den nye SecureProxy.

For osCommerce shops betyder det dog ikke voldsomt store ændringer. Proxy adressen skal først og fremmest ændres til den nye SecureProxy adresse. Derefter skal al JavaScript fjernes på betalingssiden og form/input felterne skal erstattes med de nye placeholders. Så burde shoppen være køreklar på den nye betalingsløsning.

Har man Flash komponenter, Frames, et søgefelt eller andre form felter på siden, skal disse også fjernes på betalingssiden.

Vi arbejder i øjeblikket på, at lave et opdateret osCommerce modul til Wannafind Betalingsgateway. Dette vil også blive lagt online i vores download sektion, så snart det er klar.

Er der spørgsmål til de nye sikkerhedsoptimeringer, besvarer vi dem naturligvis gerne på vores support telefon 70 23 55 66 eller pr. e-mail på support@wannafind.dk.

Med venlig hilsen
Wannafind.dk

[haps]

Sådan - Wannafind - opdateret Oscommerce modul - de fleste bruger vist stadig Oscommerce version 2.2ms2 - blot til orientering.

[dinmc]

Sådan Wannfind!! Først ude med tilbuddet om et opdateret modul til OS Commerce. Jeg gælder mig - sammen med mange andre!

MVH
Lars