Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
An authorisation taken against a Salesforce opportunity is not money yet, and the gap before it is captured is where a closed deal can quietly quietly stop being real without anybody noticing it.
An authorisation and a capture are two different things with a window between them. Salesforce marks an opportunity closed when the card is authorised, which feels like the end, and the capture happens later when the goods ship or the service starts. Authorisations expire. So a deal reported as won can become a payment that was never taken, and the first sign is a receivables query weeks afterwards from somebody who assumed the money had arrived. Connecting Salesforce and Authorize.net tracks the state rather than the moment, so a closed deal and settled money stop being treated as the same event.
DATA THAT FLOWS BETWEEN THEM
Opportunities
Authorisations
Captures
Refunds
Transaction states
Customer records
The transaction state from Authorize.net sits on the Salesforce opportunity, so a deal reported as won is distinguishable from one where the money has actually been taken.
An authorisation approaching the end of its window is visible while something can still be done about it, instead of surfacing as a failed capture after the goods have gone.
Refunds reach the opportunity they belong to, so a customer's history in Salesforce reflects what the business kept rather than everything it once happened to charge.
Alumio connects to Authorize.net through its available API, as it would any reachable system, so states move without anybody reconciling a gateway report against a pipeline.
When a payment is authorised against a Salesforce opportunity, Alumio writes the state and its date onto the record, so a rep and finance can both see that money has been reserved and not yet actually received by the business.
An authorisation that has not been captured within its window is flagged on the Salesforce opportunity, so somebody can act while re-authorising is still an option rather than a difficult conversation with the customer.
Alumio writes refunds and partial captures from Authorize.net onto the opportunity, so the figure Salesforce reports for a customer matches what the business actually ended up holding at the end, once refunds have settled.
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.
What happens to money that was promised is the question, and it leads to when it can be recognised rather than to another gateway. A revenue recognition schedule tool is the common addition, because Authorize.net says when cash arrived and Salesforce says when a deal closed, and neither says which period the revenue belongs to. Alumio holds both connections, so all three answers describe one transaction.
The transaction state is what travels, not the amount alone. Alumio reads authorisations, captures, partial captures and refunds from Authorize.net and writes each state with its date onto the matching Salesforce opportunity. Nothing is inferred from a closed stage, so a won deal and a settled payment remain two facts rather than one assumption.
No, and the shape of it is a state machine rather than a field copy. Which Authorize.net states appear on a Salesforce opportunity, and what an uncaptured authorisation nearing its window does, are settings in Alumio's interface. Where a business captures in stages against a schedule of its own, the Code Transformer expresses that rule.
When it is captured, and the trade-off is worth stating: waiting to report until capture makes the pipeline honest and makes it look slower. An Authorize.net authorisation reserves funds for a window and then expires, so a Salesforce opportunity closed on authorisation alone can represent money that was never taken. Carrying both states means a business can report on either without pretending they are the same thing.
An authorisation that expired before anybody captured it is the loss here, and it fails by doing nothing at all. Alumio monitors each transition live, records the Authorize.net state it read, alerts immediately when a state cannot be written to Salesforce, names the transaction and the reason, retries where configured, and keeps unresolved authorisations listed, so none quietly runs out of window.
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)
