eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankinieautoryzowana tr4ansakcja kartą - jeszcze raz
Ilość wypowiedzi w tym wątku: 12

  • 11. Data: 2012-02-05 13:40:51
    Temat: Re: nieautoryzowana tr4ansakcja kartą - jeszcze raz
    Od: Kajetan Malkontowicz <k...@m...org>

    W dniu 04-02-2012 22:07, Krzysztof Halasa pisze:
    > Kajetan Malkontowicz <k...@m...org> writes:
    >
    >> Sam fakt przechowywanie CVV klientów jest niezgodne z PCI-DSS.
    >
    > A po co mieliby to robić? Przecież wystarczy pojedyncze sprawdzenie
    > CVV2, na początku. Jeśli w ogóle jest potrzebne (abonament można pewnie
    > anulować?).
    Mówimy o dwóch różnych rzeczach: zgodzie na obciążanie karty oraz o
    przechowywaniu danych wrażliwych jak CVV/CVV2.

    To pierwsze jest dość powszechnie stosowane, ale najczęściej w formie
    zlecenia stałego. Konieczne jest wystawienie upoważnienia firmie
    obciążającej kartę które trafia do Banku (Issuera) i na tej podstawie
    karta jest obciążana. Można to w każdej chwili odwołać w banku.
    Jednocześnie przy takiej formie nigdy nie podaje się kodu
    autoryzacyjnego. W standardowym formularzu jest tylko rodzaj, numer i
    data ważności karty oraz podpis właściciela-zleceniodawcy i konkrety
    tytuł opłaty, np. opłata abonamentowa itd. Stąd w ogóle nie do
    pomyślenia jest że ktoś w ten sposób umożliwia dowolne zakupy.

    To drugie ma się nijak do pierwszego i polega na każdorazowym
    autoryzowaniu obciążenia poprzez kod autoryzacyjny (CVV/CVV2)
    przechowywany w bazie danych podmiotu na rzecz którego płatność ma
    nastąpić (Merchanta) i w takiej formie jest niedopuszczalne z punktu
    widzenia PCI-DSS i wyraźnie zabronione. Konkretnie podpada to pod PCI
    PA-DSS (Payment Application).

    --
    pozdrowienia
    Kajetan
    http://www.psyniczyje.pl/ - przygarnij, choćby wirtualnie, psa


  • 12. Data: 2012-02-05 22:17:34
    Temat: Re: nieautoryzowana tr4ansakcja kartą - jeszcze raz
    Od: Krzysztof Halasa <k...@p...waw.pl>

    Kajetan Malkontowicz <k...@m...org> writes:

    >>> Sam fakt przechowywanie CVV klientów jest niezgodne z PCI-DSS.
    >>
    >> A po co mieliby to robić? Przecież wystarczy pojedyncze sprawdzenie
    >> CVV2, na początku. Jeśli w ogóle jest potrzebne (abonament można pewnie
    >> anulować?).
    > Mówimy o dwóch różnych rzeczach: zgodzie na obciążanie karty oraz o
    > przechowywaniu danych wrażliwych jak CVV/CVV2.
    >
    > To pierwsze jest dość powszechnie stosowane, ale najczęściej w formie
    > zlecenia stałego.

    W każdym razie, w formie jakiegos zlecenia, nie musi mieć np. stałej
    kwoty, terminów itp. To zresztą sprawa między sprzedawcą i kupującym.

    > Konieczne jest wystawienie upoważnienia firmie
    > obciążającej kartę które trafia do Banku (Issuera) i na tej podstawie
    > karta jest obciążana.

    Nic takiego nie trafia do wydawcy karty. Wystarczy np. telefoniczne
    upoważnienie sprzedawcy do obciążania karty. Do banku trafiają
    autoryzacje i poźniejsze obciążenia, przynajmniej jeśli nie ma kwestii
    spornych. Właściwie mogłyby to być same obciążenia.

    Tzn. technicznie rzecz biorąc sprzedawca może obciążać kartę w ogóle
    bez żadnego upoważnienia ze strony klienta (wystarczy znajomość numeru
    karty i daty ważności), ale to raczej nie jest rozsądne.

    > Można to w każdej chwili odwołać w banku.

    (Prawie) dokładnie tak samo jak każdą inną transakcję np. "internetową",
    czyli w ogólnym przypadku wcale nie musi być tak łatwo, i na pewno nie
    nazwałbym tej czynności "odwoływaniem".

    Myślisz może o "poleceniu zapłaty"? Ono nie wykorzystuje karty, ale
    faktycznie potrzebne jest tam pisemne upoważnienie przesłane do banku
    (w Polsce, bo "na świecie" niekoniecznie), oraz jest możliwość
    odwoływania (za granicą także może to różnie wyglądać).

    Przy kartach można jedynie składać reklamacje.

    > Jednocześnie przy takiej formie nigdy nie podaje się kodu
    > autoryzacyjnego.

    Często można podać CVV2 przy pierwszej transakcji, bo to jest zwykła
    transakcja "internetowa" (telefoniczna itp). Sprzedawca nie może jedynie
    przechowywać CVV2, ale po co miałby to robić? Zwłaszcza w takim
    przypadku.

    Owszem, istnieją pewne drobne różnice w przypadku reklamacji transakcji,
    w zależności od tego, czy zweryfikowano CVV2 (/CVC2) (np. w USA
    w połączeniu z AVS), ale to dotyczy fraudów "lewymi" numerami kart, i.e.
    to zupełnie inna bajka.

    > W standardowym formularzu jest tylko rodzaj, numer i
    > data ważności karty oraz podpis właściciela-zleceniodawcy i konkrety
    > tytuł opłaty, np. opłata abonamentowa itd. Stąd w ogóle nie do
    > pomyślenia jest że ktoś w ten sposób umożliwia dowolne zakupy.

    Nie znam czegoś takiego jak "standardowy formularz". To kwestia sklepu.
    Rzeczywiście, trudno sobie wyobrazić "dowolne zakupy" w taki sposób, ale
    np. periodyczne regulowanie salda różnych należności jest do zrobienia.
    Kiedyś to było bardziej powszechne (gdy nie było jeszcze direct debit -
    np. płaciło się tym rachunki za telefon itp).

    > To drugie ma się nijak do pierwszego i polega na każdorazowym
    > autoryzowaniu obciążenia poprzez kod autoryzacyjny (CVV/CVV2)

    CVV to kod umieszczony na pasku magnetycznym i jako taki nie jest
    wykorzystywany w transakcjach bez fizycznej obecności karty (i klienta).

    > przechowywany w bazie danych podmiotu na rzecz którego płatność ma
    > nastąpić (Merchanta) i w takiej formie jest niedopuszczalne z punktu
    > widzenia PCI-DSS i wyraźnie zabronione. Konkretnie podpada to pod PCI
    > PA-DSS (Payment Application).

    To oczywiście prawda, tyle że nie ma to znaczenia, bo przechowywanie
    CVV2 (jak napisałem) nie jest w takich zastosowaniach przydatne.
    --
    Krzysztof Halasa

strony : 1 . [ 2 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1