Skip to main content

Flusso

Le notifiche vengono inviate al verificarsi di determinati “eventi”.

Ogni Evento è composto da due parti: Entity e State.

L’Entity è il soggetto principale (ad esempio “tspay_pis”) mentre State si riferisce allo status dell’Entity (ad esempio “active”).

Esempi di eventi potrebbero essere quindi: 

  • tspay_charge.active
  • tspay_payout.refunded
  • tspay_registration.active

      Gli eventi previsti, con i relativi stati, sono i seguenti:

      Servizio Entità Stato Descrizione
      Mandatorio all'incasso (3) tspay_source * Memorizzazione di una sorgente di pagamento a seguito di un LinkToSave
          active Memorizzazione andata a buon fine
          error Memorizzazione andata in errore
        * Incasso a seguito LinkToPay o LinkToSave
          processing Per l'SDD, nel lasso di tempo necessario all'elaborazione del pagamento
          active
      Pagamento andato a buon fine
          done
      Il LinkToPay arriva al massimo dei pagamenti previsti
          error Pagamento andato in errore
          refunded Rimborsato
          disputed Contestato
        tspay_payout * Accredito sul conto del merchant
      Disposizione di ordini (7) tspay_pis * Pagamento
          processing Pagamento in corso
          active Pagamento eseguito
          failed Pagamento fallito
      Informazione e aggregazione conti (8) tspay_consent * Consenso
          created Consenso creato
          renewed Consenso rinnovato
          in_expiration Consenso in scadenza

       

      Payload specifici per entità o evento

      Di seguito i riferimenti allo schema dei vari payload:

      Ricezione notifiche

      Tutte le notifiche hanno il seguente schema:

      • itemUuid: company registry dell'azienda per la quale si è verificato l'evento notificato
      • entity: entità
      • state: stato
      • event: evento
      • eventTime: timestamp
      • payload: parte variabile dipendente dal tipo di evento