Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Payments, refunds and processor fees from Stripe reach Infor attached to the invoice they belong to, so finance stops working out by hand what each amount was actually paying for in the first place.
A payment arriving without saying what it pays is almost as much work as no payment at all. Infor needs to know which invoice an amount settles, and Stripe knows, but only if that reference travels across with it. When it does not, the money sits in a holding account and somebody matches it up later from bank statements and order numbers. The Stripe to Infor integration carries the reference over with the amount, so payments allocate themselves, the exceptions are the handful that genuinely need a person, and the bank statement stops being where you go to find out.
DATA THAT FLOWS BETWEEN THEM
Payments
Refunds
Processor fees
Payouts
Customers
Invoice references
Each amount reaches Infor with the invoice reference attached, so it settles the right invoice on arrival instead of waiting in a holding account for somebody to work it out.
The processor's fee arrives as its own figure, so the gap between what a customer paid and what reached the bank is explained rather than investigated every month.
A refund is matched back to the original payment, so the customer's account in Infor shows what they actually owe rather than a balance somebody has to interpret first.
Because payments post as they arrive, the overdue list reflects who genuinely has not paid, and nobody chases a customer who settled up the week before last at all.
A customer pays through Stripe and Alumio posts the amount in Infor against the invoice it settles, so the account is up to date immediately and nothing waits in a holding account waiting for somebody to identify it later on.
A Stripe payout reaches the bank and the payments and fees behind it are already sitting in Infor, so the amount that landed can be tied back to the sales that produced it without anybody making a manual comparison of the two.
A refund issued in Stripe posts against the original payment in Infor, so the customer balance is right straight away rather than being adjusted at the month end at the month end by whoever happens to notice the difference first.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
A subscription billing tool is a common addition, because recurring charges have their own rhythm and neither the payment processor nor the ERP is built to manage renewals on its own. It runs through the same place as this one, on the customer matching you configured already, so a renewal, a payment and an invoice all point at the same customer.
Yes, and everything depends on the reference travelling with the amount. Alumio carries the invoice or order reference alongside each payment, so Infor can allocate it rather than parking it. Where a payment genuinely has nothing to match against, it is held and flagged instead of being posted somewhere plausible and found later.
No. Writing code is the exception in this kind of connection, not the normal way of doing it, and most of what looks technical here is a set of choices in a form: which references travel, which accounts fees post to, what happens to an amount nothing matches. The Code Transformer covers the exception when one turns up.
Whichever one your invoices actually carry, and agreeing that is most of the work. Infor allocates a payment when it can see the document being settled, so a reference that exists in the webshop but never reaches the payment is the usual reason money sits unallocated. Deciding which reference travels, and making sure it is set when the payment is taken, is what prevents that.
Money sitting in a holding account with nobody sure what it was for is the failure this prevents, and it starts with a reference that did not make the trip. Every transfer is monitored as it happens and its amount and reference recorded. Anything Infor will not allocate is escalated immediately, with the cause named, and retried where configured. No payment is quietly left unaccounted for.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
