buongiorno
ho un e-commerce che si interfaccia con un sistema di pagamento bancario in cui il numero di ordine deve GIA' esistere ed essere sempre unico quando arriva al sistema. Se il pagamento va a buon fine o meno, la banca tiene traccia del numero ordine e quindi ad ogni tentativo 'brucio' l' auto_increment nella mia tabella. Questo comporta ovviamente che ad ogni tentativo di pagamento alla banca io rigeneri il num ordine... ecco come ho pensato di procedere ora:
conferma carrello
riepilogo dati acquirente e destinazione (scrivo l' ordine nel db con esito pagamento negativo e stato di 'bloccato' e metto in sessisone il progressivo)
passaggio alla banca con num ordine
se il pagamento fallisce:
torno all' e-comm e offro la possibilità di scegliere un metodo diverso o riprovare verso la banca (magari cambia carta)
in questo caso cosa faccio? beh, se mi vuoi tornare alla banca NON puoi con lo stesso numero ordine, quindi cancello il precedente e lo riscrivo nel db con le stesse condizioni di prima.
se il pagamento è completato:
cancello il carrello in sesisone e continuo regolarmente.
questo comporta quindi la 'bruciatura' di un auto increment... e non posso nemmeno presentarmi alla banca con un numero diverso da quello che registro sennò non c'è corrispondenza tra il mio backoffice e quello della banca!
sò che fiscalmente ordini che saltano il progressivo non danno assolutamente problemi, in quanto non hanno proprio una valenza fiscale gli ordini (non sono da paragonare alla fatturazione o DdT).
ma se il venditore mi fa delle pippe perchè non vede una sequenzialità degli ordini?
se il cliente dell' e-comm mi abbandona l' acquisto sul piu bello, ovvero quando ho gia scritto l'ordine?
sarebbe corretto creare una routine che elimini gli ordini con esito pagamento negativo e bloccati?
grazie a tutti per il supporto logico
Rispondi quotando
) e salvare tutto lì. Ma non mi sembra molto pulito.
