ComparisonBuilding in-house vs Using an orchestration layer

LILPE vs. Building Payment Infrastructure In-House

Some teams should build their own payment layer. Most underestimate what it takes to keep one running. Here's how to decide with your eyes open.

Talk to sales Side by side

The approaches

What 'building it yourself' actually means

Building in-house means your engineers integrate each payment provider and bank directly, and write the logic around them: which provider handles which payment, what happens on failure, how webhooks are verified and de-duplicated, how refunds are issued and tracked, and how everything reconciles. The first integration is the easy part; the work that lasts is maintaining several, as providers change their APIs and your business adds methods and markets.

Your businessCheckout, apps, platforms
LILPEOne API and dashboard
Routing engineRules, health, cost
ProvidersPSPs, gateways, acquirers
Payment networksCards, real-time rails, banks

Where an orchestration layer sits. Illustrative; which providers are connected for your business is confirmed during onboarding.

Side by side

How the two approaches compare

Neutral, factual differences. Neither column is better in every situation.

LILPE vs. Building Payment Infrastructure In-House: side-by-side comparison
Criteria	Building in-house	Using an orchestration layer (LILPE's approach)
Control	Total: every rule and screen is yours	Configure rules within what the layer offers
Time to first provider	Your integration project	Integrate once to the layer
Each additional provider	Another integration to build and maintain	Connected behind the same integration, where available
Routing, retries, failover	Designed, built and tested by your team	Provided by the layer, configured by you
Reconciliation across providers	Built by your team	Provided across connected providers
Ongoing maintenance	Yours: API changes, incidents, security	Shared with the layer's provider

Deciding

When each one makes sense

The costs that don't appear in the first estimate

Build estimates usually cover the integrations. The long-term costs are elsewhere.

Keeping up with provider API changes and new payment methods.
On-call engineering for payment incidents, often at the worst times.
Idempotency, webhook verification and retry safety, done correctly everywhere.
Reconciliation tooling and the finance team's time when it breaks.
Security and audit work for systems that handle payment data.

When building makes sense

Building is the right call for some businesses.

Payments are core to your product, and you have a dedicated payments engineering team.
Your routing or reconciliation needs are genuinely unusual.
Your volumes justify the ongoing investment, and you've costed it over several years, not one.

Questions to settle before deciding

Answer these with your engineering and finance leads in the room.

How many providers will we run in two years, and who maintains each integration?
Who is on call when payments fail on a sale day?
How will we reconcile across providers, and who owns it?
What would we build next if we didn't build this?

Build or use a layer?

Build when payments are your product and you can staff them properly for years. Use a layer when payments are essential but not your differentiator, and your engineers' time is better spent elsewhere. Either way, the principles (idempotency, verified notices, daily reconciliation) are the same; the developers page lists them.

FAQ

Questions about this comparison

Can we start with a layer and build later?

Yes. Keeping your own systems free of deep provider-specific assumptions makes a later move in either direction easier.

Will we lose control of routing?

You set routing rules in the layer rather than writing them in code. How much can be configured depends on the platform; ask to see it.

What does LILPE offer here?

How LILPE describes its routing, retries and reconciliation is on the platform pages; what's available for your business is confirmed during onboarding.

Guides

Guides and explainers

Plain-language answers to the questions businesses ask before and after they go live.

Deciding whether to build?

We're happy to talk it through, including when building is the better answer.

Talk to sales All comparisons