What Questions Should You Ask a Payments Vendor Before Outsourcing

Merchant payouts at xpate, a European payments platform, used to take 3 to 10 days. A new payout architecture brought that down to minutes. Few vendors can show the production work behind a result like that.

Rail orchestration, core banking, and merchant abstraction are 3 different layers of a payments stack. Here, vendor means the payments engineering partner you hire to build on one of them. Stripe and Adyen appear below as the platforms that partner integrates with.

What's the difference between a payment gateway and payment orchestration?

A payment gateway is data plumbing. It moves transaction details to a processor and returns an approval or a decline, and payment gateway development stops there. Payment orchestration operates a layer above it, routing each transaction across gateways, payment service providers (PSPs), and rails by cost, success rate, or failover rules. Years of payment gateway development don't automatically transfer into payment orchestration provider skill, though vendors pitch them interchangeably.

The full breakdown lives in the payment orchestration vs payment gateway guide. For due diligence, the practical test is narrower. Does this vendor know which layer they're building, or do they call all of it "payments" and hope nobody asks twice?

What questions expose whether a vendor has shipped rails, or just added a checkout button?

A vendor who has actually shipped payment rails answers 2 specific questions differently than one who has only wired up a checkout widget.

One is about which architectural layer they operate at. The other is about a specific rail, named on the spot, rather than a general claim of "payments experience." Rails here means schemes like SEPA and SWIFT that move the money.

Which layer are they integrating at: rail orchestration, core banking, or merchant abstraction?

In production, a vendor who says "we do payments" without naming a layer hasn't answered the question. Rail orchestration, core banking, and merchant-facing abstraction each solve a different problem. Each has its own short list of providers worth asking about.

Ask a payments engineering partner directly which row they've built against. A vendor who has shipped ISV payments, meaning payments built into a software product, names the rail or provider they integrated.

They also explain what they built on top. One who has only resold a checkout widget answers with an adjective.

What's their SEPA or SWIFT integration experience, specifically?

SEPA and SWIFT are not interchangeable proof points. SEPA Instant is a European scheme governed by the European Payments Council. SWIFT is a global messaging network with its own message format and timelines.

A vendor's SEPA Instant work says nothing about whether they've shipped a SWIFT message flow. Ask which of the two your product depends on, then check the vendor's work against that one.

xpate's real-time payout work illustrates the distinction that matters here. The platform moved merchant payouts from 3 to 10 days to minutes on an internal payout architecture. The result is a payout speed number, not a SEPA Instant rail integration, and a precise vendor says so unprompted.

Ask whether their SEPA or SWIFT work connected to a rail or sped up payouts on top of one. Both are real skills. They answer different questions on a due diligence call.

How do you evaluate a payments engineering partner beyond the generic checklist?

Evaluating a payments engineering partner runs into the same problem as any vendor checklist: most vendors can tick every box. The sharper version replaces adjectives with a concrete ask and a follow-up question. The ask is a live PSP integration built under real constraints. The follow-up checks which named infrastructure providers the vendor has worked with.

Require a named, live PSP integration

Cleeng needed a customized Adyen integration to onboard new business partners fast, against a real deadline. The team built the connector as a serverless layer on AWS Lambda. Terraform and GitHub Actions automated infrastructure and deploys.

Throttling and rate limiting protected the connector at the request level. AWS KMS and Secrets Manager handled the sensitive data. Sentry, CloudWatch, X-Ray, and Grafana covered monitoring, and the team tracked Sentry for errors in every release. The partnership has run 4 years.

The difference between shipping integrated payments solutions and reselling a checkout widget shows up in the details. This connector shipped on schedule with monitoring, security controls, and a client relationship that has outlasted the original deadline by years.

Ask a candidate vendor for a comparably specific story. It should name a platform, a real deadline, and a monitoring stack they can describe from memory. A generic "yes, we've done PSP integrations" isn't a comparable story.

Then ask which named infrastructure providers they've worked with

A provider name proves little on its own, so treat this as a follow-up to the live PSP story. Form3 and Banking Circle give API access to SEPA and SWIFT. Swan covers embedded finance, CurrencyCloud adds FX, and Incore handles digital asset flows.

Ask a candidate which of these, or a close equivalent, they've worked with in production, then ask what they built on top. Good follow-ups cover the rail or provider it connected to, who owned sandbox testing, and the time to first live transaction. Then ask who was on call after launch and what broke first.

Look for fintech-software engineering work on a vendor's own case study pages. Where the client is under NDA, ask for the same detail on a call: the layer, the provider, and the deadline.

Key insights

• Layer fit decides delivery risk. A partner strong in rail orchestration may never have touched core banking. Match the layer you need to their shipped work before comparing rates.

• A payout speed number needs context. Ask whether a fast payout time came from a named rail integration or from an internal architecture. The two answers describe different engineering, so check which one your project needs.

• Pressure shows what a certification list hides. Ask for the deadline, the scope change, and the first production incident on a PSP integration. A partner who did the work answers in detail, with names and dates, and one who only watched from the sideline stays general.

• Provider names open the conversation. Hearing Form3 or Swan is a cue to ask what the team built on top, in which layer, and when it went live.
  
  Treat the vendor conversation as a technical interview. Teams that skip it tend to learn which layer the vendor actually built only in production, after the contract is signed.