Payment Service Provider: Check the Service Boundaries

A payment service provider helps a business accept payments, but its label alone does not identify every service or legal role.

For a cross-border merchant, identify who signs the agreement and which services it covers. Processing handles payment instructions; card acquiring is the merchant-side card-acceptance arrangement. Then confirm payment methods, settlement terms and operating responsibilities. A service bundle does not make every merchant contract identical.

Source: Stripe, “Payment service providers explained” (commercial service categories; not a universal legal or aggregated-account definition); accessed 2026-10-20.

• This guide is for the payment owner preparing a shortlist or reviewing an existing provider. It explains what to ask for, what the answer proves, and where to go deeper. It does not rank providers or certify regulatory status.

What is a payment service provider?

In commercial payments, a payment service provider (PSP) helps businesses accept electronic payments. The service may combine checkout, processing connections, payment methods, reporting and other tools. Read the specific product scope before assuming each function is included.

The term also has jurisdiction-specific legal meanings. In the United Kingdom (UK), the Financial Conduct Authority’s Handbook definition covers several categories, including payment institutions, credit institutions and electronic-money issuers. That legal definition is broader than a single aggregated merchant-account model.

Source: the same commercial publisher, “Payment service providers explained” [1a]; Financial Conduct Authority, “Payment service provider: Handbook definition” (commercial explainer versus explicitly UK regulatory terminology); accessed 2026-10-20.

• Do not use “PSP” as evidence that a company holds a particular authorization in the United States (US), UK or another market. Verify the named legal entity and permissions relevant to the services and jurisdictions you need.

What a PSP does — and what you still need to verify

Source: the same commercial publisher, “Payment service providers explained” [1a] (service categories; evidence-request column is an original procurement method); accessed 2026-10-20.

Treat an incomplete row as an open question. “Global,” “all-in-one” and “one integration” can describe a useful product, but they do not replace a written availability matrix or an agreement.

PSP vs gateway, processor, acquirer and merchant account

Source: the same commercial publisher, “Payment processor vs payment gateway” [1b]; Mastercard, “Find a payment facilitator” (card-role distinctions; a broad PSP label does not establish the PayFac relationship); accessed 2026-10-20.

PSP vs your own merchant account

Ask whether the offered service uses an aggregated or submerchant arrangement, works alongside a dedicated merchant account, or relies on a direct acquiring relationship. Record the actual answer and agreement. Do not turn a common industry example into a definition that every PSP must follow.

The right comparison is the offered arrangement. Ask whether your business is a direct merchant or submerchant, which agreements apply, and who supplies the acquiring function. A single dashboard, rapid signup or one invoice does not answer those questions.

Onboarding convenience does not prove that underwriting, business verification or ongoing monitoring disappears. Compare the information and responsibilities for the exact service; do not assume every route requires the same process.

Source: the commercial explainer’s publisher, “Payment service providers explained” [1a]; the same card scheme, “Find a payment facilitator” [2] (different service/account arrangements; no promise of no-underwriting onboarding). Both accessed 20 October 2026.

Build a shortlist around routes, not a global logo list

Write down your merchant legal entity, customer market, payment method and receiving bank. Record presentment currency (the currency charged to the customer) and settlement currency (the currency the merchant receives) separately. Then ask each candidate to confirm that exact row. This prevents a country-coverage claim from being mistaken for merchant eligibility.

The table is a selection method, not a statement that any particular provider supports every combination. It is useful for a one-market merchant too: start with the route you need now, then record expansion routes separately.

Four-stage procurement workflow for checking a payment service provider. The checklist is not a provider score or regulatory approval.

The service-boundary worksheet

Use one worksheet per merchant entity and payment route. Give each provider the same questions, then require a document reference and operating owner for each answer. Keep unsupported answers unresolved instead of treating a polished demonstration as contract evidence.

Download the provider service-boundary worksheet. Start with the contracting-identity rows, then add roles, funds, terms and retained responsibilities. Use document/page labels, not customer records or account credentials.

Compare the operating job in two public customer stories

A marketplace paying sellers and a software business collecting invoices need different operating handoffs. Public customer stories help identify those handoffs. They do not prove that a provider’s entire catalogue, commercial terms or legal arrangement applies to your account.

Look beyond the marketplace buyer’s checkout

The marketplace case below describes payment, onboarding and payout risk. It includes seller-verification and bank-account-verification work. The useful procurement question is who owns seller activation and payout exceptions, alongside payment acceptance. This historical provider account does not establish the marketplace’s current configuration or availability of the same services in every jurisdiction.

Source: Adyen, “How eBay reduces fraud and risk with a global payment partner” [5a], 9 November 2022; accessed 20 October 2026. Vendor marketplace report, not an independent audit or universal merchant-onboarding model.

Follow the invoice as well as the payment

The software customer in the story below used the provider’s payment and invoicing products to automate invoice creation and match incoming payments with invoices. The account describes failed-payment communications in the subscription lifecycle. This example separates collecting money, maintaining the invoice and controlling product access. It does not supply your subscription policy, support agreement or a guaranteed improvement in authorisation or conversion.

Source: Stripe, “Slack customer story” [1c], publication date not displayed; accessed 20 October 2026. Vendor account of that implementation; reported performance percentages are not used here.

Check three handoffs in the actual product documentation

Sources: the marketplace provider, Verification process [5b] and Settlement details report [5c]; the invoicing provider, Using webhooks with subscriptions [1d]. Current provider-specific documents, accessed 20 October 2026; examples to map, not requirements for every PSP.

Turn the comparison into a bounded request

Pick the journey closest to your business. Ask who owns each handoff, what evidence supports it and which exception path stays with your team. Use the service-boundary worksheet to compare that answer with the offered agreement; a customer story cannot supply your contractual scope.

Both stories are vendor-published third-party accounts, not this publisher’s customer cases, tests or partnership evidence. This comparison makes no provider ranking or independently audited performance claim.

Security and compliance are shared responsibilities

A PSP can operate payment-security services, but outsourcing does not remove the merchant’s responsibility to ensure account data is protected. Confirm the provider’s relevant Payment Card Industry Data Security Standard (PCI DSS) validation. Document written responsibilities and the tasks that remain in your environment.

Source: PCI Security Standards Council, “Outsourced processing and merchant responsibilities” (merchant responsibilities after outsourced processing; validation scope must be confirmed for the actual integration); accessed 2026-10-20.

Do not accept “PCI handled for you” as a complete answer. Ask which services the validation covers and who maintains the merchant’s integration, website and ongoing compliance evidence. Your actual obligations should be confirmed through the relevant compliance-accepting parties.

When one PSP is not enough — and when it is

Keep one provider when the verified service meets the current routes and operating requirements. Adding a second provider introduces another integration, reporting stream and support boundary. More connections do not automatically improve approval rates or resilience.

• A new market needs a payment method or merchant arrangement the current provider cannot confirm.
• Finance cannot obtain the reporting or settlement detail required for its reconciliation process.
• The business needs an exit or portability option the current agreement does not provide.
• The team has a specific, tested resilience requirement and can operate the additional complexity.

Each is a reason to investigate, not a conclusion that the provider must be replaced. For a provider comparison, continue to the international payment gateway guide. For the operating data, use the reconciliation guide.

Prepare a provider review without guessing the service boundary

A useful proposal review joins one merchant entity, one route and the documents governing them. Begin with the service-boundary worksheet. Record a reference, responsible party and unresolved condition for each row. Two entities may perform several roles; the sheet must show the actual arrangement rather than infer it from a brand or dashboard.

Collect the records in this order

1. Identity and offered route. Fill Merchant entity, Contracting counterparty and Merchant eligibility from the proposed agreement and written scope. Keep the brand separate from the legal signer. Record the product, country, method and business model being assessed.
2. Service roles and account model. Identify the checkout/gateway, processing or instruction-handling owner, acquiring arrangement and merchant-account relationship. For a bank-only route, ask the provider to document which card-specific fields do not apply. A quick signup does not determine whether the merchant is direct or a submerchant.
3. Funds, currencies and terms. Distinguish who handles funds from who owes or remits merchant settlement. Attach timing, fee, hold/reserve and receiving-bank terms. Record presentment currency—the customer-facing transaction currency—and settlement currency separately. If they differ, request the conversion scope and terms instead of assuming an exchange rate or saving.
4. Optional claims. If a facilitator relationship, regulatory permission or price is claimed, reference the entity, service, jurisdiction or quote that supports it. Leave an unclaimed optional service marked not applicable only when the offered scope supports that answer. A marketing description does not fill a missing agreement.
5. Retained work and exit. Name the owners of security, refunds, disputes, reporting, incidents and support. Ask finance to trace a payment into the settlement/payout report. Record how services or data can be moved or terminated under the agreement; a single integration does not establish an exit right.

Sources: the commercial explainer’s publisher, “Payment service providers explained” [1a] and “Payment processor vs payment gateway” [1b] (service roles); the cited card scheme, “Find a payment facilitator” [2] (its acquirer-registration relationship). Financial Conduct Authority, “Payment service provider” [4] (UK terminology), and PCI Security Standards Council, “Outsourced processing and merchant responsibilities” [3] (retained merchant duties). Accessed 20 October 2026. The record sequence is an original procurement method, not verified contract, licensing or compliance results.

Turn an incomplete answer into a specific follow-up

Use the Unresolved condition column to write the missing fact, next owner and affected decision. “Need more information” is too broad. “Finance needs the payment-to-payout reference map before accepting the reporting sample” gives the provider an answerable request.

Source: Original editorial synthetic examples, prepared 20 October 2026. No real merchant, provider test, reviewed contract or payment outcome is represented.

A completed sheet means the requested answers and references are present. It does not authenticate them, establish a license, validate a price or approve a merchant. Send the same version to the responsible provider, finance, security and professional reviewers. Preserve their answers and remaining conditions with the agreement.

Use the worksheet for the next provider conversation

To assess the publisher’s checkout or card-acquiring services, bring the route and service-boundary worksheet to a payments discussion. Confirm entity eligibility, current availability and commercial terms before treating a proposed setup as supported.

Sources and verification scope

This comparison is published by HaiPay, a payment-services vendor. It compares payment roles and procurement questions, not tested provider performance. Contract terms and market rules determine the actual arrangement. This is operational guidance, not legal or investment advice.

1. Stripe —
   • Payment service providers explained [1a]. Commercial service categories; aggregation is an example, not a universal legal definition. Accessed 20 October 2026.
   • Payment processor vs payment gateway [1b]. Message flow and issuer decision, not a performance comparison. Accessed 20 October 2026.
   • Slack customer story [1c]. Vendor account of software billing, not merchant-specific contract proof. Publication date not displayed; accessed 20 October 2026 Coordinated Universal Time (UTC).
   • Using webhooks with subscriptions [1d]. Selected paid-invoice/active access condition, not a universal access policy. Publication date not displayed; accessed 20 October 2026 UTC.
2. Mastercard — Find a payment facilitator. Acquirer-registration definition for this scheme; no other scheme’s contractual liability is inferred. Accessed 20 October 2026.
3. PCI Security Standards Council — Outsourced processing and merchant responsibilities. Merchant responsibilities continue after outsourcing; confirm validation scope for the actual setup. Accessed 20 October 2026.
4. Financial Conduct Authority — Payment service provider: Handbook definition. UK regulatory terminology only, not a statement about a US vendor’s legal status. Accessed 20 October 2026.
5. Adyen —
   • How eBay reduces fraud and risk with a global payment partner [5a]. Published 9 November 2022; accessed 20 October 2026 UTC. Historical marketplace account, not current rollout or product availability.
   • Verification process [5b]. Current platform integration’s capabilities, not every PSP merchant model. Publication date not displayed; accessed 20 October 2026 UTC.
   • Settlement details report [5c]. Transaction-level report fields and payout journal types; sample rows are examples. Publication date not displayed; accessed 20 October 2026 UTC.