3 ms·

So ruby isn't a primary language form me, but doesn't the tx.save in the rescue block cause a retry? Also the 500ms poll looks like it is coming from the clien

• zrail 13y ago
  The `save!` in the rescue block is just to save off the error message from Stripe, since retrying after a Stripe-level error isn't possible because the token that you get from `stripe.js` is one-time-use and is consumed as soon as Stripe sees you make an API call. SuckerPunch won't actually retry the job. In this simple example the backgrounding mechanism is mostly for insulating you from the browser's timeout.
• micaeked 13y ago
  Not quite. `txn.save!` just writes the data to the database. The call to do the actual processing happens earlier, on the line beginning with `charge = Stripe::Charge.create(`. RE the poll: I tend to do doubling polls for stuff like this (500ms, 1s, 2s, 4s, 8s, etc), but in this case I don't think it matters, since all the server does is one database lookup and render as json. Side note to OP: It seems like a bad idea to use the auto-incremented id as a key for polling, since it would allow an attacker to get full details of all transactions.
  • zrail 13y ago
    Yep, you're right. The book[1] has a much more fleshed out version of this example that uses a random guid as the key, plus a whole lot more. [1]: https://www.petekeen.net/mastering-modern-payments https://www.petekeen.net/mastering-modern-payments
  • optimiz3 13y ago
    Got it, thanks!