Skip to main content

Flusso notifiche

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

       

      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

       

      Payload specifici per entità o evento

      Di seguito i riferimenti allo schema dei vari payload:

        Back to top