Processing History Requirements

ARTICLE START Processing History Requirements for PSP Onboarding: What Underwriters Look For Two merchants can each have processed $12 million in the previous year and still present very different payment histories. One may have tens of thousands of relatively small transactions, stable monthly volume, limited refunds, a diversified customer base, and little month-to-month variation. The other may have far fewer, higher-value transactions, pronounced seasonality, rapid recent growth, a different geographic mix, and materially different refund or dispute patterns. The annual volume is identical. The operating evidence is not. That is why processing history requirements during payment service provider (PSP) onboarding should not be understood simply as a request to prove how much money a merchant has processed. Processing history is better understood as a behavioral evidence set: a record that can help an underwriting party understand how the merchant's previous payment activity actually behaved.

Current provider documentation illustrates the distinction. Checkout.com states that, depending on factors including registration location, it may request online processing-history information such as processing volume, refund ratio, and chargeback ratio to better understand a business's dispute profile. Worldpay for Platforms similarly identifies previous fraud or chargeback history and, for businesses that have already accepted payments, processing history among information relevant to underwriting. The exact information, period, format, and decision criteria vary by provider, acquirer, merchant, jurisdiction, and business model. A request for processing statements is therefore not a universal checklist item, and a particular historical metric does not by itself determine whether a merchant will be approved. What is payment processing history? Payment processing history is evidence of how a merchant's previous payment activity performed over a defined period. It can include merchant processing statements from a previous PSP or acquirer, transaction or settlement reports, dispute reports, refund reports, and other processor-generated records. A merchant processing statement commonly identifies the merchant and statement period and can include transaction activity, sales, refunds, settlements, fees, and chargebacks. For onboarding purposes, the important point is not the document's name. The important questions are: * Which legal entity generated the activity?

* Which merchant account or accounts are represented? * What period does the evidence cover? * How much was processed? * How many transactions produced that volume? * What was the typical transaction size? * How much activity was refunded? * How much became disputed or charged back? * What fraud information is available? * Which markets and currencies produced the activity? * Was the business stable, seasonal, shrinking, or growing? * Does the history agree with what the merchant has stated in its new application? Processing history therefore sits between a merchant's claims about its business and an underwriter's assessment of how that business has operated in practice. Why may a PSP or underwriter ask for processing statements? A PSP, acquirer, bank, or another underwriting party may need to understand the financial and operational exposure associated with processing payments for a merchant. Previous processing can contribute evidence to that assessment because it records outcomes rather than expectations. Checkout.com, for example, explicitly describes processing volume, refund ratio, and chargeback ratio as information it may request to understand a merchant's dispute profile. Worldpay for Platforms describes merchant underwriting as a risk assessment and identifies processing history, previous fraud history, and excessive chargebacks among possible underwriting information. These are provider-specific examples, not universal rules.

This explains why a large volume figure alone is incomplete. Suppose a merchant reports that it processed $1 million in a month. An underwriter may still need to understand whether that amount arose from: * 100 transactions averaging $10,000; * 10,000 transactions averaging $100; * transactions concentrated in one market; * transactions spread across many markets; * a normal trading month; * a short seasonal peak; * a gradual operating history; or * a sudden increase that differs materially from previous activity. Those scenarios can create different operational questions even when gross volume is identical. What can a merchant processing statement show? Statement formats vary, so merchants should not assume every PSP produces the same fields. Checkout.com describes merchant statements as records containing transactions, sales activity, refunds, settlements, fees, and chargebacks. It also notes that statement headers can identify the business, merchant ID, statement period, and generation date. Other processor reports can expose still more detail. Adyen's reporting documentation, for example, includes fields for merchant account, payment method, currency, amount, shopper country, and issuer country. Its settlement reporting separately identifies gross and net amounts and records debits such as refunds and chargebacks.

An onboarding package therefore may involve a conventional PDF processing statement, data exports, or additional reports where the statement itself does not answer the relevant question. Evidence dimension What it can help establish Important qualification Processing volume Scale of historical payment activity Volume alone says little about transaction shape or outcomes Transaction count Number of payment events generating the volume Do not confuse count with monetary value Average transaction value Typical transaction size Averages can hide a wide distribution Refund activity How often or how much the merchant returns to customers Refunds are not the same as chargebacks Chargebacks/disputes Customer transactions entering a dispute process Not every dispute is fraud-related Fraud data Fraud-related payment outcomes where available Fraud and chargebacks should not be treated as interchangeable Currency and geography Where payment activity occurs Statement-level detail varies by provider Trend Growth, decline, volatility, or seasonality across periods One month may not represent the business Merchant/entity identifiers Whose activity the statement represents The evidence needs to reconcile with the onboarding applicant Volume and transaction count answer different questions One of the most important distinctions in PSP processing history is the difference between transaction value and transaction count. Consider this hypothetical example: Merchant A * Annual processed value: $12 million * 120,000 transactions

* Implied average transaction value: $100 Merchant B * Annual processed value: $12 million * 12,000 transactions * Implied average transaction value: $1,000 Both merchants have identical annual volume, but their transaction profiles are materially different. A simple analytical measure is: Average transaction value = processed transaction value ÷ transaction count The merchant should define which transactions and period are included. For example, an average calculated from successful settled transactions should not silently be compared with one calculated from all authorization attempts. This is why a well-prepared processing-history package does more than display the largest revenue number available. It makes the relationship between volume, count, and average transaction value understandable. Refunds, chargebacks, and fraud are not interchangeable These three concepts frequently appear together in payment reporting but describe different events. Refund A refund is generally a merchant-initiated return of money to a customer following a previous payment. A high refund level does not necessarily mean the same thing in every business. The commercial significance depends on the product, cancellation model, customer journey, fulfilment cycle, and reason for the refunds. Chargeback or dispute

A chargeback arises from the payment dispute process rather than an ordinary merchant refund. Visa describes a chargeback as the result of a disputed transaction where, following review, the payment is reversed in the customer's favor. Disputes can arise from fraud, processing or authorization issues, or customer complaints such as non-receipt or goods or services not being as described. Fraud Fraud is not synonymous with chargebacks. Some chargebacks are fraud-related, while others are not. Adyen's current risk reporting explicitly distinguishes chargeback metrics, fraud metrics, and fraudulent versus non-fraudulent chargebacks. That distinction matters in underwriting. Saying that a merchant had "a 0.5% problem rate," for example, is not useful unless the merchant identifies what the percentage measures, how it was calculated, and which period it covers. Define the denominator before discussing a rate A rate without a denominator can create more confusion than clarity. Possible internal merchant calculations might include: Refund rate by value Refunded payment value during period ÷ Relevant processed payment value during period Refund rate by count Number of refunded transactions ÷ Relevant transaction count Dispute rate by count Number of disputed or charged-back transactions ÷ Defined transaction population These formulas should be treated as clearly labeled merchant analyses, not as universal card-network or PSP definitions.

Provider and scheme methodologies can differ. Adyen, for example, describes a dispute-rate calculation based on disputed payments compared with settled transactions and separately describes fraud rate in relation to settled transactions. Visa's merchant guidance recommends monitoring disputes as a proportion of sales activity. The practical lesson is simple: never send an unexplained percentage. State: 1. the numerator; 2. the denominator; 3. whether the measure is based on count or value; 4. the period; 5. the relevant merchant account or entity; and 6. any exclusions. Gross processing volume is not the same as net settlement Another common processing-history mistake is to treat the amount customers paid as interchangeable with the amount deposited into the merchant's bank account. They are different measures. In Adyen's reconciliation documentation, for example, a transaction has a gross amount paid by the customer and a lower net amount credited after applicable transaction costs. Its reporting also records refunds, chargebacks, fees, and payout activity separately. For onboarding purposes, therefore, merchants should label figures precisely: * Gross processed volume: the defined value of payment transactions before specified deductions. * Net settlement or payout: the amount ultimately settled after the applicable adjustments represented in the relevant report. A bank deposit total should not automatically be described as processing volume.

If the PSP asks for processing volume and the merchant submits only settlement deposits, the two sides may be measuring different things. Geography and currency can change the meaning of the history Historical payment activity can also be segmented by where payments originate and in which currencies they are processed. Not every monthly processing statement contains this detail. Processor reporting systems may provide it separately. Adyen's received-payment reporting, for example, includes transaction currency as well as shopper and issuer country where available. Its risk analytics can also be filtered by issuer country or region, payment method, merchant account, and date range. Visa's dispute guidance also identifies sales volume and geographic location among factors relevant when acquirers address excessive dispute activity. For a merchant, this means a single global total may hide useful context. If 80% of historical processing occurred in one country but the new application forecasts rapid expansion into several new markets, the merchant should not present the historical total as though it already demonstrates the future geographic mix. Historical evidence and future plans answer different questions. Seasonality and trend matter A processing statement is a snapshot for a defined period. A sequence of statements becomes a trend.

That distinction can matter for businesses with holiday peaks, event-driven demand, school terms, travel seasons, large annual renewals, or other uneven sales patterns. Checkout.com's explanation of merchant statements notes that comparing statements over time can reveal changes in transaction activity and trends. Adyen's risk tooling similarly exposes trends across selected date ranges rather than reducing performance to a single lifetime number. A merchant preparing history should therefore consider whether the requested period is representative. If one month is unusually high or low, explain why rather than silently allowing it to stand for normal operations. Useful context might include: * a seasonal sales peak; * a major product launch; * temporary promotional activity; * migration between processors; * entry into a new market; * a business acquisition; * a temporary service interruption; or * a material change in product mix. The purpose of context is not to explain away unfavorable data. It is to make the historical record interpretable. Historical processing is not the same as a forecast A merchant's previous PSP statements describe what occurred. A forecast describes what management expects to occur. Those should remain separate. For example: Historical actual: $800,000 monthly processing in the most recent completed month. Current run rate: activity observed so far in the current period, explicitly identified as incomplete.

Forecast: management expects $1.5 million monthly processing after a new market launch. The forecast may be entirely credible, but the historical statement does not prove it. If future volume is expected to differ materially from processing history, a clear onboarding package should identify the reason for the difference rather than blending actual and projected numbers. That distinction is particularly important for fast-growing merchants. The deeper question of how future scale affects underwriting belongs in Underwriting for High-Growth Merchants; the role of this article is to keep historical payment evidence separate from forward-looking assumptions. Common processing-statement problems A valid statement can still fail to resolve an underwriting question if its scope is unclear. Common practical problems include: The statement belongs to a different legal entity A group may operate several companies, brands, and merchant accounts. If the applying company is Entity A but the previous processing statement names Entity B, do not silently assume the relationship is self-explanatory. Identify the relationship and confirm whether the provider wants the history included. Merchant statements commonly include identifying information such as business details and merchant IDs, which makes entity reconciliation possible. The period is unclear or incomplete Do not combine data from different dates without labeling the periods.

If the PSP asks for a defined scope, provide that scope or explain what is unavailable. Checkout.com's current onboarding guidance provides a good example of why the period must be treated as provider-specific: for certain merchants it explicitly specifies a three-month processing-history period. That should not be generalized into a rule for every PSP or jurisdiction. Only the favorable pages are submitted Where the source document contains multiple pages or sections, sending an incomplete extract can make reconciliation harder. Submit the requested source material intact unless the PSP instructs otherwise. Merchant-created totals do not reconcile with processor records A spreadsheet summary can be useful, but it should complement—not silently replace—the underlying evidence. If the summary says monthly gross volume was $500,000 while the processor reports show a different amount, document the reason for the difference. Refunds and chargebacks are combined Keep them separate. Chargebacks and fraud are combined Keep them separate unless the source system itself defines a combined metric, in which case preserve and explain that definition. Count and value are mixed "$20,000 of chargebacks" and "20 chargebacks" answer different questions. Gross volume and settlement are confused Reconcile processed value to settlement rather than describing them as the same figure. Screenshots lack context

A screenshot that shows a number but not the merchant account, period, provider, or metric label may be difficult to interpret. Where a provider accepts screenshots, preserve enough source context for the data to be understood. Checkout.com, for example, currently states that screenshots can be accepted for its specified processing-history request when a merchant's existing provider does not support exports, provided the screenshots contain the required information. That is a Checkout.com policy example, not a universal PSP rule. What if the merchant has no processing history? A merchant with no previous card or online payment-processing history should say so clearly. No processing history is not the same as no business history. A company might be new to card payments while already having: * established operations; * previous sales through another channel; * customer contracts; * financial statements; * inventory or supplier relationships; * fulfilment records; or * a documented operating plan. Equally, a genuinely new business may have neither payment history nor a long commercial track record. The important point is that processing history should not be fabricated, reconstructed as though it were processor-issued evidence, or borrowed from an unrelated entity.

Provider documentation itself shows that processing history is conditional rather than universally available. Worldpay for Platforms refers to processing history if the business has previously accepted payments, while Checkout.com's online-processing-history request depends on specified onboarding circumstances. Where historical payment evidence does not exist, the provider may need to understand the merchant through other available financial, commercial, or operational evidence. What evidence is acceptable is provider- and merchant-specific. Checkout.com's onboarding guidance, for example, separately provides for financial projections in some circumstances when a new business cannot provide historical financial statements. That does not mean financial projections universally substitute for processing statements; it illustrates the broader principle that underwriting evidence can change when historical records do not exist. The Processing History Review Map Merchants can use the following framework to review their evidence before submission. Review dimension Underwriting question Merchant preparation 1. Scale How much payment activity has occurred? Reconcile monthly processing value and clearly define gross versus net figures 2. Transaction shape What produces that volume? Provide transaction count and average transaction value using defined periods 3. Customer outcomes How much activity results in refunds? Separate refund count and value and explain the denominator 4. Risk outcomes

What happened with disputes, chargebacks, and fraud? Keep these categories distinct and use source-system definitions 5. Geography Where does activity occur? Provide country and currency mix where available and requested 6. Trend Is activity stable, seasonal, declining, or growing? Compare consistent periods and explain material anomalies 7. Application consistency Does history match the merchant described in the application? Reconcile legal entity, merchant account, business model, markets, and forecast The framework is not a PSP scoring model. It is a merchant-side quality-control tool for making historical evidence easier to interpret. How to prepare processing history clearly A strong processing-history submission should behave like a reconciled operating record, not a folder of unexplained PDFs. 1. Confirm exactly what is being requested Identify: * evidence type; * requested period; * legal entity; * merchant account or accounts; * processor or processors; * relevant payment channels; and * required metrics. If the request is ambiguous, ask which underwriting or verification question the reviewer is trying to resolve. 2. Preserve original processor evidence Download processor-issued statements or reports where available. Do not alter the underlying records. 3. Build a reconciliation summary Where the history is complex, create a short summary that maps the source documents into consistent monthly measures. For example: Month Gross processed value Transaction count Avg. transaction value Refund value

Chargeback count January Source figure Source figure Defined calculation Source figure Source figure February Source figure Source figure Defined calculation Source figure Source figure March Source figure Source figure Defined calculation Source figure Source figure Include definitions beneath the table. 4. Define every rate For every percentage, state the numerator, denominator, period, and whether it is calculated by transaction count or monetary value. 5. Separate distinct payment outcomes Do not combine: * refunds with chargebacks; * chargebacks with fraud; * successful transactions with authorization attempts; or * gross processing with net settlement. 6. Explain material anomalies A concise explanation can be more useful than forcing the reviewer to infer why a metric changed. State the event, period, and effect. 7. Reconcile the history with the application Check that: * the legal entity is understood; * trading names are explained; * processor accounts are mapped correctly; * historical markets match the stated footprint or differences are explained; * historical activity is distinguished from future forecasts; and * volume figures use consistent definitions. 8. Keep source evidence and merchant analysis separate A merchant-created spreadsheet can make the submission easier to review. It should be obvious which numbers came directly from a previous processor and which figures or ratios the merchant calculated itself. That distinction protects the integrity of the evidence and makes reconciliation easier.

The goal is not to make the history look perfect Merchants sometimes approach onboarding evidence as though every unusual number must be minimized. That is the wrong objective. A more useful goal is to make the record complete, reconciled, correctly scoped, and understandable. An underwriting party can then evaluate what the evidence actually shows. Historical volume cannot guarantee approval. Neither can a low refund rate, a low dispute rate, rapid growth, long operating history, or any other single metric. Payment underwriting considers the merchant relationship in context. Requirements and risk appetite vary among providers and acquiring arrangements, and a legitimate merchant can still be unsuitable for a particular provider. Processing history reduces one kind of uncertainty: uncertainty about how previous payments behaved. It does not eliminate underwriting judgment. Frequently asked questions Why does a PSP need previous processing statements? A provider may use historical statements to understand more than sales volume. Depending on the onboarding arrangement, the history can help show payment scale, refunds, chargebacks, transaction characteristics, trends, and other aspects of previous performance. Checkout.com's current underwriting guidance, for example, explicitly identifies processing volume, refund ratio, and chargeback ratio in its processing-history request. How many months of merchant processing statements are required?

There is no universal period that should be assumed across PSPs. Requirements must be confirmed with the provider handling the application. Checkout.com currently specifies three months for the particular US and Hong Kong processing-history requirement described in its documentation, while Worldpay for Platforms has separately published an example underwriting-document list mentioning the last three merchant processing statements. These are provider-specific examples, not industry-wide requirements. Does a merchant with no processing history automatically fail underwriting? No universal conclusion follows from the absence of processing history. Worldpay for Platforms itself frames processing history conditionally for businesses that have previously accepted payments. A new merchant should state accurately that no history exists and ask what other evidence the relevant provider requires. Is a refund the same as a chargeback? No. A normal refund is distinct from the dispute and chargeback process. Visa describes a chargeback as an outcome of a transaction dispute reviewed through the issuing and acquiring ecosystem. Are all chargebacks caused by fraud? No. Visa identifies multiple sources of disputes, including fraud, authorization problems, processing errors, and customer disputes. Adyen's reporting likewise distinguishes fraudulent from non-fraudulent chargebacks. Does a low chargeback rate guarantee PSP approval? No.

A historical performance metric is one evidence point. It does not determine overall merchant eligibility or underwriting outcome by itself. Can a merchant send screenshots instead of previous PSP statements? Only where the reviewing provider accepts them. Checkout.com currently states that, for its specified online-processing-history requirement, screenshots may be accepted when the previous payment provider does not support exports, provided the required information is visible. Merchants should not assume another PSP follows the same policy. Final takeaway Processing statements are not valuable to an underwriter merely because they prove that a merchant has processed payments before. Their real value is that they record how those payments behaved. A merchant preparing PSP processing history should therefore treat the submission as a reconciled evidence package: entity → period → volume and transaction shape → refunds → disputes and fraud → geography and currency → trend → consistency with the onboarding application The merchant controls the quality, accuracy, organization, and explanation of that evidence. It does not control the provider's risk appetite, acquirer decision, or final underwriting outcome. Good preparation cannot bypass legitimate underwriting. It can reduce avoidable questions created by unclear, incomplete, inconsistent, or poorly defined processing history.

Disclaimer: This article provides general information and does not constitute legal, regulatory, financial, tax, or compliance advice. Merchant onboarding and underwriting requirements vary by jurisdiction, provider, acquirer, business model, and individual circumstances. Merchants should confirm applicable requirements with qualified advisers and the relevant payment providers, acquirers, banks, regulators, and authorities. 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 ARTICLE END

I followed the brief’s assigned territory: historical payment-performance evidence, with processing history treated as a behavioral evidence set rather than merely proof of past volume. Processing History Requirements for PSP Onboarding: What Underwriters Look For SEO / publication metadata — not part of the article SEO title: Processing History Requirements for PSP Onboarding: What Underwriters Look For Meta title: PSP Processing History Requirements: What Underwriters Review Meta description: Learn why PSPs may request merchant processing statements, which payment-history metrics underwriters may review, and how to prepare clear evidence. Suggested URL slug: /processing-history-requirements

EDITORIAL / SEO NOTES — not part of the article Suggested internal links Underwriting for Online Merchants Suggested placement: in the section explaining why an underwriter may interpret historical performance alongside the broader online business model. Underwriting for High-Growth Merchants Suggested placement: in “Historical processing is not the same as a forecast,” where the article deliberately hands off future-growth underwriting. Documents Needed for PSP Approval Suggested placement: near the first definition of merchant processing statements, for readers who need the wider evidence categories used in onboarding. Why Merchants Are Rejected by PSPs Suggested placement: after the section explaining that no individual processing-history metric guarantees approval. Suggested supporting visual Processing History Review Map A seven-stage horizontal or circular framework: Scale → Transaction shape → Customer outcomes → Risk outcomes → Geography → Trend → Application consistency Under each stage, show one diagnostic question: * Scale — How much was processed? * Transaction shape — How was the volume generated? * Customer outcomes — What was refunded? * Risk outcomes — What became disputed or fraudulent? * Geography — Where did activity occur? * Trend — How did activity change? * Consistency — Does it match the application? The visual should be operational rather than decorative. Recommended visual alt text

“Processing History Review Map showing seven PSP underwriting review dimensions: scale, transaction shape, customer outcomes, risk outcomes, geography, trend, and consistency with the merchant application.” Sources / research references 1. Checkout.com — “Requesting additional information”, updated May 1, 2026. Current provider-specific underwriting guidance describing circumstances in which online processing history may be requested and identifying refund ratio, chargeback ratio, and processing volume. 2. Worldpay for Platforms — “Why underwriting documentation is important.” Describes merchant underwriting and identifies previous fraud/chargeback history and processing history for businesses that have previously accepted payments among possible evidence. 3. Checkout.com — “Merchant processing statements explained.” Useful first-party definition of merchant processing statements and examples of statement contents including transactions, settlements, refunds, chargebacks, merchant identifiers, and statement periods. 4. Adyen Docs — Transaction-level reconciliation. Primary documentation demonstrating the distinction between gross transaction amount, net amount, settlement, fees, refunds, and chargebacks. 5. Adyen Docs — Risk & dispute analytics. Primary documentation distinguishing refund, chargeback, fraud, count, value, date ranges, and fraudulent versus non-fraudulent disputes.

6. Adyen Docs — Received payment details report. Primary documentation showing payment-report fields including merchant account, payment method, currency, amount, shopper country, and issuer country. 7. Visa Acceptance Solutions — Chargebacks. Current first-party explanation of the dispute and chargeback process and of fraud versus non-fraud dispute causes. 8. Visa — Dispute Management Guidelines for Visa Merchants, June 2024. Primary card-network guidance recommending proportional dispute monitoring and describing acquirer involvement and factors including sales volume and geography.

* requires a particular number of statements; * evaluates a particular historical period; * applies a particular refund, dispute, fraud, or volume threshold; * accepts screenshots or particular report formats; * uses a specific underwriting model; * guarantees or targets a particular onboarding time; * applies defined reserve or settlement conditions based on processing history; or * accepts or rejects particular merchant categories based on specified historical metrics.

Claims requiring legal / compliance / risk review

* that the industry-level explanation of processing history reflects current acquiring and underwriting practice;

* that provider-specific examples remain clearly scoped to the cited provider and geography; * that the “no processing history” section does not imply that any particular substitute evidence must be accepted; and * that the regulatory disclaimer is appropriate for the final publication jurisdiction.