Overview
Executive decision
Payment processor selection is a business architecture decision. It determines which transactions the company may accept. It also shapes settlement timing, reserve exposure, data duties, and service continuity.
Price should not control the first screening round. The first question concerns business-model acceptance. The processor must approve the real product, contractual role, websites, countries, and money flow. That approval should be written and entity-specific.
A technically capable processor can still be unsuitable. Suitability requires legal fit, underwriting approval, geographic coverage, operating reliability, and acceptable contract terms.
Most IT companies need several payment functions. A single provider rarely supplies every function at equal quality. Common functions include card acquiring, bank payments, seller accounts, global payouts, tax data, fraud screening, and reconciliation.
The recommended selection sequence has seven stages:
The central procurement rule is simple. A provider’s website proves product availability. It does not prove approval for a particular company. Sales statements also need underwriting confirmation.
Match the provider to the actual transaction role, not the marketing label.
Treat payment acceptance, platform funds, and supplier payouts as separate services.
Require written approval for every restricted category, domain, country, and legal entity.
Compare total cost, including reserves, foreign exchange, disputes, and internal labour.
Prefer hosted payment fields when the company wants a smaller card-data scope.
Maintain a double-entry ledger outside provider dashboards.
Use delayed release and contractual recovery for service-delivery risk.
Treat chargebacks as a secondary recovery method.
Keep real transaction volume with an approved secondary provider.
Cap balances held with payment firms and reconcile them every day.
Recheck provider licences, policies, and product status before contract signature.
Phase I — Define & Map
Define the transaction before selecting the processor
1.1 The processor underwrites facts, not labels
An IT company may describe itself as software, agency, platform, or marketplace. These labels do not settle the payment analysis. The processor examines who contracts, supplies, invoices, refunds, and receives settlement.
The same interface can support different legal roles. One company may sell its own service. Another may connect buyers with independent suppliers. A third may resell a third party’s service under its own contract.
Each role creates a different processor requirement. The provider may treat third-party settlement as a restricted activity. The provider may also require seller verification and controlled balances.
1.2 Four common operating models
| Model | Customer contract | Supplier contract | Settlement pattern | Main processor requirement |
|---|---|---|---|---|
| Direct merchant | Customer buys from the IT company | Supplier acts as a subcontractor | Processor settles gross revenue to the company | Merchant acquiring with written product approval |
| Reseller | Company buys an input and resells a new supply | Supplier sells to the company | Company receives customer funds and pays supplier invoices | Merchant acquiring with contracts, invoices, accounting, and delivery duties that evidence resale |
| Multi-party platform | Customer buys from an independent supplier | Platform sets platform terms with both sides | Regulated provider allocates balances and payouts | Platform payment product with seller verification |
| Third-party escrow | Buyer and supplier transact through escrow terms | Escrow agent controls release conditions | Licensed escrow provider holds funds until release | Escrow product with country and transaction coverage |
A company should not select a role to obtain easier processing. The contracts and daily operations must support that role. Tax, consumer, licensing, and accounting rules also follow the facts.
1.3 The minimum role memorandum
The company should prepare a two-page role memorandum. It should answer these questions for every product line:
Who makes the offer to the customer?
Who promises delivery?
Who controls the supplier’s work?
Who sets the final price?
Who issues the invoice?
Who appears on the card statement?
Who decides refund claims?
Who bears non-delivery loss?
Who owns the receivable?
Who receives processor settlement?
Who owes the supplier?
Who reports tax and seller data?
Unknown answers should remain marked as unknown. Management should resolve them before the request for proposal.
Map the complete movement of money
2.1 A funds-flow diagram is mandatory
The company should draw every money movement. The diagram should start at customer authorization. It should end after payout, refund, or write-off.
The diagram must identify each legal entity and bank account. It should also show currencies, timing, reserve rules, and ledger entries.
At least eight events require separate treatment:
2.2 One uncovered rail can invalidate the design
Companies often design the card flow carefully but ignore manual wires. Other omitted routes include support-created invoices, stored balances, stablecoin transfers, and supplier refunds.
The processor may view an omitted route as third-party fund collection. A regulator may reach the same conclusion. The company should review every rail under one role model.
2.3 The internal ledger
A provider dashboard is not an accounting ledger. It may omit business obligations and cross-provider transfers. It may also change historical reports after disputes.
The internal ledger should use double-entry records. Each transaction needs a stable order identifier. The company should record at least these balances:
Customer funds received.
Processor receivable.
Platform revenue.
Supplier payable.
Restricted supplier earnings.
Refund liability.
Dispute reserve.
Processor reserve.
Foreign-exchange gain or loss.
Unclaimed payout liability.
The ledger should ingest signed webhooks. Daily reconciliation should compare the ledger with provider reports and bank statements.
Separate the payment stack into components
3.1 Core components
| Component | Primary purpose | Typical outputs | Examples |
|---|---|---|---|
| Acquiring | Accept cards and local methods | Authorizations, captures, refunds, disputes, settlement | Stripe Payments, Adyen, Checkout.com, Worldpay, Nuvei |
| Platform payments | Verify sellers and allocate balances | Seller status, split records, transfers, payout eligibility | Stripe Connect, Adyen for Platforms, Airwallex Payments for Platforms |
| Payouts | Pay suppliers or contractors globally | Beneficiary checks, tax forms, payout status, returns | Tipalti, Trolley, Payoneer, PayPal Enterprise Payouts, formerly Hyperwallet |
| Crypto checkout | Quote, screen, accept, and settle digital assets | Invoice address, rate, confirmations, screening, refund data | CoinGate, Confirmo, Triple-A, BVNK |
| Orchestration | Route transactions among contracted providers | Routing rules, retries, token references, unified logs | Primer, Spreedly, IXOPAY, Corefy |
| Fraud controls | Assess account, device, and payment risk | Risk score, rule result, review case | Sift, Forter, SEON, provider-native tools |
| Dispute controls | Receive alerts and prepare evidence | Early alerts, refund decisions, representment files | Verifi, Ethoca, provider dispute APIs |
| Tax controls | Determine tax and collect evidence | Tax result, location evidence, seller reports | Stripe Tax, Fonoa, Quaderno, specialist filing services |
The examples identify product categories. They do not imply universal availability or approval. Each provider applies country, entity, industry, and volume restrictions.
3.2 One provider or several providers
A single provider reduces integration work. It can also simplify reporting and support. This approach works best for a standard direct merchant.
A layered stack suits complex or international operations. It can add local payment methods, specialist payouts, or a separate crypto rail. It also creates more reconciliation and contract work.
The company should choose the smallest stack that meets the defined requirements. Every added provider creates another failure point and data relationship.
3.3 Orchestration has a limited role
Orchestration routes payments among approved processor accounts. It can apply rules based on country, currency, cost, or past performance. It can also store portable payment tokens.
Orchestration does not grant merchant approval. It cannot lawfully route an unapproved category through another account. It also cannot replace a live secondary merchant account.
Build the requirements dataset
4.1 Required business facts
Processor comparison becomes unreliable when candidates receive different facts. The company should use one controlled requirements dataset.
The dataset should include:
Legal entities, incorporation countries, and beneficial owners.
Websites, applications, checkout pages, and customer terms.
Product descriptions and delivery periods.
Customer and supplier countries.
Monthly value and transaction count by country.
Average, median, and maximum transaction value.
Refund, fraud, and dispute history.
Recurring billing terms.
Payment methods and settlement currencies.
Supplier count, payout count, and payout corridors.
Restricted or licensed customer categories.
Required launch date and migration constraints.
Security certifications and incident history.
The company should distinguish current data from forecasts. Forecasts should state assumptions and confidence ranges.
4.2 Geographic requirements
“Global coverage” is not a measurable requirement. The company should list each country and each function.
A provider may support card acceptance in one country but not local settlement. It may support customer payments but not supplier onboarding. A payout provider may deliver funds without opening local accounts.
The country matrix should contain five columns:
| Country field | Question |
|---|---|
| Merchant entity | Can this legal entity sign the contract? |
| Customer location | Can customers pay from this country? |
| Payment method | Which local methods work for this customer? |
| Settlement | Which currencies and bank countries receive settlement? |
| Supplier payout | Can verified suppliers receive funds there? |
4.3 Volume and risk statistics
Processors price future exposure. Average transaction value alone gives little information. The company should provide distributions and cohort data.
Useful statistics include:
Monthly payment value at the 50th, 90th, and 99th percentiles.
Transaction values at the same percentiles.
Refund rates by reason.
Fraud loss by payment method.
Disputes by reason code and transaction month.
Time between purchase and delivery.
Time between delivery and supplier payout.
Share of cross-border transactions.
Share of recurring transactions.
Concentration among the ten largest customers.
Concentration among the ten largest suppliers.
Processors may request twelve months of statements. A new company should provide signed forecasts and comparable operating data.
Apply non-negotiable gates before scoring
5.1 Purpose of hard gates
A weighted score can hide a fatal defect. Low price cannot offset prohibited activity. Good API design cannot offset missing country coverage.
The selection team should apply hard gates first. Only eligible providers should receive a numerical score.
| Gate | Pass evidence | Failure consequence |
|---|---|---|
| Business-model approval | Written approval names the actual role, domains, products, and entities | Reject candidate |
| Product eligibility | Current policy and underwriting response accept every planned category | Remove unsupported flows or reject candidate |
| Geographic coverage | Contracting, payment, settlement, and payout countries all match | Reject candidate for affected corridor |
| Lawful funds flow | Legal review accepts fund holding, agency, resale, or platform structure | Redesign before procurement |
| Licensing | Official register confirms the relevant entity and service | Reject or pause pending verification |
| Security | Required PCI, encryption, access, testing, and incident controls pass review | Reject candidate |
| Data terms | Data roles, transfers, retention, subprocessors, and deletion are acceptable | Negotiate or reject |
| Financial exposure | Reserve, settlement, termination, and insolvency exposure remain within limits | Negotiate or reject |
| Technical fit | Core API, webhook, refund, dispute, and reconciliation tests pass | Reject or require a supported alternative |
| Exit readiness | Tokens, balances, records, and pending cases can move or close safely | Negotiate or reject |
5.2 Evidence strength
The team should grade evidence. A contract term should outrank a sales statement.
Evidence strength is claim-specific. A regulator record proves authorization status, not product approval. Production data proves observed performance, not contractual rights.
An executed term proves only the subject it addresses.
| Grade | Evidence | Permitted use |
|---|---|---|
| A | Executed term, regulator record, sponsor confirmation, or reconciled production data | Final decision |
| B | Entity-specific written approval, binding proposal, or saved test output | Final decision, subject to contract review |
| C | Current official legal or technical documentation | Shortlist decision |
| D | Sales statement, presentation, or public marketing page | Market screening |
| E | Missing, conflicting, anonymous, or unverified evidence | Question generation only |
Each critical gate requires Grade A or Grade B evidence that directly proves that gate. A public product page cannot establish entity-specific approval.
Phase II — Evaluate Fit
Assess business-model and underwriting fit
6.1 Underwriting begins before the sales call
The company should prepare a complete factual file before contacting providers. Partial disclosure can produce a fast approval and a later freeze.
The provider should receive the same core facts:
Business description in plain language.
Customer and supplier roles.
Full domain and application list.
Terms, privacy notice, refund policy, and pricing pages.
Funds-flow diagram.
Product and restricted-category matrix.
Historical processing statements.
Delivery and complaint data.
Licences held by the company or its customers.
Sanctions, identity, and content-control procedures.
The company should record every submitted version. Later changes should trigger a formal provider notification.
6.2 Written approval must be precise
An approval email saying “marketing accepted” may be too vague. The approval should identify the exact service, websites, countries, entities, and transaction model.
The company should ask five direct questions:
6.3 Website consistency
Underwriters compare the application with the live website. They inspect pricing, terms, support channels, prohibited content, ownership, and descriptors.
The following items should match:
Contracting entity.
Invoice issuer.
Card statement descriptor.
Customer support identity.
Product description.
Delivery period.
Refund terms.
Restricted-category policy.
Privacy notice.
Bank beneficiary.
False or incomplete policy text creates more risk than an accurate restrictive policy. The company must enforce every published prohibition.
6.4 Restricted and regulated categories
Many IT companies serve customers in regulated sectors. Examples: financial services, online gaming, pharmaceuticals, telehealth, digital assets, adult content, and weapons.
The IT service may remain lawful. The processor may still restrict the customer sector. Card networks and sponsor banks can apply broader risk rules.
The company should use a category matrix with four states:
| State | Meaning | Payment action |
|---|---|---|
| Prohibited | Law, network rule, or provider policy bars the activity | Reject transaction and customer |
| Approval required | Provider accepts only after written review | Hold activation until approval |
| Licensed only | Customer needs a valid licence in the target market | Verify licence and geographic scope |
| Standard | No special rule was identified | Apply documented onboarding, transaction, and monitoring controls |
The company should use default denial for unclear restricted cases. A human reviewer may approve only with recorded evidence.
Compare acquiring and payment-method coverage
7.1 Card acquiring
Card acquiring remains the main online payment route in many markets. The company should compare more than authorization rate.
Required fields include:
Supported card brands.
Merchant countries.
Customer countries.
Settlement currencies.
Local versus cross-border acquiring.
Merchant category code.
Authorization message detail.
Network token support.
Three-Domain Secure controls.
Partial capture and incremental authorization.
Refund and dispute APIs.
Reserve and settlement rules.
Local acquiring can reduce cross-border charges and may improve authorization performance. The provider may require a local contracting entity or bank account.
The provider may also require domestic settlement. Tax advisers should assess whether the resulting activities create a permanent establishment.
7.2 Bank payments and local methods
Bank payments may lower card-dispute exposure. They can also increase reconciliation work. Reversibility depends on the local method.
Examples: SEPA Credit Transfer, SEPA Direct Debit, ACH, UK Faster Payments, iDEAL, BLIK, and Pix.
The company should classify each method by:
Confirmation speed.
Revocation or return period.
Customer authentication.
Refund process.
Mandate requirements.
Settlement delay.
Currency.
Charge or return fee.
Reference-data quality.
A payment marked “successful” may still be returnable. The ledger should use method-specific finality rules.
7.3 Payment-method relevance
More methods do not always raise conversion. Each method adds testing, support, accounting, and refund work.
The company should add a method when measured demand exceeds its operating cost. Useful evidence includes checkout abandonment, lost sales, and customer requests.
7.4 Customer authentication
The issuer evaluates transaction and device data. It may approve a frictionless flow or request a challenge.
The team should test:
Exemption handling.
Challenge rate.
Challenge completion.
Liability shift.
Mobile redirect behavior.
Stored-card transactions.
Merchant-initiated transactions.
Soft-decline recovery.
The team should measure exemption requests, authorization rates, fraud, and issuer soft declines by country.
7.5 Recurring billing and subscriptions
A subscription business should score billing operations separately from payment acceptance.
The company should test:
Initial authentication.
Stored-credential indicators.
Consent records.
Merchant-initiated transaction treatment.
Network tokens.
Account updates.
Retries and dunning.
Plan changes and pauses.
Cancellations.
Prorated refunds.
The company should measure involuntary churn, renewal recovery, retry cost, and renewal dispute rates.
The contract should cover export of schedules, consent records, mandates, and payment tokens.
7.6 Checkout data and friction
The checkout should collect the minimum data needed for payment, tax, fraud, and delivery. Other data can wait until a later step.
The company should test each field through controlled experiments. It should also retain fields required for tax or fraud evidence.
Evaluate platform payment products
8.1 When a platform product is necessary
A platform product becomes relevant when independent sellers receive transaction proceeds. The provider usually creates a connected account or ledger balance for each seller.
Verification and legal status vary by product, entity, and country.
Examples: Stripe Connect, Adyen for Platforms, Airwallex Payments for Platforms, Checkout.com Integrated Platforms, Mangopay, and Lemonway.
These products can support:
Seller identity verification.
Capability restrictions.
Split allocation.
Platform commissions.
Seller balances.
Refund allocation.
Negative-balance recovery.
Payout scheduling.
Seller statements.
8.2 Charge types change liability
The platform should understand who appears as merchant for each charge. The answer controls disputes, fees, refunds, and statement descriptors.
Other products allocate liability differently. The contract and technical setup must state the result. Product names alone are insufficient.
8.3 Seller verification does not transfer every duty
A provider may verify sellers for payment-law purposes. The platform controls product access and contractual performance. It may retain sanctions, tax, consumer, and content duties.
The platform should map each control to one owner. It should obtain evidence through webhooks or reports. Silence should not count as successful verification.
8.4 Release conditions
The provider may permit delayed settlement or manual transfers. These functions do not automatically create licensed escrow.
The company should define release conditions in operational terms:
Customer funds have settled.
Supplier identity status is valid.
The service has reached a defined milestone.
The complaint period has ended.
No sanctions or fraud block exists.
The reserve rule has been applied.
The platform should disclose the release model in its customer and supplier terms.
8.5 Regulatory classification remains separate
A provider product does not settle every legal classification. The company may still need advice on money transmission, stored value, escrow, or agency.
In the United States, federal and state tests can differ.
State agent-of-payee treatment depends on facts and statute. The company should test the exact contract and money path in every required state.
The company should place regulated balances with the licensed provider. It should use direct custody only after jurisdiction-specific legal confirmation.
Evaluate supplier and contractor payouts
9.1 Payouts require separate analysis
A global payout service is not the same as an acquirer. It moves company funds to recipients. It may verify recipients and collect tax data.
Examples: Tipalti, Trolley, PayPal Enterprise Payouts, Payoneer, Wise Platform, Airwallex Global Payouts, dLocal, and Nium.
The provider should identify the regulated entity for each corridor. The company should also identify any sponsor bank or local partner.
9.2 Coverage claims need field testing
Provider coverage numbers are usually aggregated across methods and entities. They do not prove that every recipient can receive every currency.
9.3 Payout due diligence
The team should compare:
Individual and company onboarding.
Beneficial-owner verification.
Bank-account ownership checks.
Sanctions screening.
Tax form collection.
Local tax reporting.
Payout methods.
Funding methods.
Currency conversion.
Minimum and maximum payouts.
Returned and unclaimed funds.
First-payout review.
Support response time.
Recipient data export.
The company should measure payout success by corridor. A global average can conceal corridor-specific payout failure.
9.4 Payout timing and reserves
Supplier earnings should become payable only after the contractual release event. Payout speed should not exceed delivery certainty.
Common controls include:
First-payout hold.
Rolling supplier reserve.
Delivery confirmation.
Complaint period.
Bank-account change hold.
Velocity limit.
Negative-balance netting.
Future-earnings set-off.
The company should not describe an internal hold as regulated escrow unless the legal structure supports that term.
9.5 Tax and seller reporting
Payout onboarding should capture tax status before funds become payable. Examples: Forms W-8 and W-9, taxpayer identifiers, VAT numbers, and DAC7 fields.
Payment providers can collect data. The platform must still determine whether a reporting rule applies.
9.6 Payment method does not determine indirect tax
Tax follows the underlying supply and customer facts. Card, bank, wallet, and crypto routes do not change that starting point.
The processor should provide reliable location, currency, fee, and refund data. The tax system should determine the tax result.
Evaluate crypto and stablecoin payment products
10.1 Accountless does not mean anonymous
A payer may complete a hosted crypto invoice without opening a provider account. The provider may still screen the wallet and transaction. It may request identity or source data when risk rules trigger.
The request for proposal should ask for the exact payer process. It should cover ordinary, high-value, self-hosted-wallet, and flagged transactions.
10.2 Dynamic invoices
A managed gateway usually creates a payment quote and destination address. The invoice has an expiry time. The provider tracks network confirmations and amount variance.
This design supports:
Order matching.
Exchange-rate control.
Address screening.
Underpayment handling.
Overpayment handling.
Confirmation status.
Refund records.
Fiat settlement.
A static wallet address weakens matching and audit evidence. It also transfers screening, refunds, and accounting to the merchant.
10.3 Crypto product types
| Product type | Customer experience | Settlement | Main use | Main caution |
|---|---|---|---|---|
| Regulated checkout | Hosted invoice, wallet transfer, possible step-up checks | Fiat, crypto, or stablecoin | Merchant checkout | Country and asset coverage changes |
| Enterprise stablecoin rail | API channels, virtual accounts, or assigned addresses | Stablecoin and fiat | Treasury and platform flows | Minimum volume and onboarding terms vary by provider and contract |
| Exchange-account payment | Customer pays through a verified exchange account | Crypto or fiat | Existing exchange users | Customer must hold an account |
| Card-to-crypto on-ramp | Customer buys crypto by card before transfer | Crypto | Wallet funding | Full payer checks and extra fees |
| Self-hosted gateway | Merchant controls invoice software and wallet | Crypto | Technical control | Merchant owns screening and conversion duties |
10.4 Provider comparison fields
The crypto evaluation should include:
Contracting and licensed entity.
Official register entry.
Merchant countries.
Payer countries.
Supported assets and networks.
Self-hosted-wallet treatment.
Travel Rule procedure.
Wallet-screening vendor.
Confirmation policy.
Rate-lock period.
Fiat settlement currencies.
Conversion point.
Settlement frequency.
Minimum settlement.
Refund method.
Underpayment and overpayment process.
Blocked-funds process.
Data export.
Custody and safeguarding.
It lists zero settlement processing fees and dynamic network fees. It also lists a 100% fee for a non-refunded payment exception.
The schedule lists EUR 10 monthly for an abandoned account. These public rates do not establish an entity-specific quote.
10.5 Asset and network risk
An asset name does not identify the network. USDT can operate on several blockchains. Each network has different fees, confirmation rules, and screening data.
The checkout should block unsupported network choices. It should warn that wrong-network transfers may be irrecoverable.
The provider should document any recovery procedure and fee.
The company should avoid promising permanent asset support. Stablecoin treatment can change after licensing or network-policy changes.
10.6 Refunds
Crypto refunds are not card reversals. The company needs a verified destination address and a recorded exchange rate.
The refund policy should answer:
Does the customer receive the original asset amount?
Does the customer receive the fiat purchase value?
Which party bears network fees?
Which rate applies?
Does the provider screen the refund address?
What happens after a price movement?
The customer terms should state the selected method before purchase.
Determine whether a merchant-of-record service fits
11.1 What the service changes
A merchant-of-record service becomes the seller to the customer. It usually processes payment, calculates indirect tax, issues the customer invoice, and handles billing support.
This model can suit software and digital goods. It can reduce the merchant’s indirect-tax and payment operations.
It changes the customer contract. It may also change revenue presentation or recognition. The accounting team must assess principal-agent treatment.
Examples: Paddle, FastSpring, and Lemon Squeezy.
11.2 Product eligibility is narrow
Many merchant-of-record services focus on SaaS, software, games, or digital content. They may reject marketplaces, advertising services, human services, or physical fulfillment.
The company should confirm:
Exact product eligibility.
Customer contract language.
Refund authority.
Tax registration scope.
Supported countries and currencies.
Subscription migration.
Revenue recognition treatment.
Customer-data access.
Reseller margin and deductions.
Exit and customer continuity.
11.3 A merchant of record is not a marketplace payout product
The service may buy software from one developer and resell it. It does not necessarily allocate transaction funds among many independent suppliers.
An IT marketplace may still need seller verification, balances, tax data, and payouts. The merchant-of-record model should not be treated as a substitute without written product approval.
Phase III — Control & Verify
Control fraud, disputes, and delivery risk
12.1 Separate four loss sources
Payment loss has several causes. A single fraud score cannot control all causes.
The company should track four classes:
| Loss class | Typical event | Primary control |
|---|---|---|
| Unauthorized payment | Stolen card or compromised account | Device, identity, authentication, and velocity controls |
| Friendly dispute | Customer recognizes the purchase but disputes it | Clear descriptor, receipt, support, and evidence |
| Service failure | Supplier does not deliver or removes the service | Delayed release, monitoring, reserve, and replacement |
| Processor loss | Provider freezes, delays, or fails | Balance caps, daily sweeps, diversification, and exit plan |
12.2 Fraud controls
The company should designate one risk-decision engine. Provider-native controls often supply payment-specific signals.
An independent engine may coordinate decisions across several processors.
Useful signals include:
Device history.
Account age.
Email and telephone risk.
IP and billing-country mismatch.
Card fingerprint.
Velocity across accounts.
Failed authentication history.
Supplier and customer relationship.
Repeated refund behavior.
Network or wallet risk.
Rules should state the business reason for each decision. Reviewers should see the underlying signals.
The company should test false positives by country and customer cohort. A low fraud rate can hide excessive rejection.
12.3 Dispute prevention
Pre-dispute resolution can prevent formal network filing. The company should use:
Recognizable statement descriptors.
Immediate receipts.
Accurate delivery dates.
Accessible cancellation.
Recorded acceptance.
Fast support.
Proactive refund rules.
Network dispute alerts.
12.4 Representment evidence
Each product should have an evidence template. The template should match the relevant dispute reason.
Evidence may include:
Customer identity and account history.
Authentication result.
Order timestamp and IP address.
Contract acceptance.
Product description.
Delivery record.
Customer communications.
Refund policy.
Prior undisputed transactions.
Service-use logs.
The team should never submit irrelevant evidence in bulk. Networks may impose strict formats and deadlines.
12.5 Network monitoring
Card networks monitor acquirers and merchants. The company should receive monthly network metrics from each processor.
For example, from 1 April 2026, Visa sets an excessive-merchant ratio threshold at 150 basis points. It also sets a minimum count of 1,500 monthly events.
The regions are Asia-Pacific, Canada, the European Union, and the United States.
The fact sheet defines the ratio as TC40 fraud plus TC15 disputes, divided by TC05 settled transactions. The threshold is not an acceptable operating target.
The merchant threshold applies only when the acquirer is neither Above Standard nor Excessive. The ratio excludes qualifying pre-dispute resolutions.
It also excludes specified Compelling Evidence 3.0 fraud records. Both exclusions depend on extraction timing.
The company should set internal thresholds below network thresholds. It should also measure fraud and disputes by merchant account, region, and sales month.
Thresholds can change. The processor should provide written notice and remediation support.
12.6 Service-delivery protection
Card disputes do not protect a company fully against supplier failure. The company may lack card rights after paying the supplier by bank transfer.
Primary controls should include:
Clear acceptance criteria.
Milestone approval.
Delayed earnings release.
Supplier reserve.
Repeated service checks.
Replacement obligation.
Contractual credit.
Set-off against future earnings.
Evidence retention.
Longer performance periods need longer contractual remedies. Examples: 90-day replacement, 12-month monitoring, or paid extended coverage.
Test the technical integration
13.1 Integration modes
| Mode | Card-data handling | Control | Typical use |
|---|---|---|---|
| Redirect checkout | Provider hosts the entire payment page | Provider controls payment-page presentation | Rapid deployment with narrower card-data handling |
| Embedded hosted fields | Provider hosts sensitive fields inside the interface | Company controls page; provider controls sensitive fields | Web and mobile checkout without direct card-data transmission |
| Direct API | Company transmits card data to the provider | Company controls request payloads and workflow | Teams that maintain full PCI DSS controls |
| Payment link | Provider hosts a single invoice page | Limited workflow control | Sales invoices and support-assisted payment |
The company should select the least complex mode that meets product needs. Custom card-data handling should have a clear business reason.
13.2 Required API behavior
The technical assessment should test:
Idempotent create and refund requests.
Webhook signing.
Event retry.
Event ordering.
Duplicate event handling.
Partial capture.
Partial refund.
Multi-currency settlement.
Dispute retrieval.
Reconciliation identifiers.
Sandbox realism.
Versioning policy.
Rate limits.
Maintenance notices.
API status reporting.
13.3 Webhook processing
The receiver should authenticate each event before processing it. It should store the raw event before business actions.
The company should test these failure cases:
The ledger should reach the same final state after every test.
13.4 Token portability
A provider-specific token can create migration dependence. The company should ask whether network tokens or portable vault tokens can move.
The migration plan should identify:
Stored card records.
Customer consent.
Token export format.
Network-token ownership.
Recurring mandate evidence.
Data-transfer security.
Migration fees.
Provider cooperation period.
Some providers support direct token migration under controlled procedures. The contract should state the obligation before launch.
13.5 Reconciliation
Every provider should expose transaction, fee, reserve, dispute, and settlement records. Each record should contain stable identifiers.
The company should reconcile three layers daily:
Differences should enter a tracked exception queue. The company should assign an owner and aging target.
13.6 Production-like test cases
The sandbox test should include ordinary and adverse events:
Successful authorization and capture.
Soft decline with authentication.
Hard decline.
Duplicate submission.
Partial capture.
Partial refund.
Full refund.
Dispute.
Charge reversal.
Failed payout.
Returned payout.
Changed beneficiary.
Currency conversion.
Delayed webhook.
Provider outage.
The team should record expected ledger entries for every case.
Verify security, privacy, and operational controls
14.1 Card security
The applicable PCI scope depends on integration design. Hosted fields can reduce exposure. They do not remove all merchant duties.
The company should verify:
Current PCI attestation.
Scope of listed services.
Penetration testing.
Encryption in transit and at rest.
Key management.
Privileged-access controls.
Security logging.
Incident notification.
Subprocessor controls.
Business continuity.
14.2 Data roles
Payment data can serve several purposes. Examples: transaction execution, fraud screening, legal reporting, analytics, and support.
The contract should allocate:
Controller and processor roles.
Permitted purposes.
Data fields.
Retention periods.
International transfers.
Subprocessors.
Individual-rights requests.
Breach notices.
Data export.
Deletion after termination.
The company should not assume that one provider role covers every product. A provider may act independently for identity or fraud decisions.
14.3 Identity and sanctions data
The company should collect the minimum data needed for the defined decision. It should not duplicate full identity documents without a clear purpose.
The sanctions design should assess four control points:
Customer onboarding.
Transaction review.
Supplier onboarding.
Supplier payout.
Applicable law and documented risk assessment determine the screening method and timing. OFAC prescribes no single instant-payment design.
The company should also rescreen active parties after list changes. Screening needs match resolution and case records.
14.4 Provider financial safety
A regulatory licence does not equal deposit insurance. Safeguarding rules also differ by jurisdiction and product. If your business needs its own licence rather than a provider's, see our Payment & E-Money Licensing solution and the Fintech Licensing Hub.
The company should request:
Official licence and permission extract.
Safeguarding or client-money description.
Independent audit report where available.
Settlement bank names.
Insolvency treatment.
Insurance coverage.
Financial statements.
Capital or reserve information.
Material enforcement history.
Business continuity plan.
The company should cap operational balances. It should sweep settled funds to a bank account at a defined frequency.
Calculate total cost
15.1 Headline processing price is incomplete
The true cost includes cash, liquidity, engineering, finance, support, and risk. The company should model costs by transaction cohort.
Total payment cost = processor markup + fixed fees + network costs + FX cost + liquidity cost + losses + operations + migration
Remove pass-through costs already included in a blended provider rate. Count the funding cost of reserves, not the reserved principal.
The model should include:
Processing fee.
Interchange and network assessment.
Cross-border surcharge.
Currency-conversion spread.
Fixed transaction fee.
Authentication fee.
Refund fee.
Dispute fee.
Fraud-tool fee.
Seller-account fee.
Identity-check fee.
Payout fee.
Beneficiary fee.
Minimum monthly charge.
Setup and certification fee.
Reserve funding cost.
Delayed-settlement funding cost.
Internal support and reconciliation cost.
15.2 Pricing models
Enterprise contracts often use negotiated pricing. The company should demand a full fee schedule for each entity and method.
15.3 Reserve cost
A rolling reserve restricts cash. The economic cost depends on reserve percentage, holding period, growth, and funding rate.
Approximate annual reserve funding cost = average restricted balance × annual funding rate
The model should also test processor termination. The provider may hold funds for several months after closure.
A representative reserve range is unknown because providers negotiate these terms privately. Use stated stress assumptions only.
The binding schedule should state the basis, percentage, cap, review date, and release date.
15.4 Foreign exchange
The team should separate:
Customer presentment currency.
Processing currency.
Provider ledger currency.
Settlement currency.
Supplier payout currency.
Accounting functional currency.
One transaction can incur several conversions. The company should request the benchmark rate, spread, timestamp, and weekend rule.
The pilot should compare actual settlement against an independent reference rate. It should use the same transaction times and currencies.
15.5 Authorization value
A lower fee can be offset by lower approval rates. The model should compare expected net payment proceeds.
Expected settled value = valid attempted value × value-weighted approval rate × settlement rate
Net retained value = settled value - refunds - chargebacks - fraud loss - payment cost
Use settled sales revenue when fulfillment cost or gross margin differs across cohorts.
Approval rates should be compared by country, card type, and customer cohort. A blended rate can mislead.
Negotiate the contract and exit plan
16.1 Contract scope
The agreement should name every service and contracting entity. It should incorporate the approved business description.
The company should attach:
Approved domains and applications.
Approved products.
Approved restricted categories.
Merchant category code.
Countries and currencies.
Settlement schedule.
Reserve schedule.
Payout services.
Data services.
Service commitments.
Pricing schedule.
The sales proposal should not remain the only source for a material promise.
16.2 Reserve, freeze, and termination terms
The company should negotiate:
Reserve calculation.
Reserve cap.
Review date.
Evidence for increases.
Settlement suspension triggers.
Notice period.
Cure period.
Termination assistance.
Post-termination hold.
Release of undisputed funds.
Negative-balance recovery.
Providers often retain broad risk discretion. The company should at least require notice, reasons where lawful, and periodic review.
16.3 Service and support
The contract should define:
Availability measurement.
Excluded maintenance.
Incident severity.
Response time.
Restoration target.
Status communication.
Escalation contacts.
Service credits.
Data recovery.
Disaster recovery tests.
Service credits rarely cover lost revenue. The company still needs a secondary route.
16.4 Change control
Provider terms and policies change. The contract should define notice for pricing, product, country, and policy changes.
The company should require a reasonable migration period when a service ends. Immediate suspension may remain necessary for law or network orders.
16.5 Exit assets
The exit plan should identify:
Payment tokens.
Customer mandates.
Seller identity records.
Transaction records.
Dispute records.
Tax data.
Pending refunds.
Restricted balances.
Pending payouts.
API logs.
The contract should set export formats and delivery times. It should also address secure deletion.
Design resilience without policy evasion
17.1 Secondary processing
A secondary processor protects against technical failure and provider concentration. It works only when the second account is approved and active.
The company should send ordinary live volume through both routes. A dormant account may face renewed underwriting during an emergency.
The routing policy should consider:
Approved product scope.
Merchant entity.
Customer country.
Currency.
Payment method.
Processor status.
Cost.
Recent approval rate.
Reserve exposure.
Policy restrictions should override performance routing.
17.2 Independent dependencies
Two provider brands can share one sponsor bank, gateway, cloud region, or card vault. Apparent redundancy may fail during one upstream incident.
The company should map:
Acquirer.
Sponsor bank.
Gateway.
Token vault.
Cloud region.
Fraud vendor.
Identity vendor.
Settlement bank.
Payout partner.
Material shared dependencies should reduce the resilience score.
17.3 Treasury limits
The company should set a balance limit for each provider. The limit should reflect payout needs, refund exposure, and failure recovery.
Daily treasury controls should include:
Provider balance.
Restricted reserve.
Available settlement.
Bank receipt.
Pending refund.
Pending payout.
Failed transfer.
Unexplained variance.
Finance should escalate every limit breach.
17.4 Outage playbook
The playbook should define:
The company should rehearse the playbook twice each year.
Phase IV — Decide & Operate
Use a weighted decision model
18.1 Baseline weights
Hard-gate failures remain disqualifying. The score compares only eligible candidates.
| Criterion | Weight | Core question | Fixed subweights |
|---|---|---|---|
| Business model and underwriting | 20 | Does written approval cover the real product, role, entities, and categories? | Activity approval 8; role and entity 4; scope 4; change review 4 |
| Geography and methods | 10 | Does the product cover required customer, settlement, and payout corridors? | Required routes 4; measured acceptance 3; local settlement 2; expansion 1 |
| Funds flow and platform functions | 10 | Can the product represent required balances, splits, refunds, and releases? | Payment states 4; ledger 3; recovery 2; balance separation 1 |
| Risk and compliance operations | 10 | Are identity, sanctions, fraud, disputes, and reviews operationally usable? | Identity 3; fraud and authentication 3; category controls 2; records 2 |
| Total economics | 12 | What is the cohort-level cost after reserves, FX, losses, and labour? | Payment cost 4; liquidity 3; other variable costs 2; operations 2; stability 1 |
| Reliability and continuity | 10 | Can the provider meet service, recovery, and financial-safety needs? | Availability 3; settlement 2; support 2; dependencies 2; communication 1 |
| Developer and finance operations | 10 | Do APIs, webhooks, reports, and reconciliation pass testing? | API 2; events 2; reports 2; testing 2; administration 2 |
| Payout and treasury | 8 | Do corridors, beneficiary checks, funding, and returns meet requirements? | Corridors 2; onboarding 2; cost and speed 1.5; returns 1.5; FX and funds 1 |
| Security and data | 5 | Do security, privacy, access, and incident terms pass review? | Card security 1.5; assurance 1; privacy 1; incidents 1; access 0.5 |
| Contract and exit | 5 | Are change, termination, export, and transition terms acceptable? | Risk rights 1.5; portability 1.5; liability 1; changes 0.5; transition 0.5 |
| Total | 100 |
18.2 Scoring formula
Each reviewer scores every fixed subcriterion from zero to five:
0: no capability or unacceptable evidence.
1: major gaps.
2: several material gaps.
3: meets the minimum requirement.
4: exceeds the requirement.
5: best verified fit among candidates.
Each subcriterion receives its own evidence factor:
| Evidence | Factor |
|---|---|
| Executed term, regulator record, sponsor confirmation, or production data | 1.00 |
| Entity-specific approval, binding proposal, or saved test output | 0.90 |
| Current official legal or technical documentation | 0.75 |
| Sales statement, presentation, or public marketing page | 0.40 |
| Missing, conflicting, or unverified evidence | 0.00 |
These factors are procurement policy values, not empirical probabilities.
Subcriterion points = subweight × raw score ÷ 5 × evidence factor
The model sums adjusted subcriterion points. The decision record should show raw and adjusted totals.
The company must approve award thresholds before opening bids.
One illustrative policy requires 80 points supported by Grade A or Grade B evidence. It also requires 75 adjusted points.
The policy should define critical categories before opening bids. Each critical category should earn at least 60%.
Treat a two-point difference as a tie only when measurement uncertainty supports that margin.
18.3 Scenario sensitivity
Weights should reflect the business model. The company should approve weights before opening bids.
| Criterion | Direct SaaS | Multi-party platform | Global supplier payouts |
|---|---|---|---|
| Business model and underwriting | 18 | 18 | 17 |
| Geography and methods | 12 | 9 | 14 |
| Funds flow and platform functions | 5 | 15 | 7 |
| Risk and compliance operations | 10 | 10 | 10 |
| Total economics | 15 | 10 | 10 |
| Reliability and continuity | 12 | 9 | 10 |
| Developer and finance operations | 12 | 9 | 8 |
| Payout and treasury | 3 | 8 | 14 |
| Security and data | 7 | 6 | 5 |
| Contract and exit | 6 | 6 | 5 |
| Total | 100 | 100 | 100 |
The team should rerun the ranking under each plausible scenario. A candidate that wins only under one narrow assumption needs closer review.
Run one-at-a-time sensitivity tests. Increase or decrease one weight by 20%, then normalize all weights to 100 points.
Stress volume, disputes, approval rates, reserves, and outages separately.
Each route should receive its own score. Examples: domestic cards, cross-border cards, bank payments, crypto, and payouts.
18.4 Anti-gaming rules
The selection chair should enforce these rules:
Approve weights before receiving final prices.
Score evidence, not presentation quality.
Require comments for scores below three or above four.
Use at least three reviewers from different functions.
Resolve score differences greater than two points.
Separate provider facts from forecasts.
Treat missing evidence as zero.
Record all overrides.
Recalculate after contract negotiation.
Reapprove the decision after any material scope change.
Run a controlled request for proposal
19.1 Candidate funnel
A broad initial screen may include eight to twelve providers. The hard gates should reduce that group to three or four candidates.
The process should have five rounds:
The company should stop work on a candidate after a hard-gate failure. Sunk sales effort should not influence the decision.
19.2 Underwriting data room
The data room should contain:
Certificate of incorporation.
Ownership and director records.
Group structure.
Official business address.
Bank statement.
Financial statements.
Processing statements.
Product and pricing pages.
Customer and supplier terms.
Refund and complaint policies.
Privacy and security materials.
Funds-flow diagram.
Volume and country data.
Restricted-category matrix.
Licences and customer-verification controls.
Fraud and dispute data.
Sample invoices and statement descriptors.
Support contacts.
Incident and continuity procedures.
The company should index each file. It should also record the version and submission date.
19.3 Written response format
Each provider should answer the same table:
| Field | Required response |
|---|---|
| Contracting entity | Legal name, country, licence, and register link |
| Approved business | Exact description and approved domains |
| Product status | Generally available, beta, or planned |
| Countries | Merchant, customer, settlement, and payout coverage |
| Methods | Method, currency, limits, and reversibility |
| Underwriting | Required documents, timing, and approval owner |
| Reserves | Formula, cap, review, and release |
| Settlement | Timing, cut-off, holidays, and deductions |
| Pricing | Every fixed, variable, network, FX, and support fee |
| Security | PCI scope, certifications, testing, and incident terms |
| Operations | Support, escalation, reporting, and service status |
| Exit | Token, record, balance, and dispute transition |
Blank cells should count as missing evidence.
19.4 Reference checks
The company should request two reference customers with similar volumes and product structure. References should answer factual questions.
Useful questions include:
How long did underwriting take?
Which facts caused follow-up review?
Did the provider change reserves?
How accurate are reports?
How quickly does support resolve settlement issues?
Did the provider assist during network monitoring?
How did token or data migration work?
Which contract term caused the greatest operating cost?
A provider-selected reference has selection bias. The company should still compare the account with public incidents and regulator records.
Pilot before full migration
20.1 Pilot scope
The pilot should use real customers, ordinary amounts, and the final entity. It should not use a simplified temporary model.
The pilot should cover:
At least two customer countries, where the launch covers several countries.
At least two currencies, where the launch includes foreign exchange or multi-currency settlement.
Every launch payment method.
Refunds.
Authentication.
One dispute simulation where permitted.
Settlement.
Reconciliation.
Support escalation.
Supplier payout where applicable.
20.2 Acceptance measures
The company should set measures before launch:
| Measure | Calculation |
|---|---|
| Authorization rate | Approved authorizations divided by valid attempts |
| Checkout completion | Completed payments divided by checkout starts |
| Authentication completion | Completed challenges divided by issued challenges |
| Settlement accuracy | Correct settled amount divided by expected amount |
| Reconciliation exception rate | Unmatched records divided by transaction records |
| Refund completion time | Median time from approval to customer receipt |
| Payout success | Successful payouts divided by submitted payouts |
| Support response | Median time to first qualified response |
| API availability | Technically successful provider-attributable requests divided by eligible requests; exclude business declines and merchant-side errors |
| Total payment cost | All payment costs divided by settled value |
The company should compare cohorts, not only aggregate totals.
20.3 A 90-day programme
| Period | Main work | Exit condition |
|---|---|---|
| Days 1 to 15 | Roles, money flows, requirements, risk matrix, data room | Management approves one factual baseline |
| Days 16 to 30 | Public screen, hard gates, initial provider contact | Eight to twelve candidates become three or four |
| Days 31 to 50 | Underwriting, pricing, licence checks, reference calls | Written approval and complete commercial response |
| Days 51 to 70 | Sandbox build, ledger, reconciliation, failure testing | Technical acceptance report |
| Days 71 to 85 | Contract, security, privacy, support, operating procedures | Signed terms and launch approval |
| Days 86 to 90 | Controlled production pilot and secondary-route test | Measured pilot passes release limits |
A complex marketplace may need more time. Missing licences or local entities can extend the schedule.
Operate the provider after launch
21.1 Monthly control pack
Management should review one monthly payment pack. It should contain:
Payment value and count.
Authorization rate.
Authentication rate.
Refund rate.
Fraud loss.
Dispute rate.
Network-monitoring position.
Settlement delays.
Reserve balance.
Reconciliation exceptions.
Payout success.
Provider incidents.
Support cases.
Policy or licence changes.
Concentration by provider and bank.
The report should show trends and limits. Every breach needs an owner and deadline.
21.2 Quarterly provider review
The quarterly review should cover:
Business-model changes.
New products and domains.
New countries.
Restricted customer categories.
Ownership changes.
Licence status.
Contract changes.
Reserve changes.
Security incidents.
Financial condition.
Secondary-route readiness.
The company should notify the provider before material changes when the contract requires notice.
21.3 Annual renewal
The company should repeat the hard-gate test annually. It should also refresh the market screen.
The renewal should ask whether:
The original approval still matches operations.
A better local method now exists.
Provider concentration remains acceptable.
Pricing still reflects volume.
Tokens and data remain portable.
The secondary account is active.
Internal controls still match actual work.
Recognize warning signs
22.1 Provider warning signs
The company should pause procurement when it sees:
No clear legal entity.
No official register entry.
No named issuing or sponsor bank where relevant.
No acceptable-use policy.
No written business-model approval.
“Guaranteed approval.”
Settlement to an unrelated entity.
Requests to hide products or domains.
No dispute procedure.
No data export.
No reserve formula.
No incident contact.
Pricing available only through an informal message.
Unexplained changes between website and contract.
Large advance funding without safeguarding detail.
22.2 Company warning signs
Internal behavior can also cause failure:
Different descriptions sent to different providers.
Unlisted domains.
Incorrect statement descriptors.
Unsupported third-party funds.
Restricted transactions routed through standard accounts.
Provider accounts kept dormant until an outage.
Manual refunds outside the ledger.
Static crypto addresses without order matching.
Supplier payouts before delivery evidence.
Missing tax data at payout.
Unreconciled provider balances.
No owner for policy updates.
22.3 Common selection errors
Choosing the lowest headline fee
The cheapest quote may contain higher reserves or lower approval rates. The company should compare net approved revenue and liquidity cost.
Treating a licence as product approval
A licence states a permitted regulated activity. It does not require the provider to accept every industry or country.
Treating sales approval as underwriting approval
The sales team may describe technical capacity. The underwriting team decides account eligibility and reserve terms.
Buying orchestration before obtaining processor accounts
Routing software needs approved destinations. The company should secure independent accounts first.
Using a merchant-of-record service for an unsupported product
The model changes the seller and tax position. The provider must approve the actual product and supply chain.
Assuming customer bank checks cover the company
The payer’s bank performs its own controls. The merchant still owns contractual, sanctions, tax, and product duties.
Relying on card disputes for supplier performance
Network disputes may be unavailable or slow. Contractual release and recovery rules provide better primary protection.
Appendices
Detailed request-for-proposal questions
A.1 Corporate and regulatory status
A.2 Business-model approval
A.3 Payments
A.4 Platform functions
A.5 Payouts
A.6 Crypto and stablecoin services
A.7 Pricing and reserves
A.8 Technology and operations
A.9 Security and data
A.10 Contract and exit
Underwriting data-room checklist
B.1 Corporate records
Incorporation certificate.
Constitutional documents.
Director register.
Ownership register.
Beneficial-owner identification.
Group chart.
Registered and operating addresses.
Bank-account confirmation.
Latest financial statements.
Management accounts.
B.2 Product records
Product description.
Product screenshots.
Price list.
Customer journey.
Supplier journey.
Customer terms.
Supplier terms.
Refund policy.
Complaint policy.
Delivery standards.
B.3 Payment records
Funds-flow diagram.
Entity and account map.
Processor statements.
Bank statements.
Monthly volume table.
Transaction-value distribution.
Refund analysis.
Fraud analysis.
Dispute analysis.
Settlement history.
B.4 Risk and control records
Customer onboarding procedure.
Supplier onboarding procedure.
Sanctions procedure.
Restricted-category matrix.
Licence-verification procedure.
Fraud rules.
Manual review procedure.
Complaint register.
Security policy.
Incident response plan.
B.5 Technical records
System diagram.
Data-flow diagram.
API inventory.
Webhook inventory.
Ledger specification.
Reconciliation procedure.
Access-control matrix.
PCI evidence.
Penetration-test report.
Continuity and recovery test.
Decision record template
The final decision record should contain:
The decision authority should sign the record. Legal, finance, product, engineering, security, and operations should sign their assigned sections.