What payment integration covers beyond the checkout
Choosing a payment gateway is a storefront decision, and the exchange it handles is one moment. The payment relationship produces data for weeks afterward, and each type has a different destination.
- Authorization and capture: the storefront confirms funds are available, then captures them, often at shipment rather than at order
- Settlement: the provider batches captured payments and deposits them, typically net of fees and on a delay
- Refunds and partial refunds: money returns against an original transaction, sometimes long after the order closed
- Chargebacks and disputes: funds are reversed with a reason code and a deadline for evidence
- Fees: per transaction, per method, and per currency, which is what separates gross from net
Only the first belongs to the storefront. The other four belong to finance, and they are the ones that arrive without a home if the payment provider connects to the checkout and nowhere else.
Why do settlements stop matching the order book?
Payment providers batch what they capture. A deposit of 48,000 EUR does not correspond to any single order in the ERP. It corresponds to several hundred captures across two days, minus fees, minus three refunds, plus one chargeback reversal from the previous month.
Multiple payment methods multiply the problem. Card payments settle on one schedule, direct debit on another, and buy-now-pay-later providers on a third, each with their own fee structure and reporting format. A business running four methods is reconciling four separate flows against one order book.
Currency adds the last layer. A payment taken in one currency and settled in another introduces a conversion the ERP did not calculate, so the amount recorded against the order and the amount received differ by an amount nobody predicted.
What weak payment integration costs
Nobody files a ticket when a settlement fails to match an order. The costs accumulate quietly instead, and they surface in this order:
- Month-end that runs long: finance matches settlements to orders by hand in a spreadsheet, and the close date depends on how many exceptions turned up
- Revenue counted late: orders sit unmatched, so reported revenue lags actual trading by however long the matching takes
- Channel profitability that is guesswork: payment fees are not attributed per order, so margin per channel and per product is an estimate
- Refunds that go out twice: when the payment system and the ERP disagree on whether a refund was processed, service issues a second one
- Disputes lost on deadline: chargeback evidence lives across the storefront, the warehouse, and the provider portal, and the window closes before someone assembles it
Payment integration across a composable stack
Businesses used to run one payment provider against one platform, and the provider's own plugin covered most of it. That arrangement is now unusual. A typical mid-market retailer runs a primary provider, a regional method for one market, an invoice or BNPL option, and a marketplace with its own payment flow.
Essentiel Antwerp is a Belgian luxury fashion brand selling across physical stores and online internationally. Using the Alumio integration platform-as-a-service (iPaaS), they built a composable stack rather than a single suite, running Microsoft Dynamics 365 Business Central for finance, Adobe Commerce for the storefront, Channable for marketing, and Adyen for payments.
The relevant point for reconciliation is what that architecture requires underneath. When payments, orders, and financial records live in three separately chosen systems, the connection between them has to be governed rather than assumed, because no vendor owns both ends of it.
How an integration platform connects payments to the ERP
Taking one deposit apart into the payments that made it up is only the first requirement. Each payment needs its fee attached and its order reference carried with it, so the ERP can record it against the right document. That work needs a layer sitting between the payment provider and the finance systems. A dedicated reconciliation tool does the matching well and still has to be fed from both ends. Provider plugins do not reach that far.
The Alumio iPaaS sits in that position, connecting the payment provider to the systems that account for the money. That work takes four forms:
- Settlements broken back down: a data Transformer splits a batched deposit into its underlying transactions and attaches each to its order reference, so the ERP receives line-level detail rather than a lump sum
- Fees attributed per order: a data Mapper attaches each transaction cost to the order that incurred it, so margin per channel is a figure rather than an estimate
- Refunds moving in one direction: a data Route carries a refund the moment it is issued, reaching both the payment provider and the ERP, so the two cannot disagree about whether it happened
- Evidence in one place: detailed Logs hold the order, fulfillment, and payment record behind a disputed transaction together, so chargeback responses meet their deadline
Those flows are configured rather than hand-built per provider, with the Code Transformer available where configuration cannot express a rule, and writing code is preferred. Adding a payment method reuses the reconciliation logic already running.
What connected payment integration delivers
The test of a payment integration is not whether checkout converts. It is whether finance can close the month without a spreadsheet, and whether anyone can state the margin on an order after fees.
Businesses that get this right stop treating payment providers as a storefront decision and start treating them as a finance one. Run through an integration platform, adding a regional payment method becomes a commercial choice rather than a reconciliation problem, which matters when entering a market where local methods decide conversion.
What the business gets back is a month-end close that does not depend on manual matching, revenue counted when it is earned rather than when it is matched, and a clear view of what each channel makes after fees.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
