Stima dei costi di integrazione dei pagamenti
Come valutare un’integrazione di pagamento: ambiente di test (sandbox) e ambiente di produzione (live), rimborsi, webhook, idempotenza, ambito PCI. La discussione che deve avvenire prima che venga stabilito qualsiasi importo.
Sul biglietto c’è scritto “aggiungere Stripe”. Nel testo si parla di mezzo quarto.
I pagamenti dispongono di un’interfaccia API pubblica che può essere contenuta in una sola pagina e di un’interfaccia decisionale privata che invece non lo è. La scelta di un fornitore comporta un picco di lavoro di un giorno. L’implementazione del flusso di checkout standard richiede un paio di giorni. Tutto ciò che viene dopo (il flusso di rimborso, la politica di riprova dei webhook, le chiavi di idempotenza, il rapporto di riconciliazione che il reparto finanziario richiederà nel secondo mese) costituisce la funzionalità vera e propria, e nulla di tutto ciò è indicato nel ticket.
La “storia” che recita “integrare Stripe” è raramente quella oggetto di stima. La storia oggetto di stima è: “possiamo incassare denaro, effettuare rimborsi, dimostrare di averlo incassato e gestire un addebito contestato”. Finché il gruppo non voterà su tale ambito, la cifra non sarà altro che una stima relativa a un aspetto diverso.
Ciò che viene detto nella stanza
Backend: “La sandbox è semplice. La libreria si occupa della maggior parte del lavoro.”
SRE: “I webhook richiedono idempotenza. Qual è la nostra strategia di riprova nel caso in cui Stripe effettui una nuova consegna?”
Finanza: “Come vengono gestiti i rimborsi? E i rimborsi parziali?”
Conformità: “Stiamo trattando numeri di carte di credito o ci atteniamo al modello SAQ-A?”
PM: «Cosa dice l’e-mail relativa al pagamento non andato a buon fine e chi la redige?»
Domande da porsi prima di votare
- Inizialmente solo nell’ambiente sandbox, oppure le chiavi di produzione saranno incluse fin dal primo giorno?
- Rimborsi e rimborsi parziali: tramite interfaccia utente (UI), API o solo per gli amministratori?
- Idempotenza dei webhook e gestione dei tentativi di ripetizione: a chi appartiene la tabella di deduplicazione?
- Ambito di applicazione dello standard PCI: si rispetta il requisito SAQ-A evitando di accedere al PAN?
- Riconciliazione: chi redige il report e in base a quale fonte di riferimento?
- Esperienza utente in caso di errore: le carte rifiutate, quelle scadute e le richieste di autenticazione 3DS rientrano tutte nell’ambito di applicazione?
In casi come questo, la mossa giusta è spesso quella di suddividere la questione. “Incasso” è una voce; “rimborso” è un’altra; “riconciliazione contabile” è una terza. Considerarle come un unico elemento significa che l’integrazione viene rilasciata nella terza settimana e che il reparto finanziario chiede dove sia il report nella ottava settimana.
Si voti su “dimostrare che abbiamo incassato il denaro e superato la controversia”, non su “richiamare l’API di checkout”.
A margine: errori comuni nel Planning Poker relativi alla suddivisione delle storie in una fase troppo avanzata; tecniche di stima per attività così vaghe. Si vedano gli altri esempi di stima elaborati, oppure si avvii una sessione gratuita di Planning Poker quando il processo di raffinamento sarà pronto.