How to compare payment providers with a practical requirements sheet

A payment-provider comparison becomes useful when it starts with business requirements rather than a league table. A small online retailer and a software platform can look at the same providers and reasonably choose different setups. This guide explains how to create a requirements sheet that separates eligibility, payment methods, integration work and daily operations without inventing a universal best provider.

OrsunPay editorial teamPublished
Editorial illustration: How to compare payment providers with a practical requirements sheet

Describe the transactions you actually need

Write down the countries where the business operates, the currencies it presents to customers and the currencies it needs for settlement. Add the sales channels, typical order values and the payment methods customers expect. Separate current requirements from possible future expansion. A retailer selling in one market should not let a speculative global launch obscure a missing method required today. Include the legal entity that will hold the provider account, but keep sensitive onboarding documents outside the comparison sheet. The aim is a clear operational brief, not a duplicate identity-verification system.

Provider connections

Treat eligibility as a separate decision

Before spending time on interface details, establish whether the provider can assess the business and proposed activity. Public documentation describes products; it does not approve an individual merchant account. Record who will confirm eligibility, which questions remain open and whether the planned payment methods need additional configuration. Avoid presenting the absence of a rejection as approval. If two providers remain under review, keep both scenarios in the plan until the commercial and account requirements are clear. This prevents a polished integration from becoming dependent on an unconfirmed account.

Merchant cabinet

Compare the complete operational cost

Request the terms relevant to your actual transaction mix instead of comparing an isolated advertised rate. Consider the operations you will use, currency handling, reporting needs and the work required from your team. Keep provider charges distinct from any orchestration software fee. A spreadsheet can model hypothetical baskets, but label assumptions and avoid describing the result as a guaranteed saving. The most informative comparison often identifies which contractual questions must be answered before a meaningful calculation is possible. A lower headline figure cannot compensate for an unsupported essential workflow.

Examine the integration and event model

Read how each provider creates a payment, exposes its status and notifies your application. Stripe and Mollie publish payment integration documentation, but the details of their objects and workflows are not interchangeable. Ask developers to describe how the integration handles an interrupted customer journey, a delayed notification and an uncertain API response. A common API can reduce some integration differences, yet your team still needs to understand the supported provider-specific boundaries. Include authentication, test credentials, secret management and event processing in the effort estimate rather than counting only the first payment request.

  • Can the team retrieve a payment independently of the browser?
  • Is each order linked to a searchable transaction reference?
  • Who handles a failed notification endpoint?
  • Which operations require additional account permissions?

Test the support and reporting workflow

Give finance and customer-support staff a sample investigation: an order is open, the customer reports payment and the browser return is missing. Ask what records they would inspect and where they would escalate. Compare export fields, transaction references and visibility into events. Keep payment confirmation distinct from settlement, because an operational dashboard is not automatically a bank or accounting ledger. This exercise exposes practical differences that a feature checklist can miss. Record the result in the requirements sheet alongside technical findings so the final choice reflects the people who will run the system.

Decide whether orchestration addresses the real problem

If the main problem is connecting several supported accounts and standardising statuses, orchestration may be relevant. If the missing requirement is provider approval or a payment method unavailable to the account, a software layer cannot be assumed to solve it. OrsunPay connects supported PSP accounts while merchants retain their contracts and direct settlement arrangements. Its software fee is separate. Select the provider arrangement and integration architecture as related but distinct decisions, then write down the chosen scope, unresolved dependencies and acceptance tests before implementation begins.

Explore OrsunPay

Talk to our team

Sources

Keep reading