Maintaining Business Continuity During Reviews

Maintaining Business Continuity During a PSP Compliance Review

A payment-provider review creates two separate jobs for a merchant.

The first is obvious: answer the provider’s questions accurately and resolve the compliance or underwriting issue.

The second is easier to neglect: keep the business functioning while that review is happening.

Payments may continue normally. Certain account changes may be restricted. Settlement may be unaffected—or liquidity may become a concern if payouts slow. Refunds still need to reach customers. Subscriptions may continue billing. Chargebacks still require responses. Finance still has to reconcile transactions. Customer support still needs to know what to say.

That is why business continuity during a PSP review should be treated as an operational discipline, not merely a document-submission exercise.

A review also does not automatically mean account suspension or termination. A payment service provider (PSP) may simply be updating merchant information, investigating unusual activity, performing ongoing underwriting, or satisfying an acquiring, network, regulatory, or internal risk requirement. The practical goal is to determine exactly what is happening, centralize the response, and identify which parts of the payment operation could be affected if the review becomes more restrictive.

Why PSP reviews can happen after onboarding

Merchant underwriting does not necessarily end when the payment account is activated.

Card-network standards illustrate why ongoing monitoring exists. Visa’s current acquirer-risk standards require monitoring for changes and anomalies in merchant activity, including transaction velocity, sales-volume changes, authorization spikes, cross-border discrepancies, average transaction amounts, disputes, products or services sold, and delivery methods. Acquirers are expected to compare recent activity against a baseline of normal merchant behavior.

Mastercard’s February 2026 merchant-security rules similarly require periodic ongoing reviews capable of detecting changes in transaction volume, refunds, fraudulent transactions, average ticket size, chargebacks, and activity inconsistent with the merchant’s business model.

Those requirements apply to acquirers rather than establishing one universal merchant-review procedure. A particular PSP’s process may also reflect its acquiring partners, regulatory obligations, merchant agreement, payment methods, geography, and internal risk appetite.

But the operational implication for merchants is straightforward:

Payment approval establishes a relationship. It does not freeze the merchant’s risk profile permanently at the day of onboarding.

What can happen during a PSP compliance review?

The first continuity decision is to identify the actual status of the account.

These outcomes should not be treated as synonyms.

Status

What it generally means operationally

Information request / compliance review

Provider needs information or is reassessing the merchant; payments may continue

Enhanced underwriting

Additional risk or business-model analysis is occurring

Processing restriction

Some payment functionality may be limited

Payout delay or reserve

Processing may continue while settlement timing or available funds changes

Account suspension

Some or all processing/account functionality is temporarily restricted

Termination / provider exit

Provider intends to end or has ended the relationship subject to applicable contractual arrangements

During a review, do not assume the worst outcome before establishing what the provider has actually communicated.

Likewise, do not assume that processing continuing today guarantees that nothing else can change.

Continuity planning sits between those two mistakes.

Step 1: Put one person in charge of the review

A PSP review should have one accountable internal owner.

That person does not need to personally create every document. They need to own the response process.

The owner should coordinate:

Provider request

→ internal question owner

→ evidence collection

→ quality check

→ submission

→ provider follow-up

→ resolution tracking

Without central ownership, a PSP can receive:

•one revenue forecast from finance;

•a different number from sales;

•one description of the product from compliance;

•another from product;

•inconsistent customer geographies;

•outdated corporate documents;

•different explanations for the same transaction spike.

Those inconsistencies can create more questions than the original review.

A useful internal rule is:

Many teams may supply evidence. One person should control the answer.

Step 2: Read the PSP request literally before building a data room

Merchants sometimes respond to a narrow question with dozens of unrelated documents.

That can slow the review rather than help it.

Translate every provider request into a simple tracker:

PSP request

What it is asking

Internal owner

Evidence

Status

Explain transaction-volume increase

Why payment behavior changed

Payments / commercial

Forecast, campaign, sales data

Open

Updated company document

Confirm entity information

Legal

Current registry document

Ready

Refund information

Understand customer/financial exposure

Finance

Refund metrics + policy

Ready

Fulfillment evidence

Confirm goods/services are delivered

Operations

Delivery/use records

Open

This prevents two common failures:

Missing the actual question

and

submitting information that does not answer it.

If the request is ambiguous, the merchant can seek clarification through the provider’s normal support or account-management route rather than guessing.

Step 3: Make every answer internally consistent

Accuracy matters. Consistency matters almost as much.

Before submission, compare new information against what the provider may already have:

•legal entity;

•ownership;

•websites;

•products;

•business model;

•customer countries;

•pricing;

•transaction volumes;

•average ticket value;

•refund policy;

•fulfillment model;

•subscription model.

If something has changed, explain the change rather than trying to make the new information resemble the old profile.

For example:

Previous underwriting: immediate digital delivery.

Current model: physical preorder product added in July with approximately 45-day fulfillment.

Reason for change: new product line.

Current volume: 18% of monthly transactions.

Supporting evidence: product page, supplier agreement, fulfillment workflow.

That is more useful than allowing the PSP to discover that the website and original merchant profile no longer match.

Step 4: Explain unusual transaction activity as a timeline

One of the most valuable things a merchant can do during review is turn unusual payment data into an understandable business event.

Suppose transaction volume suddenly triples.

A weak explanation is:

“Sales increased because the business is doing well.”

A better internal structure is:

Normal baseline

→ $400,000 monthly processing

Change date

→ August 5

Commercial event

→ new product launch + paid campaign

Observed activity

→ $1.1 million forecast for August

Customer mix

→ largely existing U.S./UK customer base

Average transaction value

→ $52 → $74

Fulfillment

→ unchanged, immediate digital delivery

Refund/dispute behavior

→ current observed level and whether materially different from baseline

That explanation helps the reviewer distinguish a business event from an unexplained anomaly.

Visa’s current standards explicitly contemplate monitoring merchant activity against a normal baseline and detecting sudden or unexpected changes.

The merchant’s task is not to defeat that monitoring.

It is to provide the commercial context the transaction data cannot provide by itself.

Step 5: Keep a complete review record

Create one central review file or workspace containing:

•original PSP request;

•exact submission dates;

•documents supplied;

•document versions;

•written explanations;

•provider responses;

•outstanding questions;

•deadlines supplied by the provider;

•internal decisions;

•account-status changes;

•escalation contacts.

This serves several purposes.

It reduces contradictory submissions.

It prevents teams from resending obsolete documents.

It gives management a reliable status view.

And if the review continues over several rounds, it preserves the sequence of what the provider asked and what the merchant answered.

Do not rely on individual employee inboxes as the only record of a payment-account review.

Step 6: Run a payment-continuity impact assessment in parallel

The compliance owner should handle the review.

The business should simultaneously determine:

What actually breaks if the PSP changes something tomorrow?

Map the dependencies separately.

Payment acceptance

Ask:

•Is processing currently functioning?

•Which countries and payment methods depend on this PSP?

•What share of payment volume goes through it?

•Are alternative routes already approved?

•Can routing be changed technically?

Settlement and liquidity

Ask:

•What payouts are expected?

•Which operating expenses depend on that cash?

•How much liquidity exists if settlement is delayed?

•Are refunds funded from the PSP balance, merchant bank account, or another mechanism?

•Are supplier/vendor obligations due during the review?

Refunds

Ask:

•Can refunds still be initiated?

•Which team owns them?

•Is there enough available balance or cash?

•What happens to open refunds if functionality changes?

Chargebacks and disputes

Ask:

•Are existing response deadlines still being monitored?

•Who owns dispute submissions?

•Is supporting evidence accessible?

•Will a processing change affect access to the PSP dashboard?

Subscriptions

Ask:

•Which recurring customers depend on this provider?

•Where are stored credentials or provider tokens held?

•Would an alternative processor actually be able to use them?

•What happens to renewals during an interruption?

Customer service

Ask:

•Is there any customer-facing impact today?

•Which symptoms would trigger a support update?

•What information can support agents accurately communicate?

The review and continuity workstreams should run together.

Example: documentation request during peak sales

Consider a merchant in the middle of its highest-volume sales month.

The PSP requests updated corporate documents and an explanation for the recent volume increase.

Processing and payouts remain operational, but the provider temporarily restricts certain account changes.

The wrong response would be to treat this as either:

“nothing is wrong because payments still work”

or

“the PSP is closing us, activate every emergency plan immediately.”

A more disciplined response looks like this:

Compliance owner

Coordinates document submission and explanation of the transaction spike.

Payments

Confirms authorization and processing remain normal.

Finance

Monitors settlement and calculates liquidity exposure if payout timing changes.

Customer operations

Keeps refunds and dispute handling functioning.

Product/engineering

Avoids unnecessary payment-stack changes during the review and confirms contingency routing readiness.

Executive owner

Receives concise status updates and approves escalation decisions if operating conditions change.

The business is simultaneously cooperating with the review and preparing for a different outcome without assuming that outcome will occur.

Step 7: Assess settlement risk before it becomes a cash-flow emergency

A company can continue accepting payments while its financial position deteriorates if settlement changes.

That makes the question:

“Can customers still pay?”

insufficient.

Finance should also model:

cash currently available

•expected settlement

− refund obligations

− supplier/vendor payments

− payroll and operating expenses

− other near-term obligations

Then model a delay scenario.

For example:

Scenario

PSP settlement

Operational question

Normal

Normal cadence

Business as usual

Short delay

Several expected payouts shift

Can operating cash absorb it?

Extended constraint

Material settlement unavailable

Which obligations become critical?

Do not assume a review will create settlement delays.

The purpose is to know the answer before liquidity becomes urgent.

For a deeper treatment of why providers may hold settlement, use Why Payment Providers Freeze Funds rather than expanding this article into a reserve guide.

Step 8: Know whether your “backup PSP” is actually usable

There is a substantial difference between:

“We have spoken with another processor.”

and:

“We have an approved, contracted, integrated, tested route that can process the relevant transactions.”

A genuine contingency route may require:

Commercial readiness

Provider relationship and required agreements are active.

Compliance readiness

The actual merchant entity, products, markets, and business model are approved.

Technical readiness

Integration works in production or a genuinely deployment-ready state.

Payment-method readiness

The methods customers actually use are available.

Credential readiness

Stored credentials, tokens, recurring mandates, or wallet credentials can be used under the alternative architecture where permitted.

Fraud readiness

Risk configuration has been tested rather than copied blindly from another PSP.

Settlement readiness

Bank accounts, currencies, reconciliation files, and finance processes are configured.

Operational readiness

Refunds, chargebacks, support, reporting, and access controls work.

Until those questions are answered, the backup is a prospective provider, not a continuity route.

Token portability is often the hidden dependency

Recurring merchants should pay particular attention here.

A business might have an alternative processor fully integrated but discover during an emergency that the primary PSP controls the payment tokens used for recurring customers.

Whether payment credentials can be migrated or reused depends on factors including:

•provider architecture;

•vault ownership;

•token type;

•network-token arrangements;

•PCI responsibilities;

•contractual terms;

•customer consent where relevant;

•technical migration capabilities.

Do not assume:

provider token A → provider token B

is a simple database export.

A continuity design should identify credential portability long before a provider review.

Detailed migration mechanics belong in PSP Exit and Payment Migration Planning.

Step 9: Define the trigger for contingency routing

Do not reroute payment traffic merely because a review exists.

Likewise, do not wait until all processing has stopped before deciding what the company would do.

Create pre-agreed decision triggers.

For example:

Account condition

Possible operational response

Review only; processing and payouts normal

Continue monitoring; no routing change

Account changes restricted

Freeze unnecessary payment configuration changes; maintain contingency readiness

Material authorization disruption

Evaluate approved alternative routing

One region/method constrained

Consider targeted contingency route if available

Settlement delay begins

Activate finance liquidity plan

Formal provider exit notified

Begin migration program

Full processing suspension

Activate ready alternatives according to incident plan

These are internal continuity examples, not universal provider rules.

The important feature is that a merchant decides how it will decide before the account is under pressure.

Step 10: Keep refunds and disputes operational

Merchants naturally focus on new revenue during disruption.

Existing customer obligations can be just as important.

During a review, maintain a separate operating queue for:

Refund requests

Ensure staff still know how and where refunds are issued.

Chargebacks

Continue meeting applicable response deadlines.

Customer complaints

Identify issues that could increase unnecessary disputes.

Fulfillment

Do not let operational uncertainty cause paid orders to go undelivered without communication.

Subscription cancellations

Continue honoring cancellation instructions and ensure future billing is stopped correctly.

This matters both for customers and for the review itself.

A merchant under scrutiny does not want an internal response failure to create a second deterioration in refunds, disputes, or customer complaints.

Step 11: Communicate with customers only when there is a customer problem

A PSP review is not automatically a public customer incident.

If customers can still:

pay

receive their product

obtain refunds

manage subscriptions

then broad customer communication may be unnecessary.

Prepare customer-facing messaging in advance if impact appears plausible, but activate it based on an actual service effect.

For example:

Payment failures increase

Support needs a clear explanation of alternative payment steps.

Refunds are delayed

Affected customers need accurate timing information based on what the merchant genuinely knows.

Subscription billing is interrupted

Customers may need to update payment details or restart service depending on the remediation path.

Avoid telling customers:

“Our PSP froze our account”

if that is not what happened.

Customer communication should describe the customer impact, not speculate about provider decision-making.

Step 12: Coordinate five operating functions

A PSP review should have a compact internal operating structure.

Function

Primary responsibility

Compliance / review owner

PSP request, evidence, communications, deadlines

Payments / product

Processing health, routing, technical contingency

Finance

Settlement, liquidity, refunds, reconciliation

Customer operations

Refunds, disputes, customer-impact monitoring

Executive owner

Material decisions, escalation, continuity activation

Legal, risk, commercial, engineering, or regional teams can be added as needed.

The aim is not to create a large incident-management bureaucracy.

It is to make sure someone owns each dependency.

What not to do during a PSP review

Several responses can make continuity worse.

Do not ignore or casually delay the request

If the provider specifies a response timeline, track it centrally.

Do not submit contradictory information

Resolve discrepancies internally before sending answers.

Do not speculate

If the company does not know why a metric changed, investigate before inventing an explanation.

Do not conceal a material change

If a new product, geography, entity, fulfillment model, or sales channel explains the activity, describe it accurately.

Do not open replacement accounts deceptively

Using inaccurate company information, disguising the business model, misclassifying transactions, or routing activity through another account to bypass a restriction creates additional compliance and contractual risk.

Do not assume a half-built integration is a backup

A contingency route is useful only if it is approved and operationally deployable.

Do not make unnecessary payment-stack changes during the review

Changing routing, descriptors, domains, entities, or checkout behavior while the provider is trying to understand the merchant can create additional unexplained signals unless those changes are genuinely required and appropriately managed.

Build a PSP Review Continuity Dashboard

For merchants with meaningful payment dependency, a simple live dashboard can make the review manageable.

Area

Current status

Risk if changed

Owner

Contingency

Card processing

Normal

Revenue impact

Payments

PSP B

Payouts

Normal

Liquidity

Finance

Cash reserve

Refunds

Normal

Complaints/disputes

Support

Manual escalation

Chargebacks

Normal

Deadline risk

Risk

Dedicated queue

Subscriptions

Normal

Renewal loss

Payments

Migration plan

Reconciliation

Normal

Finance close

Finance

Alternative reports

PSP review

3 items open

Account status

Compliance

Response tracker

This does something a compliance-document checklist does not.

It connects:

What the provider is reviewing

with:

What the business needs to keep running.

After the review: perform a continuity postmortem

Whether the review ends quickly or becomes disruptive, capture what the business learned.

Ask:

Why did the review occur?

Was it periodic, transaction-driven, business-model-driven, regulatory, or provider-specific?

What information was difficult to produce?

If processing history, fulfillment evidence, corporate documents, policies, or transaction explanations took days to assemble, improve the review-ready documentation set.

Where were the single points of failure?

Perhaps one employee held all provider correspondence.

Perhaps refunds required PSP dashboard access held by one account.

Perhaps a supposedly redundant provider could not process recurring customers.

What operating triggers were unclear?

If finance did not know when to activate liquidity measures or engineering did not know when to reroute, formalize those decisions.

What changed in the merchant profile?

Update the information used for ongoing underwriting.

This turns one compliance review into better readiness for the next one.

For broader preparation before a review begins, see Preparing for Ongoing Underwriting.

Business continuity does not mean bypassing underwriting

The purpose of payment continuity planning is not to make a merchant immune to provider decisions.

A legitimate PSP may need to review an account.

An acquirer may need to investigate unusual behavior.

A payment provider can change its commercial risk appetite.

A bank, network, regulator, or contractual requirement may create additional constraints.

Visa and Mastercard both maintain ongoing merchant-monitoring requirements for acquirers precisely because merchant activity can change after onboarding.

Continuity planning deals with a different problem:

How dependent is the business on one payment relationship, and how well can it continue serving customers while legitimate review processes are resolved?

That is an architecture and operations question as much as a compliance question.

Key takeaways

Maintaining payment continuity during a PSP review requires two parallel workstreams.

Resolve the review

Assign one owner

→ understand each request

→ collect relevant evidence

→ check consistency

→ explain unusual activity

→ submit clearly

→ maintain a complete record

Protect the business

Map processing exposure

→ monitor settlement and liquidity

→ keep refunds and disputes running

→ protect recurring billing

→ verify whether contingency routes are genuinely ready

→ define escalation triggers

→ prepare customer communication only when needed

→ coordinate internal teams

The key distinction is:

A compliance review is not automatically a payment outage—but it is the wrong time to discover that the business has never planned for one.

The strongest merchant response is therefore neither panic nor passive waiting.

It is fast, accurate cooperation with the provider combined with an already-understood operational continuity plan.

That is how ongoing compliance becomes part of payment operations rather than an emergency process invented after disruption has already begun.

🙂 🙂 🙂 🙂 🙂