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