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 |
active |
Memorizzazione andata a buon fine |
error |
Memorizzazione andata in errore | ||
tspay_charge |
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 | ||
| Disposizione di ordini (7) | tspay_pis |
processing |
Pagamento in corso |
active |
Pagamento eseguito | ||
failed |
Pagamento fallito | ||
| Informazione e aggregazione conti (8) | tspay_consent |
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:
- Notifiche da entità "charge": specifiche payload
- Notifiche da entità "source": specifiche payload
- Notifiche da entità "pis": specifiche payload
- Notifiche consenso: specifiche payload