Choosing a PSP? Ask to see a bad Friday and the final day

A polished demo shows a successful payment. A more revealing scene is Friday afternoon: a response is lost, a refund is unresolved and the account specialist is away. Then rehearse the day you decide to leave. These exercises expose operational dependency better than a long feature list.

Walk through a difficult trading day

Here is a hypothetical exercise. On Friday, your business receives 500 payments of €40, totalling €20,000. Some notifications arrive late that evening. On Monday, customers request refunds. Ask the candidate to show what your operator, engineer and accountant would see.

How is a transaction found if an API response was lost? How are delayed events investigated? Where does a failed payout appear? Who answers an urgent ticket outside office hours, and what information must the ticket contain? Useful answers include sample records, documented behaviour and actual escalation routes.

Create a shared test log with expected behaviour, observed behaviour, test date and unresolved questions. Cover declines, repeated requests, refunds and customers leaving the checkout page as well as successful payments. Any live pilot should be agreed with the provider and remain within the product's permitted use.

Establish business fit before discussing features

Give every candidate the same factual description: contracting entity, actual product, customer countries, currencies, average transaction size, expected volume, fulfilment times and refund process. A P2P platform should also explain who sells, who buys and whose funds it receives. “Online services” is too vague to support a useful underwriting discussion.

Request written confirmation that the proposed model is supported. Identify the entity providing each service, the contractual counterparty and the entity named on invoices. A salesperson's informal reassurance is weak evidence on which to schedule a launch.

Regulatory checks are jurisdiction-specific. In the United Kingdom, for example, the FCA advises checking the firm's identity and permission for the relevant service. A registration in one country should not be treated as evidence of permission for every activity elsewhere. Obtain local advice where the model requires it.

Ask for the cash calculation

Continue the invented Friday example. Assume €400 in processing fees, €1,000 in new reserve withholding and €600 in refunds, with no other movements. The resulting amount is €18,000. The fee rate is 2%; the reduction in immediately payable cash is 10%. These are different measures. None of the figures represents a current provider offer.

Have the provider identify the calculation base and timing for each component. Ask separately when funds become available and when payouts are sent. For the example above, request a dated schedule showing how much reaches the bank, which amounts remain held, and who investigates a missed payout.

Five requirements, each with something to inspect

Give finalists a short acceptance sheet. Put an expected artefact beside each requirement. Reconciliation needs a redacted report with usable identifiers. Error recovery needs documentation and a test result. Support needs a confirmed contact channel and escalation process. Access control needs tested roles. Exit readiness needs a described procedure and an understandable export format.

Mark answers Confirmed, Promised or Untested. A sales promise should not quietly become a technical fact because the presentation went well. If the candidate cannot demonstrate something yet, record the dependency and the point at which its absence blocks launch. This keeps the discussion moving without pretending every question is resolved.

A practical tradeoff is convenience against dependency. One service can reduce the number of interfaces operators use, but ask whether the history can be reconstructed without that interface. Multiple providers may offer choice while adding reconciliation, support routes and different state models. A second integration alone does not create a working fallback process.

Access and card data need a separate check

Ask for a payment-data responsibility matrix. PCI SSC explains that outsourcing does not remove all merchant responsibilities. A compliance logo alone cannot tell you which controls belong to your implementation.

Also test least-privilege access. Stripe recommends restricted API keys with permissions matched to the integration's needs. Ask your candidate to demonstrate its equivalent, especially the separation between reading payments and changing payout destinations. Have the people who will operate the account test their actual roles.

Rehearse the exit before signing

Take ten invented orders covering successful payments, partial refunds, an open dispute and a pending payout. Ask which records remain accessible after new sales stop, who can complete outstanding refunds and how to retrieve the movement history. Treat payment-data and token migration separately: do not assume portability without confirmation from the parties and an authorised secure process.

Then estimate the team’s work. If one exception needs three manual exports and an email reconciliation, include that in the comparison. An illustrative extra four minutes across one hundred cases adds 400 minutes of work even when the transaction rate is lower. This is a workload calculation, not a prediction about any named provider.

The decision record should name the owner of every remaining risk. Replace “We’ll sort it out after launch” with a specific condition: what still needs checking, before which operation and by whom. An unanswered question may disappear from a presentation without disappearing from the first overnight support queue. Keep the agreed evidence with the decision so a new team member can understand why the provider was selected.

Make the selection defensible

Divide requirements into mandatory conditions and preferences. An unsupported business model, unclear counterparty or inability to reconcile funds should fail the mandatory filter. A polished interface should not compensate for those gaps. Compare the remaining candidates using the same transaction mix and test cases.

The selection should end with a launch decision and its conditions: chosen candidate, confirmed constraints, unresolved questions and operations that must wait for answers. Retain the original product and geography assumptions. When they change, reassess whether the arrangement still fits.

A successful pilot and verified permissions do not guarantee that terms or restrictions will never change.