2 ms·

> test in staging as much as it is useful, and then go live with an immediate test built into the deployment toolchain, with automatic rollback in case of failu

> test in staging as much as it is useful, and then go live with an immediate test built into the deployment toolchain, with automatic rollback in case of failure for any reason I'm curious about the logistics of automatically testing payments after a deployment? Does your automated test place an order with a valid, working credit card? Does your test include going through 3D Secure too? Do you then automatically cancel the order? How do you make sure that whole unusual process doesn't get blocked by unusual activity fraud detection? Whose credit card is it? Have broken tests ever lead to the test order getting fulfilled?

madaxe_again 2y ago
> Does your automated test place an order with a valid, working credit card? Yep. Organisation owned card for the purpose, details used by selenium for the test. Details stored securely, I might add, as PCI/DSS and ISO27k1 were important to us. > Does your test include going through 3D Secure too? Yeah. Same bank card always being used meant we could automate the flow. > Do you then automatically cancel the order? It went through the whole despatch process, including label production with couriers etc., and was then cancelled as that tests everything including CANCEL/VOID and the whole critical flow. > How do you make sure that whole unusual process doesn't get blocked by unusual activity fraud detection? By using the same card over and over, placing an order for a normal item, talking to our bank when it did occasionally get flagged. > Whose credit card is it? The businesses. > Have broken tests ever lead to the test order getting fulfilled? Yup. We had a few that appeared on our doorstep, both due to our error, and client error.