Cash back orario delle transazioni sfalsato rispetto rispetto all' ora reale

Alcune transazioni fatte il 30 giugno sera prima di mezzanotte non sono state registrate…infatti ho notato che in generale sempre rispetto all’ ora reale in cui avviene l acquisto ,l app io le registra sfalsate di qualche ora…per questo le mie transazioni risultano fatte il primo luglio!!!ma in realtà le ho fatte il 30 alle 22 circa… purtroppo non ho gli scontrini…come posso fare

Trovare due orologi RTC che segnino la stessa ora, che siano sincronizzati è un impresa.
Per questo ritengo che la classifica con orario sarà un bagno di sangue, magari vincerà l’ultimo che ha fatto la transazione perché casualmente ha beccato il POS o Acqurer con l’orario più sballato a suo favore.

Secondo me non rimane altro che rassegnarsi.

È probabile che ci siano POS con orari non aggiornati,l’esercente non è comunque obbligato ad allineare gli orari sul dispositivo.
Per elaborare una transazione è necessario che il terminale POS sia collegato ad un cosiddetto gateway di pagamento, un sistema che comunica sia con la società che ha emesso la carta del cliente, sia con la banca destinataria della transazione.

Tale schema di trasmissione dati viene definito come modello o schema a quattro parti:

immagine

Aspettiamoci temporali perchè sono daccordo con @Margo stavolta.
La classifica basata su orario ragionandoci ha senso, del resto applicandola nella realtà i sistemi informatici di qualunque tipo hanno spesso problemi di disallineamento di orario, timezone, ora solare/legale etc etc quando va bene di pochi minuti, quando va male anche di ore.

Per cui la guerra sul 100.000 (ovvero in zona parità numerica a livello di transazioni ma giocata sull’orario) è un bel casino da risolvere.

Penso che prima di tutto vada stabilizzata la situazione individuando con precisione il numero di transazioni. Poi tra chi ha le stesse transazioni che potrà essere ipotizziamo a 787 e compreso a causa dell’orario tra il 99.100 e il 100.900, sarà molto difficile discriminare, prob si farà prima a dare il scashback a tutti questi che prevedere una guerra a colpi di orario o cercare di fixare a posteriori, cosa che vedo poco fattibile.

Ovviamente è solo una mia idea.

2 Mi Piace

E’ da diversi giorni che ho sollevato questo problema, su altro thread (Cashback - Situazione dopo quasi 5 mesi - n°1320 da Al_Pa)

Sorry ma non riesco a leggere tutto :frowning:

No problem, figurati.
Il punto importante è che hanno aggiunto quella modifica al DL, che sarebbe stata ridondante se non per gestire la casistica di un numero maggiore di 100.000 vincitori.

Praticamente tutti i soggetti coinvolti dovrebbero scambiarsi la data in formato UTC, in questo modo non hai problemi con ora legale/solare o diversi timezone dovuti a gateway stranieri oppure appoggiati su server cloud esteri.
Poi bisognerebbe entrare nel merito se l’orario viene preso dal POS oppure dal server gateway che riceve la chiamata dal POS. Questo è un altro fattore discriminante perché se viene rilevato dai POS questi devono avere assolutamente un orario corretto, viceversa se consideriamo quello del gateway potrebbe accadere che due clienti facciano una transazione e premano sul pulsante verde ed il primo che ha premuto arrivi poi sul gateway per secondo perché va sommato un tempo di connessione imponderabile dovuto alla rete di collegamento. Quindi comunque la si analizzi la faccenda dell’orario è sempre un inferno. :smiley:

Rispettando tutte le specifiche considerando quella del gateway comunque potresti avere problemi con server che non utilizzano NTP o si sincronizzano troppo blandamente; l’orario dei server non è completamente affidabile perché ci sono dei clock accelerati o rallentati che in un giorno si sfasano di diversi secondi o minuti …

Fare delle verifiche in tal senso sarebbe decisamente molti difficile per un comune mortale, quindi ai partecipanti non resta altro che “fidarsi” della classifica stilata; se uno volesse contestarla entrerebbe in un ginepraio non indifferente. :wink:

Il tempo di comunicazione dełł’intero processo è standard è i gateway di pagamento hanno per tutti dai tre o quattro secondi per chiudere o annullare la transazione.
Server che non utilizzano NTP credo non esistano nemmeno per i giochi online figuriamoci per un gateway di pagamento.

Io mi riferivo al tempo che occorre al POS per raggiungere il gateway di pagamento; può usare reti cablate o mobili, quest’ultime all’interno di certi esercenti hanno dei collegamenti “imbarazzanti”.

Condivido, ma visto che la sincronizzazione NTP non è costante, se è giornaliera tra una sincronizzazione e quella successiva il clock può sfasarsi di minuti, sia a tuo favore che a tuo sfavore. Quindi ritorniamo sempre al fatto che trovare due orologi che segnino lo stesso orario è praticamente impossibile. :wink:

NTP è un protocollo ideato proprio per la sincronizzazione degli orologio all’interno di una rete che al contrario senza avrebbe problemi di latenza come lei ha sostenuto.

Per quanto riguarda i tempi di connessione degli esercenti,credo che senza Cashback nessuno avrebbe pensato che sia ridicolo che nel 2021 ci siano commercianti con connessioni da terzo mondo tipo modem 56k

Non discuto sul protocollo in se; ma dipende sempre da quante volte un server si sincronizza. Se accade una volta al mese o alla settimana sarebbe quasi del tutto inutile; una volta al giorno è ancora insufficiente.

Prima di tirare la croce addosso all’esercente tiriamola addosso ai fornitori di servizi; sei così sicuro che TUTTI gli esercenti, nessuno escluso, siano coperti da fibra FTTH? :thinking:
Se anche tutti lo fossero non è obbligatorio che utilizzino tale tipo di collegamento visto che è più costoso di un abbonamento mobile e/o possono sfruttare uno smartphone come tethering per i collegamenti. Per quanto riguarda i Registratori Telematici non c’è nessuna prescrizione in merito, è ammissibile anche un modem analogico.
Quindi al limite sono cavoli del cliente se questo perderà alcuni secondi che lo faranno rimanere fuori al fotofinish del SCB. :rofl:

In FTTH sarà coperto il 20% del totale. Il misto fibra
/rame (FTTC) copre oltre l’80% con connessioni in media da 50 mega in download e 15 in Up a costi non oltre le 30 euro mensili.Quindi non c’è nessuna esigenza di fibra pura a 1Giga di download ma solo abituare gli esercenti a pagamenti digitali.

P.S il modem 56 k era ovviamente in senso ironico.

Io lo dicevo solo in ottica di latenza, non tanto per le prestazioni in download che sono completamente inutili.
Non si parla praticamente mai di connessioni via cavo visto che come ti dicevo non sono competitive come costi; ci sono piani mobili, con quantità dati molto contenuta che hanno costi nettamente più convenienti. Così come quando acquisti un Tom Tom o prendi un auto con connettività non paghi tu la rete dati così accade anche per i POS, il collegamento è incluso nel servizio.
Se tu sapessi quali modem vengono montati su dei device per il controllo remoto ti metteresti le mani nei capelli! :rofl:
In ottica futura, IOT, velocità e latenza non sono così fondamentali come pensi; un 56k per la mole di dati che transitano sarebbe sufficiente.

Mi dispiace contraddirla ancora,ma quello che ha scritto è totalmente inesatto la latenza si misura in ping con il server, dove si inviano e ricevono dei pacchetti dati. Le connessioni mobili per architettura hanno ping più elevati che sul fisso.
Per quanto riguarda modem,device e "controllo remoto " non ho capito il senso logico.
Infine Tom Tom che offrono connessione dati internet non ne ho mai visti,al massimo abbonamenti per aggiornamento mappe,in auto se non si dispone di Hot spot e sim dati dedicata non è possibile avere connessione internet

Alcuni acquirer non trasmettono nemmeno l’ora a PagoPA, per esempio le transazioni di Nexi non riportano alcun orario. Altri acquirer invece che trasmettono l’orario UTC e noi invece siamo UTC+2. Insomma di problemi ce ne sono…

SIAMO PROPRIO NEL RIDICOLO, infatti se ne è aperta una discussione al riguardo
Ecco come qualcosa di semplice la si faccia diventare sempre complicata!!!
<> cosa prevedibilissima in un concorso con milioni di partecipanti

Bastava scrivere: “150milioni di montepremio per i primi 100000 con annessi parimerito in coda

GIA’ SISTEMATA la questione classifica finale senza penalizzare gli inconsapevoli che per qualche minuto di differenza oraria vanno a perdere il premio (GRANDE INGIUSTIZIA)
e riducendo la gran mole di eventuali reclami prevedibili
Il premio per i 100000+ si riduceva solo di qualche euro (ininfluente)
e invece… diventa un ulteriore QUESTIONE di questo SCB
Grande incompetenza di chi preposto

Non hai compreso; mi stai dando ragione! Anche io sostenevo che non si sceglie la FTTH pur avendo latenza minore, non in ottica di prestazioni in download. Non la si sceglie per i costi che la rendono non competitiva.

Il senso logico è l’IOT; i device a controllo remoto, come anche un POS volendo, non vanno verso a connessioni fisse, vanno più verso a connessioni mobili perché più economiche e senza alcun vincolo.

L’aggiornamento delle mappe, con grossi moli di dati, lo fai collegandolo, ma i dati che ti arrivano con traffico/incidenti in tempo reale da dove arrivano secondo te?

Eh sì. Infatti è possibile che alla fine faranno più o meno così. È parte della polpetta avvelenata che Giuseppi ha lasciato a Super Mario

Con la postilla che gli annessi a paremerito li pagava maurix! :rofl:

E finora Zio Mario non l’ha proprio ingoiata, anzi, l’ha messa in frigorifero sospendo il tutto, e non è detto che a fine anno faccia qualche altro giochetto di prestigio perché nel frattempo i denari li ha deviati in altre voci di spesa, quindi prima di pagare bisognerà rimpinguare la cassa introducendo nuove tasse. :thinking: