It's simpler and many orders of magnitude more efficient to ask the DB
to aggregate the customer balance based on their orders. It removes
a nasty N+1.
The resulting SQL query is:
```sql
SELECT customers.*, SUM(spree_orders.total - spree_orders.payment_total) AS balance
FROM "customers"
INNER JOIN "spree_orders"
ON "spree_orders"."customer_id" = "customers"."id"
WHERE "customers"."enterprise_id" = 1
AND (completed_at IS NOT NULL)
AND (state != 'canceled')
GROUP BY customers.id
ORDER BY email;
```
I'm not sure why this spec started failing. Fixes:
```
Spree::OrdersController viewing cart when an item is in the cart the page provides the right registration path
Failure/Error: expect(subject.registration_path).to eq registration_path
ActionController::UrlGenerationError:
No route matches {:action=>"index", :controller=>"registration"}
# ./spec/controllers/spree/orders_controller_spec.rb:140:in `block (5 levels) in <top (required)>'
```
DEPRECATION WARNING: `#deliver` is deprecated and will be removed in Rails 5. Use `#deliver_now` to deliver immediately or `#deliver_later` to deliver through Active Job.
Sometimes the objects are not paginated. In this case we need to avoid trying to render pagination data, as it will throw an error. This guard clause also means we can remove messy conditionals from several controllers.
For some reason the process is now working correctly, the authorization step succeeds and a redirect link is stored in the payment with state pending. The payment state is correctly left at pending. Here we add a check for the redirect path sent by stripe and fail the authorization if there is one (it means the payment would need an extra auth step only available in the frontoffice now and probably through email to customer at some point in the future). For some reason the flash with the authorization failure message is not showing up for the user
