Embedded Payments for ERP Platforms
Every ERP platform has billing. Almost none execute payments.
The accounts receivable module records the invoice. It tracks the due date. It logs the customer. It drives the ageing report. When the customer eventually pays — by BACS transfer, by card on a separate portal, by a posted cheque, by a finance team manually keying a payment — the ERP records the receipt and reconciles. It does not, in most platforms, initiate or capture the payment itself.
That gap is the single biggest unmonetised surface in the ERP business model. Customers want one system that runs their finance operations end-to-end. They settle for a system that records and reports while a separate set of tools — PSPs, gateways, payment portals, e-mandates, treasury workflows — handles the actual money movement.
This guide is for ERP platforms — from horizontal mid-market suites to vertical-specific ERPs in commerce, manufacturing, distribution and field service — and how to close that gap by adding embedded payment execution without becoming a payments company.
Why ERP Platforms Don't Execute Payments
The reasons are structural, the same ones that keep most B2B platforms out of payment execution.
PCI compliance. The moment an ERP touches card data, PCI DSS applies. For a platform that handles general ledger entries, inventory, manufacturing routings, project accounting and customer master data, taking on PCI scope means new audit cycles, new security controls, and a security posture that the rest of the product roadmap doesn't justify.
Customers won't switch their PSP. A mid-market manufacturer using Adyen for B2B card collection won't switch to your gateway because your ERP only supports it. A distributor using Worldpay won't migrate either. ERP customers expect the platform to fit into their existing finance stack — including the processor relationships their treasury team has already negotiated.
Payments aren't the engineering priority. ERP roadmaps are bottomless. Inventory enhancements, multi-entity consolidation, manufacturing planning, project costing, statutory tax reporting in fifteen jurisdictions — the backlog is structural. Building a multi-PSP, multi-channel payment infrastructure inside the ERP would consume engineering capacity that's already over-allocated.
Liability. Carrying funds — even briefly — is a regulated activity. ERPs that briefly held customer money would need money-transmission or e-money licences in the jurisdictions they operate. Most ERP vendors don't want that liability profile.
The result: the ERP records the obligation. The customer pays through a separate channel. The platform sits at the centre of the finance operation but doesn't touch the moment of payment.
What "Embedded Payments" Looks Like Inside an ERP
There's a difference between an ERP that has a "Pay" button and an ERP that has embedded payments.
A "Pay" button routes the customer to a third-party portal. The user leaves the ERP. The transaction completes in someone else's branded checkout. The ERP gets a webhook back (sometimes) and reconciles. The customer's perception is that the ERP is a billing front-end and a separate site handles payment.
Embedded payments mean the payment execution happens inside the ERP workflow. The customer never leaves. The invoice email contains a pay-now flow that completes in the same UI. The AR clerk processing an invoice can take the payment in the ERP. The customer portal exposes the same payment surface inside the ERP brand. Reconciliation isn't a webhook-and-pray flow; it's a native field on the invoice record.
For ERP platforms with a self-service customer portal (most modern mid-market and SMB ERPs), embedded payments transform the portal from a billing-statement viewer into a billing-and-payment workspace. That's where the customer experience competitive advantage lives.
The Four AR Workflows That Embed Cleanly
When ERP vendors add embedded payments, four workflows tend to absorb most of the volume.
**1. Invoice email pay-now.** The standard outbound invoice email — generated by the ERP — carries a hosted payment link that opens to a Shuttle-hosted payment page branded for the ERP customer (the merchant, not the ERP itself). The customer pays card or account-to-account. The payment lands back on the invoice record in real-time. See invoice payment links and the B2B pay-now invoice pattern for the deeper mechanics.
2. Customer portal one-click pay. The customer-facing portal shows outstanding invoices. A pay-now control on each invoice — or a "pay all" control on the AR ledger — initiates payment inside the portal. Card-on-file, BACS direct debit and SEPA mandate options are surfaced based on what the customer's account has authorised.
3. AR clerk-assisted payment. The clerk taking a customer call (or processing a manual payment instruction) initiates the payment from inside the ERP invoice screen. For card payments, the customer is sent a payment link or completes through Voice Checkout if the call centre is integrated. No card data ever lands in the ERP — but the clerk's workflow is single-screen.
4. Recurring AR and direct debit mandates. For subscription and recurring B2B billing — common in SaaS, telecoms, utilities and managed services on top of ERP — the ERP captures the mandate once and Shuttle executes on the schedule. Failed payments retry automatically; dunning surfaces back into the ERP's AR module.
These four cover most of what a customer means when they ask the ERP vendor to "support payments natively." Across these flows, the ERP platform is the system of record. Shuttle is the payment execution layer.
Multi-PSP Without the Integration Burden
The structural reason ERP platforms have stayed away from embedded payments is the multi-PSP requirement. Every ERP customer has its own processor relationship. The platform can't dictate which.
Shuttle solves the multi-PSP problem at the architecture layer. Customers connect their existing PSP — Stripe, Adyen, Worldpay, Chase, Elavon, Braintree, GoCardless, Checkout.com, and 40+ others — and Shuttle routes transactions to the right processor for the right customer. The ERP integrates once. Each customer's transactions flow through their own processor relationship with their own merchant pricing, their own settlement schedule, and their own statement.
That changes the economics for the ERP vendor. Instead of building thirty processor integrations (and maintaining them through every API version bump for the next decade), the vendor integrates Shuttle once and the multi-PSP coverage is inherent.
For the deeper architecture discussion, see PSP-neutral vs single-PSP architecture and enterprise PSP mandates.
The Revenue Model
Payment execution isn't just a feature — it's a revenue line for the ERP vendor.
When invoices, recurring billing and customer-portal payments flow through the platform's embedded payment layer, the platform participates in the transaction economics. Revenue share on volume processed, without taking on processor liability and without becoming a money-transmission entity.
For an ERP processing materially-sized B2B payment volume across its customer base, the embedded payment revenue can rival or exceed module subscription revenue within a few years. For vertical ERPs in commerce, distribution and field service — where transaction volume per customer is high — the impact is meaningful from quarter one.
See How Platforms Monetise Payments Without PSP Lock-In for the model in depth.
Vertical ERP Patterns
Commerce ERPs (JTL, Actindo, distribution suites). High invoice volume, mix of B2B and B2C payment patterns, multi-currency, marketplace and channel-driven order flow. Embedded payments slot into customer portals and inbound order acknowledgements.
Manufacturing and project ERPs. Project-based invoicing, milestone payments, retention and stage payments. Embedded payments handle scheduled invoicing and mid-project disbursements. Recurring services billed alongside one-off project work in the same payment flow.
**Field service ERPs.** Service-call-driven invoicing, often with mobile-engineer card-present capture at the customer site, plus follow-up payment links for outstanding balances. See field service payment collection for the field-side pattern.
**Open-source / extensible ERPs (Frappe / ERPNext, Odoo-style).** Multi-tenant deployments by implementation partners, with payment configuration per tenant. Implementation partners earn on transaction volume the same way CCaaS implementation partners do — embedded payments become a recurring revenue stream for the partner ecosystem, not just the ERP vendor.
Vertical-specific finance ERPs (Rillet and similar). Accounting-led ERPs where the invoice and the GL entry are the primary objects. Embedded payments turn the platform from an accounting record into an end-to-end AR workflow.
Build vs Integrate
The build-vs-integrate decision for ERP platform payments comes down to the same two questions every B2B platform faces.
1. Can you justify the engineering investment? Building multi-PSP payment execution — with PCI compliance, multi-currency, card and account-to-account methods, mandate management for recurring billing, and per-customer routing — requires 12 to 18 months of dedicated development and significant ongoing compliance investment. That's engineering capacity diverted from the modules your customers are actually buying.
2. Can you justify the ongoing operational overhead? Every PSP integration requires version management, certification renewals, monitoring and incident response. Multiply by the number of acquirer relationships your customer base demands. Add PCI audit cycles and statutory compliance reporting in each jurisdiction. The operational cost compounds annually.
The alternative: integrate once with The Payment Layer. 40+ PSPs supported. Embedded checkout, payment links, voice and recurring direct debit. PCI handled. New customer PSPs onboard in days, not engineering cycles. The ERP ships embedded payments without building payment infrastructure.
For the broader build-vs-integrate framework, see Build vs Buy: Payment Infrastructure for Platforms.
Related Reading
Embedded Payments Without Becoming a PayFac — why most platforms shouldn't own the payment relationship
Invoice Payment Links — the canonical pattern for invoice-led payment flows
Pay-Now Buttons on B2B Invoices — the buyer-side experience
Get Payments Off Your Roadmap — the engineering-leadership argument
PSP-Neutral vs Single-PSP Architecture — when PSP flexibility matters
How Platforms Monetise Payments Without PSP Lock-In — the platform revenue model
Enterprise PSP Mandates: Why Customers Need Multiple Gateways — the constraint that drives PSP-neutral architecture
Payment Layer Explained: Gateway vs Orchestrator vs PayFac vs Payment Layer — the category framework
*Shuttle is The Payment Layer for ERP platforms. One integration. Any customer's PSP. Embedded checkout, invoice links, AR portals, recurring direct debit and voice — branded for each customer. PCI DSS Level 1, ISO 27001, and SOC 2 certified. See how it works for platforms or book a discovery call.*