Deep Dive — Partner Orchestration & Vendor Management

The partner taxonomy

"Vendor" is a sloppy word in payments. Be specific. Different partner classes do different jobs and have different risk profiles.

Senior interview habit: when asked about a partner, ask back which class. Different answers, different tradeoffs.

Vendor selection — the RFP

Selecting a partner — especially an acquirer or banking partner — is a structured process. The interview-grade outline:

1. Define scope — geos, methods, volume forecast, latency targets, integration shape.
2. Long-list (8-15) → short-list (3-5) based on coverage, scale, reputation, references.
3. RFP issued — structured questionnaire. Sections: technical, commercial, risk/compliance, operational, references.
4. Scoring matrix — weighted criteria (coverage 30%, cost 25%, reliability 20%, integration speed 15%, partnership cadence 10% — example).
5. Live technical due diligence — sandbox testing, security review, SOC 2 / ISO 27001 evidence.
6. Commercial term sheet — pricing tiers, MSF (merchant service fee) breakdown, settlement terms, MGFs (minimum guarantees).
7. Compliance/legal review — sanctions exposure, data-processing agreement, DPA, sub-processor list.
8. Award + integrate.

KYB and partner risk profile

You are KYBing your partners as much as they are KYBing you. Diligence on:

• Licensing — does the partner actually hold the license they claim? (EMI, MTL, banking license, money services).
• Sanctions exposure — beneficial owners, jurisdictional footprint.
• Financial soundness — for banking partners, deposit-insurance posture; for PSPs, runway and parentage.
• Sub-processors — your partner's downstream chain becomes your data-residency surface.
• Incident history — references, public-record outages, fines.
• Concentration risk — are they themselves over-dependent on one acquirer or one bank?

The cost stack — interchange, scheme, acquirer, FX

Every successful card txn has a stack of fees. Know each component:

For a US-issued card paying a UK merchant in USD on Visa, the stack might be ~2-3% all-in. For UPI / PIX the stack is dramatically lower — sub-50bps, sometimes free. Cost-stack literacy is a tell of seriousness.

-- Cost per successful txn, by rail, last 30 days
SELECT
  rail,
  geo,
  COUNT(*) FILTER (WHERE status='approved') AS approved,
  SUM(fee_interchange + fee_scheme + fee_xborder + fee_fx + fee_acquirer + fee_psp)
    FILTER (WHERE status='approved') AS total_cost_cents,
  ROUND(
    SUM(fee_interchange + fee_scheme + fee_xborder + fee_fx + fee_acquirer + fee_psp)
      FILTER (WHERE status='approved') / NULLIF(COUNT(*) FILTER (WHERE status='approved'), 0),
    2
  ) AS cost_per_success_cents
FROM payments
WHERE created_at >= NOW() - INTERVAL '30 days'
GROUP BY rail, geo
ORDER BY rail, geo;

Orchestration patterns — what "payment orchestration" means

Payment orchestration is the abstraction layer above your PSPs. It owns: routing, retries, vaulting, normalization, observability. There are three patterns:

For a company the company's size, build-your-own is the default, with buy on the margins for specific regions. Be ready to defend either side.

Smart routing & cascading

The two patterns interviewers reach for:

Smart routing

Route each txn to the PSP / acquirer most likely to approve at lowest cost, before first attempt. Inputs:

• BIN → guess issuer behaviour and acquirer affinity.
• MCC → some acquirers handle quasi-cash better.
• Country pair → cross-border vs domestic preference.
• Currency / amount → some PSPs have caps.
• Historical AAR for this BIN × PSP × hour.

Cascading (fail-over)

On soft decline or system failure, retry the same txn on a different PSP. Rules:

• Never cascade on hard decline (scheme violation).
• Cap retries (typically 1-2 alternates).
• Use the original issuer authentication if you have it (network token avoids re-step-up).
• Log every cascade for vendor SLA reporting.

SLAs and partner cadence

An SLA matters only if it's measurable and you reference it. Typical PSP SLAs:

• Uptime — 99.95% monthly, with credits if missed. Define at API endpoint level, not statuspage.
• Latency — p99 auth response in <800ms.
• Settlement — funds in your account within T+N.
• Support — P1 incident response in <30 minutes, 24/7.
• Roadmap commitment — quarterly business review with deliverable list.

Run monthly business reviews. Bring data: AAR by issuer, cost reconciliation deltas, incident report. Treat the partner as an extension of the team.

Multi-PSP architecture in one diagram (words)

Walk this through in a whiteboard round:

1. Client app → Payments API (your service).
2. API normalizes request → calls Routing service.
3. Routing returns ordered PSP list given BIN, MCC, geo, amount, recent history.
4. API invokes PSP adapter for the chosen PSP (translates internal model → PSP-specific).
5. PSP responds; adapter normalizes response into shared schema.
6. On soft decline / timeout, Cascade controller picks next PSP, invokes adapter again.
7. Successful auth → Vault service stores network token; Event bus publishes payment.authorized.
8. Settlement service reconciles incoming PSP reports against the auth events daily.
9. Observability layer tracks AAR per route, latency, cost, attribution.

Off-boarding a partner — when and how

When the partner is the right call:

• Material persistent AAR underperformance vs alternatives (corrected for mix).
• Repeated SLA misses without remediation.
• Compliance/sanctions exposure rising.
• Roadmap divergence — they won't ship what your portfolio needs.
• Cost no longer competitive after re-RFP.

The how is slow: parallel-run the replacement, shift traffic by % over weeks, retain the outgoing partner as cold fail-over for a quarter, then settle the contract. The senior payments PM is the person who runs this without a customer noticing.