When a retailer takes an order today but ships it over several days, the payment side gets complicated fast. Here is how we rebuilt the Authorize.Net flow for Natures Warehouse so the card is only ever charged for what actually leaves the warehouse.
The problem: one order, many shipments, one card
Natures Warehouse sells a wide catalogue where a single sales order often cannot ship in one go. Some lines are in stock, others are on their way in, and a few need to follow later as a back order. Standard Odoo, paired with a payment gateway, wants to settle the whole order at confirmation. That creates two headaches:
- Customers get charged before they receive goods. Capturing the full amount up front, then refunding the undelivered portion, is messy, slow, and erodes trust.
- The order total keeps moving. Prices change, lines are added or removed, quantities are adjusted. A single up-front capture cannot keep up with an order that is still in motion.
What the business actually needed was the classic card model done properly: authorise the customer's card when the order is confirmed, then capture only the value of each shipment as it goes out the door, and issue an invoice to match.
What we built
We developed a custom Sale Auth Flow module on top of Odoo's Authorize.Net integration. It changes the payment lifecycle so it follows the goods, not the paperwork.
Authorise on confirmation, capture on delivery
When the order is confirmed, the customer's card (or eCheck) is authorised for the order value. No money moves yet. As each delivery is validated, we capture exactly the amount of goods in that shipment and raise a matching invoice. Ship half the order, capture half the money, invoice half the order. The customer is never charged for something still sitting on the shelf.
A payment-method choice built for the counter
Not every customer pays the same way. The confirmation flow opens a short wizard where staff choose how the order will be settled: credit card, eCheck, or a manual cheque. Credit cards are authorised first and captured on delivery; bank accounts and eCheck follow the rules the gateway allows; cheques are recorded against the order for reconciliation. One flow, three real-world payment paths.
Re-authorisation when the order changes
This was the hard part, and the part that makes the module genuinely useful. Card authorisations expire, and orders rarely stay still. If the order value goes up, if a line is added after a partial invoice, or if a shipment changes the balance owed, the system recalculates the outstanding amount and flags that a fresh authorisation is needed. Staff acknowledge the change and re-authorise in a click, so the held amount always reflects what the customer will actually owe. No silent under-charging, no expired holds discovered at capture time.
Partial deliveries and partial invoices, kept in lockstep
Because capture, invoicing, and delivery are tied together, back orders just work. A shipment goes out, its invoice is created, its portion of the card hold is captured, and the remaining balance stays authorised for the next shipment. Every payment carries a reference back to the transaction that created it, so reconciliation is clean.
The result
- Customers are charged for goods received, not goods ordered. Fewer disputes, fewer refunds, better trust.
- Cash flow matches fulfilment. Revenue is recognised shipment by shipment, in step with the invoices.
- No expired or stale authorisations. The re-authorisation logic keeps the card hold accurate as the order evolves.
- One confirmation flow for every payment type. Staff follow the same short process whether the customer pays by card, eCheck, or cheque.
If your business takes orders that ship in parts, and you want your payment gateway to behave the same way, this is exactly the kind of tailoring we do. Talk to Shadail Technology about a payment flow that follows your goods.
