A customized test transaction is an automated, controlled simulation of a real user checkout flow on a target merchant's website designed to capture, with evidence, exactly what happens when a payment is initiated. For acquirers, PSPs, and payment facilitators, it is the only reliable way to know with certainty which processor a merchant is currently using, how transactions are actually being routed, and what payment methods are live at the checkout layer.
Most of what passes for competitive intelligence in payments is inferred from surface signals: declared logos, embedded scripts, public registrations. That inference is workable for the simplest setups and unreliable for everything else. Modern checkouts route through multiple intermediaries, host payment forms on third-party domains, white-label gateways, and use redirect chains that make the actual processor invisible to anyone watching from outside the browser. Test transactions cut through that opacity by performing the action, initiating a payment and recording what the action exposes.
This guide explains what customized test transactions actually do, why they are a different category of intelligence than scraping, and what to look for in a provider that runs them at the depth and scale modern acquirer GTM and risk programs need.
Why static merchant data is no longer enough
Acquirer sales teams have spent decades operating on merchant data sourced from third-party databases, association lists, and inference from public-facing signals. That model worked when payment stacks were simple and stable. It does not work now.
The first reason is that modern checkout architectures are designed in ways that hide the processor by default. Hosted payment fields, iframe-based checkouts, redirect-based flows, and tokenization layers all push the actual payment endpoint outside what an external observer can see from the merchant's site. The logo at the checkout page is a marketing signal; the actual processor handling the transaction is frequently a different entity that never appears on the page.
The second reason is the rise of orchestration and gray-label routing. A meaningful share of mid-market and enterprise merchants now run payment orchestration layers that route transactions across multiple processors based on cost, geography, or fraud rules. The merchant's "primary" processor as declared on the site may handle a small share of actual volume; the rest goes through processors the merchant has no contractual reason to advertise. From the outside, the orchestration layer is invisible.
The third reason is that decisions made on inferred data are systematically biased. Sales teams targeting prospects based on what the website appears to show waste a large share of effort on merchants who turn out to already be processing through the targeting acquirer's competitors or, worse, through the targeting acquirer itself. Test transaction-based intelligence corrects that bias by producing definitive answers to the questions sales teams need to answer before they make a call.
What customized test transactions actually cover
A customized test transaction is more than just hitting a checkout button. The intelligence value comes from the depth of what the simulation captures.
Real checkout journey simulation
The foundation is a controlled, automated traversal of the merchant's actual checkout flow — adding products to cart, proceeding to checkout, entering payment details, and capturing the full set of network events, redirects, and endpoint URLs that the flow produces. The simulation has to behave like a real user; checkouts that detect automation typically respond by serving a different flow, which is the exact opposite of what the intelligence requires.
The output of the simulation is a structured record of the transaction path: every URL touched, every script loaded, every redirect followed, every payment endpoint hit. That record is what makes the rest of the analysis possible.
PSP and acquirer detection
The primary intelligence output is the identity of the processor handling the transaction. In simple cases, the answer is in the payment endpoint URL — the domain hit when the card details are submitted. In complex cases, the answer requires correlating the endpoint with metadata, BIN-routing patterns, and processor-specific fingerprints to identify the actual entity behind a white-labeled or orchestrated flow.
Working programs identify the current PSP or acquirer in over 70% of tested merchant flows. The remaining cases are typically merchants with sophisticated orchestration setups where multiple processors share volume; even there, the test transaction produces evidence about at least one of the active processors, which is more than inference produces.
Hidden routing and gray-label setups
This is where the intelligence value compounds. A test transaction can expose third-party routing arrangements, hidden acquirer IDs, and gray-label payment setups that the merchant has no commercial incentive to advertise. The evidence is structural — endpoint URLs, processor metadata, BIN-routing behavior — and it surfaces relationships that no public signal would reveal.
For acquirers, this is direct competitive intelligence: a confirmed list of merchants currently using competing processors, with the evidence to support targeted conquest outreach. For risk teams, the same intelligence has a different value: hidden routing at a merchant who declared a different processing relationship is itself a compliance signal that warrants investigation.
APM and wallet detection at the checkout
The checkout simulation also captures the full set of payment methods presented at the actual checkout; the wallets, BNPL providers, local APMs, and alternative payment methods that the merchant is actively offering. This data is materially more reliable than scraping the merchant's published payment-method icons, because the checkout reflects what the merchant has actually integrated, not what the marketing page implies.
The intelligence supports both sales and product targeting. A merchant whose checkout shows three competitor wallets but no local APM in a region the merchant operates is a high-conviction cross-sell prospect. A merchant whose declared APM list at marketing time differs from the actual checkout offering is a different kind of signal.
Test transactions vs. surface-level web scraping
A common confusion: that comprehensive web scraping should be able to produce the same intelligence as test transactions. It cannot, and the gap is structural.
Web scraping operates on what the merchant's pages publish — HTML content, embedded scripts, declared payment-method icons, marketing copy. Sophisticated scraping is genuinely useful, and it produces a meaningful share of merchant intelligence at scale. But it sees only what the merchant has chosen to make visible at the page level, and the most consequential elements of the payment stack — actual processor, real-time routing, true APM availability — typically are not at the page level.
Test transactions operate on what the merchant's flow actually does. The intelligence comes from network events, endpoint URLs, and runtime behavior, none of which are accessible from passive scraping. A site can declare one processor on its marketing page and route through five others at runtime; scraping sees the declaration, the test transaction sees the routing.
The two techniques are complementary, not interchangeable. A working merchant intelligence program runs both, with scraping handling breadth and test transactions handling depth on the merchants that warrant it. Acquirers that depend on scraping alone end up with confidently incorrect competitive maps; acquirers that run targeted test transactions get the resolution to make sales decisions they can stand behind.
How customized test transactions work in practice
A working test transaction program runs as a controlled, evidence-producing operation rather than an ad-hoc exercise.
Targeting starts with the prospect list. Test transactions are expensive to run at scale, so they are concentrated on the merchants where the intelligence matters most — high-value prospects, competitive accounts, suspicious portfolio members, or merchants whose declared payment stack does not match what the broader intelligence suggests. The targeting decision happens before the test, not during it.
Execution runs in controlled environments designed to behave like real users. Anti-automation defenses on modern checkouts are sophisticated, so the test environment has to be as well — proxying through residential IPs, mimicking browser behavior, handling the full checkout flow rather than skipping steps. Tests that get detected and re-routed to a fallback flow produce no useful intelligence.
Capture is automatic. Network events, endpoint URLs, redirect chains, screenshots, and payment-method offerings are all recorded with timestamps, ready for analysis and export. Evidence handling matters because the intelligence has to be defensible — sales teams making calls based on the data need to point to specific evidence, and risk teams using the data for compliance investigations need an audit trail.
Analysis produces the structured intelligence output: identified processor, detected APMs and wallets, evidence of hidden routing, and any compliance signals the test surfaced. The output flows into the systems the teams already use — CRM for sales, case management for risk — through APIs, with the underlying evidence file attached.
Test transaction signals: what the data is telling you
The most useful test transaction signals fall into three categories.
Direct processor identification is the obvious one. A confirmed processor identity for a target merchant is intelligence the sales team can act on immediately — it changes the conversation, the timing, and the value proposition. Working programs convert this signal into a 35–50% reduction in outreach cycle time and a 3x improvement in conversion when paired with structured lead generation.
Hidden routing detection is the second. A merchant whose test transaction reveals routing through a processor different from what they have declared, or who appears to operate through orchestration shared across competitors, is producing intelligence with both sales and risk implications. The sales implication is competitive opportunity; the risk implication is potential disclosure inconsistency.
APM and wallet gap detection is the third. The checkout offering is the ground truth for what the merchant has actually integrated. A test transaction that captures the live offering, compared against what the merchant could plausibly support given their geography and vertical, surfaces concrete gaps — the wallets they should have, the BNPL options that fit their AOV, the local APMs that match their visitor map. Gap intelligence is what converts payment channel intelligence into prioritized cross-sell.
What to look for in a test transaction provider
When evaluating customized test transaction providers, the questions that matter are about reliability, depth, and evidence handling. Does the provider's test environment behave reliably like a real user, or does it get detected and routed to fallback flows that distort the intelligence? Does it capture the full network event stream, or only the surface page? Does it identify the actual processor in complex orchestration setups, or only in simple direct-routing setups?
Evidence handling is the second filter. Test transaction outputs need to be exportable as structured evidence files — endpoint URLs, screenshots, network events — that sales teams can use for credibility and risk teams can use for audit. Without evidence handling, the intelligence is anecdotal.
Integration is the third. Test transaction outputs should flow directly into the CRM and case management systems the teams already use, with the evidence attached. Test transaction tools that produce output only in their own UI create operational friction and inconsistent records.
Volume scaling is the fourth, and it pulls against the others. A provider that can run high volumes cheaply is unlikely to be running the depth of simulation that produces reliable intelligence; a provider running deep simulations is unlikely to scale to the volumes typical of broad portfolio analysis. The right answer for most acquirers is a targeted approach — high-depth tests on the merchants that matter most, integrated with broader scraping for breadth.
How Onlayer automates customized test transactions
Onlayer's Customized Test Transaction is purpose-built to expose competitor footprints and validate merchant payment infrastructure with evidence. The service executes automated test transactions simulating real user checkout flows across target merchant websites, identifying the current PSP or acquirer in over 70% of tested merchant flows — including in complex cases of hidden routing and gray-label payment setups that surface scraping cannot detect.
For competitive intelligence, the service captures complex payment redirection flows, extracts exact payment processor URLs, flags third-party routing and hidden acquirer IDs, and identifies explicit payment processors and APM usage across high-value merchant segments. Sales teams receive real checkout screenshots, exact URLs, and underlying metadata as exportable reports that flow directly into CRM workflows.
The service pairs natively with Onlayer's Lead Generation Service to drive strategic, data-backed acquisition campaigns — converting test transaction intelligence into prioritized outreach lists where the value proposition is built around what the test actually exposed. Payment Channel Intelligence operates alongside, scanning live checkout pages at scale for active wallets, BNPLs, and local APMs across more than 100 global methods, so the depth of test transaction intelligence combines with the breadth of automated checkout analysis in a single connected workflow.
For risk teams, the same evidence supports Transaction Laundering Detection and Merchant Monitoring Service workflows — confirming actual payment endpoints when declared and observed routing diverge, which is exactly the signal pattern that catches sophisticated laundering operations before they scale.
