Sage Pay / Opayo ↔ Sage 200 Integration
Sage Pay / OpayoPayment gatewaySage Pay (now Opayo/Elavon) accepts card payments at order entry, settles to sales ledger, and supports card-on-file for recurring billing.
Sage Pay (now Opayo/Elavon) is the payment gateway that lives between your Sage 200 front end and the card processor. It handles the three core flows of order-to-cash: taking payments when you enter an order, moving cleared settlements into the sales ledger, and storing card details for recurring or multi-order billing. The tricky part is weaving those flows into Sage 200's order workflow: confirming payment completion links to invoice generation, reconciling card settlements with sales ledger postings, and managing card-on-file for subscription or standing order scenarios. We build the Sage-side plumbing — payment confirmation triggers, settlement → ledger reconciliation, card data handling — so you keep Sage 200 as the single source of truth for orders, invoices and cash.
Data Flows
- 1
Payment on order entry
When you enter an order in Sage 200, Sage Pay is called via the order screen to capture card details or check card-on-file. If authorized, the order status moves to 'payment confirmed' and the invoice is generated with the payment method recorded. Failed payments leave the order in 'awaiting payment' for manual follow-up.
- 2
Settlement → sales ledger reconciliation
At scheduled settlement periods (usually end-of-day), Sage Pay reports the cleared transactions to Sage 200. We reconcile each settlement batch against the Sage sales ledger postings, so any mismatch (missing settlement, duplicate posting) surfaces in a review queue rather than sitting unnoticed.
- 3
Card-on-file storage and reuse
For subscription or standing order scenarios, Sage Pay tokens store encrypted card details for future use. When the order runs again, the token auto-populates and the payment goes through without re-scanning. Expired tokens trigger a re-authentication flow and refresh.
- 4
Failure handling and retry
Declined cards, insufficient funds, or gateway timeouts are captured in Sage with a clear reason and timestamp. The order stays in 'payment pending' with a retry queue where staff can re-enter the card or try alternative payment methods. The retry count is tracked to avoid spam.
Where These Integrations Go Wrong
The failure modes we design around — most Sage Pay / Opayo ↔ Sage projects hit at least two of these.
Card-number entry has no test mode
Sage Pay's test mode runs against their sandbox endpoint; Sage 200's transaction capture uses live authorization for a reason: to catch configuration issues before go-live. The test mode is a dev screen only; don't build production logic around it.
Settlement delays are real
Card payments can take 1-3 days to settle in Sage Pay's reporting. If you have high transaction volume, build the reconciliation as a batch job with hold periods, not real-time expectations.
Card-on-file compliance
PCI compliance is heavy for card storage. For recurring billing, partner with Sage Pay's tokenization and avoid storing raw numbers in Sage 200. The audit trail from Sage Pay covers the 'must be able to show' requirement.
Bank fees affect landed cost
Sage Pay deducts fees (0.3%-2% depending on merchant tier) before settlement. Those fees have to flow to the appropriate cost account in Sage 200, otherwise the profit model will be off.
What's Included
- Payment capture on order entry with authorization and capture
- Card-on-file tokenization with auto-populate for recurring orders
- Settlement batch reconciliation and auto-match to sales ledger
- Failure handling and retry queue for declined/timeout payments
- PCI-safe card data handling through Sage Pay tokens
- Fee accounting (payment gateway processing fees) posted to cost center
Who It's For
Sage 200 businesses that want to take card payments at order entry (one-off, subscription, standing order) but avoid the complexity of a full e-commerce platform. Covers standard Sage 200 on-premise or hosted deployments, with a note for Syspro variant.
FAQ
Is this the same integration for Syspro?
Yes — the same Opayo/Sage Pay gateway builds the Sage-side plumbing, but the development work maps to Syspro's order/payment workflow instead of Sage 200's. The data flows (payment on order, settlement, card-on-file) are identical; just the screens and Sage 200 vs Syspro touchpoints differ.
Does this handle refunds?
Refunds are a two-way thing: Sage 200 initiates a refund through Sage Pay (descriptive 'refund' or 'return' transaction) and Sage Pay returns the funds to the card with the right status. Failed refunds (insufficient balance, expired card) show up in a review queue where the sales team can re-attempt.
Can we integrate with other payment providers like Stripe later?
Absolutely — this build is an adapter pattern. The Sage 200 plumbing (payment confirmation → invoice → ledger reconciliation) is generic. Adding a new provider is just swapping out the gateway API calls; the downstream flows stay the same.
Scope Your Sage Pay / Opayo Build
Fixed quote once we know your Sage version, the flows you need and the volumes.