Cash settlement e conferme monetarie#

CertiExch non riceve né detiene il denaro. Coordina la gamba monetaria e registra soltanto istruzioni, prenotazioni, conferme e ricevute provenienti dal sistema esterno.

Modalità disponibili#

La modalità ordinaria per un’infrastruttura che non deve impartire direttamente pagamenti può essere external_confirmation/confirmation_only.

Modalità del DvP#

Il ciclo di regolamento distingue:

• orchestrated_dvp: CertiExch orchestra riserva e settlement tramite il provider configurato;
• external_confirmation: CertiExch attende una conferma qualificata di un pagamento disposto altrove;
• free_of_payment: non esiste una gamba cash nel processo CertiExch.

La modalità deve essere fissata prima dell’avvio del ciclo e coerente con il contratto dell’operazione.

Istruzione minima#

Un’istruzione cash contiene almeno:

reference_type
reference_id
payer_id
beneficiary_id
amount
currency

Il provider simulato calcola un hash canonico dell’istruzione. Se lo stesso riferimento viene riutilizzato con un payload diverso, l’operazione deve essere rigettata.

Provider simulato#

Il provider simulato mantiene:

• rapporti cash fittizi per titolare, provider e valuta;
• saldo disponibile al netto delle prenotazioni;
• istruzioni riservate;
• ricevute di settlement;
• cancellazioni.

La riserva fallisce se la provvista disponibile è insufficiente. Il settlement verifica nuovamente coerenza e disponibilità prima di spostare il saldo simulato.

Conferma esterna#

Nella modalità confirmation_only, il core non può invocare riserva, settlement, cancel o lookup. Deve ricevere una conferma proveniente dal canale concordato.

La conferma deve riportare almeno:

• provider;
• reference della transazione;
• riferimento dell’operazione CertiExch;
• pagatore e beneficiario;
• importo e valuta;
• stato finale;
• timestamp di finalità;
• identificativo o hash della ricevuta;
• autenticazione del messaggio.

Non è sufficiente caricare manualmente una frase “pagato”.

Provider HTTP#

L’adattatore HTTP richiede:

• endpoint HTTPS valido;
• bearer token senza caratteri di controllo;
• TLS peer/hostname verification;
• redirect disabilitati;
• timeout entro limiti;
• risposta JSON entro la dimensione massima;
• request ID propagato.

Endpoint previsti dal contratto di riferimento:

GET  /health
GET  /balances
GET  /balances/available
POST /reservations
POST /reservations/{reference}/settle
POST /reservations/{reference}/cancel
GET  /reservations/{reference}

L’adattatore non rende automaticamente il provider idoneo alla produzione: occorrono contratto, autenticazione forte, idempotenza, semantica degli stati e test di finalità.

Finalità separata#

CertiExch distingue:

• finalità cash;
• finalità della consegna;
• finalità complessiva.

Timeout e ricevuta tardiva#

Un timeout non dimostra che il pagamento sia fallito. Prima di riprovare:

1. interrogare il provider o il canale di conferma;
2. cercare una ricevuta tardiva;
3. verificare l’idempotency key;
4. controllare saldi o statement;
5. decidere retry, cancel o manual review.

L’invio cieco di una seconda istruzione può produrre un doppio pagamento.

Riconciliazione#

Verificare almeno:

• importo atteso e confermato;
• valuta;
• pagatore e beneficiario;
• reference univoco;
• stato finale;
• timestamp di finalità;
• ricevuta provider;
• stato della gamba titoli;
• eventuali retry o cancellazioni;
• corrispondenza fra messaggi e oggetto DvP.

Errori principali#