When the order changes, the money still has to make sense.
The amount a customer approved is not always the amount the operation ultimately delivers. A split shipment, a cancellation, a return or a tax adjustment can change what should be invoiced, captured or refunded. Hantera_ keeps the financial outcome connected to the order from checkout through to accounting handoff.
Original order
What changed
Financial resolution
Checkout is an authorization to begin — not a reason to stop paying attention.
An order can change long after the customer has paid. A delivery can split. An item can be cancelled before it ships. A return can be approved after the original invoice was created. A payment-provider action can happen outside the normal flow.
If invoices, payments, refunds and order changes are managed as separate stories, support cannot explain the balance and finance spends the month reconciling exceptions. Hantera_ keeps the financial facts where the operational facts already live: on the order.
What the customer sees
A charge, a refund or a credit should match the promise they were given — not a correction they have to chase.
What the operation needs
One place to see what was invoiced, what was captured, what changed and what still needs to happen.
What finance needs
A financial outcome that follows the order through delivery, return, tax and credit treatment before it reaches the accounting system.
Keep the order, the payment and the invoice in the same conversation.
Hantera_ does not ask a payment provider or accounting system to become the operating record for a changing order. It creates invoices, holds the connected payment history and carries the result of operational decisions through capture, credit, refund and accounting handoff.
Invoices from the order
Create invoices from the order lifecycle, with the connected lines, tax and delivery context needed to explain what the customer owes or is due back.
Payment activity with a history
Keep authorizations, captures, refunds and provider references attached to the payment and the order instead of hiding the story in a provider dashboard.
Capture and settlement in context
Coordinate payment capture against the order's unpaid invoices, so the decision to collect money is made with the latest operational context in view.
Credits, refunds and accounting handoff
Carry the final outcome into credits and refunds, then connect the relevant records to accounting software while it remains the system of record for vouchers.
Know what happened without asking three systems for three answers.
Payment actions do not always happen in the same place. A provider can report a capture or refund through an event. A team member can take an action in the provider's dashboard. A notification can arrive late or be missed.
Hantera_ keeps a detailed payment history on the order and lets connected payment-provider flows reconcile external activity back to that record. Support can answer the customer from the same context that operations and finance use to resolve the exception.
The refund should reflect what the customer actually bought.
The original basket may include a campaign, a bundle, shipping, tax and a mix of items that do not all follow the same return path. A correct refund cannot be guessed from the current catalogue price or assembled from disconnected exports.
Hantera_ keeps the promotion, price, tax and return context on the order so the business can calculate the right outcome, then send that outcome through the connected payment and accounting flows.
Promotions stay visible
The discount that made the original order add up is still available when only part of that order comes back.
Tax and credits follow the outcome
Tax treatment and credit context stay attached to the order instead of becoming a manual clean-up after the refund.
Recovery and payment agree
A return or claim resolution can lead to a refund, replacement, exchange or another outcome — without leaving the payment record behind.
The payment model is built to connect, not to trap you in one provider.
Hantera_ has a native payment model rather than treating a provider response as the whole payment record. That gives the platform a consistent way to hold payment state and transaction history while payment-provider apps handle provider-specific checkout, capture, refund and reconciliation work.
The same model gives teams a practical way to connect the providers they use without turning each one into a rewrite of the order-management core. Browse the payment apps in the marketplace →
The provider moves the money. The order explains why.
Show us the order that becomes difficult to settle.
Bring the split shipment, the partial return, the missed provider event or the invoice finance has to untangle. We’ll show you how Hantera_ keeps the financial outcome connected to the operation that created it.