Aidan Today at 1:25 PM Let's say you have a website where you can pay for something with a credit card, and people are using this website from their phones, but their internet connections keep dropping out, so the users are left in an ambiguous state where they don't know if their order has been processed or not... what strategies can be used to resolve this problem?
23 replies parndt 15 minutes ago as a user this is the worst parndt 14 minutes ago I usually check my email straight away to see if I got a confirmation Aidan 14 minutes ago I'm thinking one-time use tokens embedded in the form, to prevent multiple submissions, and that token can also be used by the front end to re-request the status of the order (and the status may be "huh? never heard of it") Aidan 13 minutes ago (if JS is enabled) Aidan 12 minutes ago There must be standard well-tested solutions to this problem? jstr 12 minutes ago sounds like an idempotency token like concept jstr 12 minutes ago Stripe do that jstr 11 minutes ago You could do receipt emails and automated follow ups for abandoned sales, if your primary interest is capturing the sale terrcin 10 minutes ago doesn't rails already do the token embedded in the form thing?? terrcin 10 minutes ago maybe I am thinking of something else Aidan 10 minutes ago csrf terrcin 9 minutes ago ah yup, that's probably what i'm thinking of terrcin 8 minutes ago regardless of the client with the dodgy connection you should do something to prevent against double submits. I've experienced things like Nginx resending a request if the first attempt failed parndt 8 minutes ago those aren't really for idempotence are they? (edited) terrcin 7 minutes ago or you structure your endpoint to handle being submitted to heaps of times Aidan 6 minutes ago when sending a payment request to a payment gateway, you usually have to provide a unique id with which to reference the request. Then if the connections drops you can re-attempt and the gateway will reject it if it has seen it before (edited) Aidan 5 minutes ago (The payment gateway will typically also give the transaction their own unique ID) (edited) Aidan 5 minutes ago I think this is a strategy I could adopt, with the front-end re-attempting/requesting order status, using a unique ID (edited) Aidan 2 minutes ago But the unique ID would have to be generated by the back-end, and I'd have to verify that the id hadn't been modified during the round-trip to the user (edited) terrcin 1 minute ago have the id being JWT, that way you get tamper protection for free :+1: 1
psdavey 1 minute ago I admit I’ve not thought about this deeply, but, as regards unique ids and not being modified (and server generated) could you lean on https://github.com/rails/globalid :+1: 1
Aidan < 1 minute ago tbf, I could just stash valid IDs in the user's server-side session jstr < 1 minute ago Here’s Stripe’s strategy https://stripe.com/blog/idempotency
Page created on 6 Jun 2020