eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankiKK Citi a PINRe: KK Citi a PIN
  • Path: news-archive.icm.edu.pl!news.rmf.pl!nf1.ipartners.pl!ipartners.pl!news.nask.pl!
    news.nask.org.pl!not-for-mail
    From: Krzysztof Halasa <k...@p...waw.pl>
    Newsgroups: pl.biznes.banki
    Subject: Re: KK Citi a PIN
    Date: Wed, 17 Mar 2010 20:00:16 +0100
    Organization: NASK - www.nask.pl
    Lines: 54
    Message-ID: <m...@i...localdomain>
    References: <hng03l$kh1$1@inews.gazeta.pl> <4b9b9990$1@news.home.net.pl>
    <hng8ea$hi3$1@inews.gazeta.pl> <hngqdd$vub$1@news.onet.pl>
    <s...@t...ceti.pl> <hni51l$f25$1@news.onet.pl>
    <s...@t...ceti.pl> <hnidk6$n3u$1@news.interia.pl>
    <s...@t...ceti.pl>
    <p...@l...org.pl>
    <s...@t...ceti.pl> <m...@i...localdomain>
    <p...@r...org> <m...@i...localdomain>
    <p...@r...org> <m...@i...localdomain>
    <p...@r...org> <m...@i...localdomain>
    <p...@r...org>
    NNTP-Posting-Host: khc.piap.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=utf-8
    Content-Transfer-Encoding: 8bit
    X-Trace: pippin.nask.net.pl 1268852417 12517 195.187.100.11 (17 Mar 2010 19:00:17
    GMT)
    X-Complaints-To: abuse ATSIGN nask.pl
    NNTP-Posting-Date: Wed, 17 Mar 2010 19:00:17 +0000 (UTC)
    Cancel-Lock: sha1:R39vvjBijMUOHoCnG207Jdrpln4=
    Xref: news-archive.icm.edu.pl pl.biznes.banki:522552
    [ ukryj nagłówki ]

    Olgierd <n...@n...problem> writes:

    > No wiesz, jeśli przewalacz posłuży się kartą w Rumunii, a klient jednak
    > się nie ruszał z domu i ma na to dowody -- choćby w postaci wykonanych w
    > tej okolicy czasowej innych transakcji -- to w zasadzie problem jest z
    > głowy (i z tej przyczyny nie ufam różnym gadżetom w rodzaju "dodatkowa
    > nalepka na telefon" -- bo można łatwiej zarzucić, że jednak się
    > rozdwoiło).

    Ale to jest moze dobry dowod w sądzie, nie w banku (jak nietrudno
    zauwazyc w praktyce - przeciez to jest wlasnie typowa sytuacja, i mimo
    tego banki takich reklamacji nie chca uwzgledniac - na Zachodzie, ktory
    podobno slynie z "praworzadnosci").

    > Mnie się wydaje, że jeśli ma być użyty czip to będzie i wola sprzedawcy
    > nie ma nic do tego. Chyba że sobie jakoś inaczej zaprogramuje
    > terminal.

    To oczywiscie zalezy od konfiguracji, ale karta chipowa moze byc uzyta
    do transakcji "klasycznej" jesli:
    - terminal nie ma czytnika chipow
    - czytnik chipow z jakiegos powodu nie dziala
    - obslugujacy terminal zrezygnowal z transakcji chipowej
    - itd.

    We wszystkich tych przypadkach zastosowanie ma "liability shift".

    > Jeśli sprzedawca przyjmie płatność dokonaną przy pomocy wykradzionego
    > (albo wygenerowanego) numeru karty? ZTCP raczej
    > pośrednik-rozliczeniowiec.

    W tych rozwazaniach to jest jedno, to sa sprawy wewnetrzne miedzy
    sprzedawca a acquirerem. Typowo odpowiada sprzedawca, pomijam kwestie
    ubezpieczenia. Szczerze mowiac, nie spotkalem sie z sytuacja, gdy za
    transakcje wykradzionym albo wygenerowanym numerem placi acquirer
    (oczywiscie on odpowiada przed wydawca - mam na mysli to, ze w efekcie
    to sprzedawca nie zatrzymuje zaplaty, a acquirer nie doklada do
    interesu).

    Inna sprawa sa transakcje, przy ktorych sprzedawca (acquirer) moze
    udowodnic dostarczenie towaru/uslugi klientowi. Ale to tak jakby nie ta
    bajka.

    >>> Ależ jak najbardziej ponosi odpowiedzialność jeśli podpis będzie
    >>> sfałszowany. Wiem, że wymaga to odeń przejścia weekendowego kursu
    >>> grafologii.
    >>
    >> Bardzo smieszne.
    >
    > To nie jest śmieszne, to jest prawdziwe.

    Z tym, ze w rownoleglej rzeczywistosci.
    --
    Krzysztof Halasa

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1