- ',' or '.' can be used as decimal separator (defined in the application configuration)
- Remove thousands separator if it's detected as so (use regexp to match)
Here we were rendering an entire PDF, then passing that PDF into the job queue as an *argument* containing the entire binary of the PDF in a massive string. This means the job object itself would contain that entire PDF. That's bad queueing!
We now create the PDF *during* the job (not before it), and pass simple arguments.
Retrieve the current decimal separator used to display price (`I18n.toCurrency()`), and check if number is formatted with only if this is `,`. If so, remplace comma by point, to pass the check `!isNaN`, and format unit price
Previously we only set these part-way through deployment, so the values could be out of sync between our ENV vars and Spree::Config (which itself is a mix of both cached values and database-persisted values).
- If there is any payments, we use the last one to retrieve the payment method description
Use the first completed payment to display payment description
Completed is state = "checkout" or state = "completed"
Squash w/ "Add section at the bottom of invoice: Payment Description at Checkout"
Squash w "Add section at the bottom of invoice: Payment Description a"
Note: this is a bit like an N+1 query, but for rendering. If there are 30 enterprises, the partial file would be loaded and parsed 30 times; but if we render it as a collection it'll load the partial once and substantially improve the performance.
The state should have changed in the database if the payment was processed successfully, and the memoized version here will not know that without a reload.
If the page is reloaded after the payment has already gone through, we can skip the processing and give a non-error response; the payment is already completed and Stripe's response confirms it was successful.
When we're fetching the payment intent via PaymentIntentValidator in StripeSCA#purhcase (to capture it), we want it to fail loudly if it's not in "requires_capture" state. We're now also re-using the same PaymentIntentValidator service to check if payment processing was *successful*, in which case we need it *not* to fail loudly if the state == "succeeded", eg != "requires_capture".
