Why Processors Require Regression Testing

Payment processors aren't static. They update their platforms on their own schedules: new features, security updates, protocol changes, infrastructure upgrades. Fiserv updates RapidConnect. TSYS updates their platform. These updates happen independently of anything you're doing on your end, and they can change how your certified payment solution interacts with the processor's host.

When a processor makes significant changes to their platform, they need to know that the gateways and payment solutions certified against that platform still work correctly. Their mechanism for verifying this is a regression test suite: a structured set of test cases that exercises the transaction flows, message formats, and response handling that certified solutions are expected to support.

If you're a certified gateway, the processor will require you to run their regression test suite against the updated platform before you can proceed with any new certification work. In some cases, processors require regression testing on a scheduled basis tied to their platform update cycles, regardless of whether you have active certification projects in flight.

What Regression Testing Actually Looks Like

If you've been through an EMV L3 certification, you're familiar with test suites in the hundreds of test cases. Processor regression test suites are a different scale entirely. We're talking thousands of test cases per processor, covering the full breadth of transaction types, response codes, error conditions, and edge cases that the platform supports.

The test cases typically come in the form of spreadsheets. Each processor formats them differently, uses their own terminology, and organizes them according to their own internal logic. There's no standardized format across the industry. A regression test suite from Fiserv looks meaningfully different from one from TSYS, which looks different from Global Payments. If you're maintaining certifications across multiple processors, you're potentially managing multiple regression test cycles with different formats, different cadences, and different pass/fail criteria.

Unlike EMV certification test cases, regression test cases don't require EMV card data. They're testing transaction message flows rather than chip card processing. That means they can be executed faster than a full EMV cert, without the physical test card setup and reader equipment that an L3 cert requires. The volume is high, but the per-test execution time is lower.

The Timing Problem

Here's where regression testing catches companies off guard: it's on the processor's schedule, not yours.

You can plan your EMV certification projects well in advance, budget for them, and staff accordingly. A processor platform update and the regression testing requirement that comes with it arrives on whatever timeline the processor operates. If Fiserv updates RapidConnect and requires certified gateways to complete regression testing before proceeding with new certification work, that requirement lands on your plate regardless of what else is in your pipeline.

Companies that aren't tracking processor platform update cycles and maintaining readiness to execute regression testing can find themselves in a position where a certification project they've been planning for months is blocked by a regression test cycle they weren't expecting. The project doesn't move forward until the regression testing is complete. That's a delay that has nothing to do with your application, your readiness, or your resources: it's purely a function of not being positioned to respond quickly when the processor requires it.

Every Processor Handles It Differently

The lack of standardization in regression testing is, appropriately enough, consistent with every other aspect of the processor certification landscape. Each processor determines their own update cadence, their own regression test suite format, their own pass/fail criteria, and their own requirements for how results are submitted and validated.

Some processors are more aggressive about requiring regression testing than others. Some tie it explicitly to platform update cycles. Others require it on a more periodic basis. The specific requirements aren't always published clearly in advance, which means that without direct experience working with each processor's certification program, it's easy to be caught flat-footed when the requirement arrives.

This is another area where institutional knowledge of each processor's practices is more valuable than any documentation. Knowing that a specific processor tends to require regression testing on a particular cadence, that their test suite arrives in a specific format, and that their pass/fail criteria have quirks that affect how you set up your test environment: that knowledge comes from having been through the cycle before.

What This Means for Your Roadmap

If you're managing a payment product with certifications across multiple processors, regression testing is a recurring operational reality that should be factored into your planning, not treated as an exception.

Practically, that means maintaining awareness of when each of your processors is likely to update their platform, keeping your test environment current enough to execute regression test cases quickly when required, and having a process for working through thousands of test cases efficiently when the requirement lands.

CertLabs handles regression testing as part of our broader certification support services. When a processor requires a regression cycle, we can execute the test suite quickly and accurately, in the processor's format, without pulling your engineering team off whatever they're currently working on. Given that regression test suites run to thousands of cases per processor, the time savings are significant.

If your certified solutions span multiple processors and you haven't thought through how you'd handle a regression testing requirement on short notice, that's worth getting ahead of.

The Bottom Line

Regression testing is the certification work that doesn't result in a certification. It's unglamorous, high-volume, and entirely on the processor's schedule. But it sits between you and your next certification project if you're not ready for it when it arrives. Know your processors' platform update cycles. Maintain regression testing readiness. And don't let something that has nothing to do with your application quality become the thing that holds up your certification roadmap.

What SoftPOS Is (and Isn't)

SoftPOS (also called Tap to Phone or Tap on Mobile) turns a commercial off-the-shelf (COTS) device (typically an NFC-enabled Android smartphone or tablet) into a payment acceptance terminal. No dedicated hardware. No proprietary card reader. The NFC antenna built into the phone reads the contactless card or mobile wallet, and a certified software application handles the payment processing.

Apple's Tap to Pay on iPhone operates on similar principles but through Apple's own controlled framework, which introduces its own certification considerations.

The key distinction from a certification standpoint: in a traditional device cert, the hardware is purpose-built for payment acceptance and has gone through its own L1 and L2 certification process. In a SoftPOS cert, the hardware is a consumer device never designed for payment acceptance, running a general-purpose operating system, with no hardware-level payment security controls. That distinction drives most of what makes SoftPOS certification different.

L1 Is Waived, But Replaced By Something More Complex

In a traditional device certification, L1 (the physical and electrical interface certification) is the device manufacturer's responsibility. By the time you're doing an L3 cert, L1 is already done and behind you.

For SoftPOS, L1 is formally waived. A consumer smartphone can't meet traditional L1 requirements: the proximity requirements for contactless card reading on a general-purpose NFC antenna don't map cleanly to EMV L1 hardware specs. So the standard L1 certification doesn't apply.

What replaces it is more complex. Because you're running payment acceptance software on a device with no hardware security controls, the entire security model shifts to software and operational controls. This is where PCI's MPoC (Mobile Payments on COTS) standard comes in. MPoC defines the security requirements for SoftPOS solutions: application attestation (verifying the app hasn't been tampered with), device integrity monitoring, runtime threat detection, and remote management capabilities that allow the solution to be disabled if a device is compromised.

Getting a SoftPOS solution PCI MPoC listed is a prerequisite before the L3 certification process can formally begin. That's an entirely separate evaluation, performed by PCI-recognized laboratories, with its own timeline and requirements. It doesn't exist in the traditional device certification world at all.

L2 Is Still Required, But the Kernel Lives Somewhere Different

In a traditional device cert, the EMV kernel is embedded in the device firmware. The OEM owns that kernel and its L2 certification. You inherit a certified kernel when you work with a certified device.

In SoftPOS, there's no OEM in the traditional sense. The solution vendor is responsible for integrating a certified EMV L2 contactless kernel into the application. This is typically done by licensing a kernel SDK from an approved provider: Visa, Mastercard, and others maintain approved contactless kernel SDKs specifically for SoftPOS use cases.

The important implication: the kernel isn't hardware-resident. It's software running on a general-purpose OS alongside every other app on the phone. That creates complexity around how the kernel is isolated, how it's protected from other processes on the device, and how it's updated when card scheme requirements change. In a traditional terminal, a kernel update is a firmware push to a controlled device fleet. In SoftPOS, it's an app update to millions of consumer smartphones running different OS versions.

L3 Is Familiar, With Some New Wrinkles

The L3 process for SoftPOS is structurally similar to traditional L3: you're validating that the application correctly handles EMV transaction flows, communicates properly with the acquirer host, and passes the card scheme test cases. If you've done traditional L3 certs, this part will feel recognizable.

The wrinkles are specific to the SoftPOS context. Cardholder Verification Method (CVM) handling is more complex because SoftPOS introduces CDCVM (Consumer Device CVM): the cardholder verifying their identity on their own device (Face ID, fingerprint, PIN on the consumer's phone) rather than on the merchant's terminal. How CDCVM interacts with traditional CVM methods, and how the test cases validate that interaction, is a new layer that doesn't exist in traditional device certs.

User interface and transaction flow handling gets more scrutiny too. A dedicated payment terminal has a controlled display and input method. A SoftPOS app runs on a general-purpose device with a variable screen size, OS version, and user environment. Test cases validate that the app correctly handles prompts, errors, and transaction states across that variable environment in a way that replicates a certified payment experience.

The Organizational Structure Is Different

In a traditional L3 cert, the cert is driven by the acquirer or their processor, with the gateway or terminal manufacturer as the technical party doing the work. The processor's certification program is the primary structure you're working within.

SoftPOS certification involves more parties. The solution vendor (whoever built the SoftPOS app) has to get PCI MPoC listed independently of any specific acquirer. That listing is then referenced by the acquirer when they initiate the L3 process. Visa's Tap to Phone program and Mastercard's Tap on Phone program each have their own enrollment and approval requirements on top of the standard L3 process. You're not just working within one processor's certification program. You're coordinating across card scheme programs, PCI requirements, and the acquirer simultaneously.

For Mastercard specifically, the acquirer must obtain a Contactless Development License before any development begins: before the L3 process even starts. That's a contractual step with Mastercard that doesn't have a direct equivalent in traditional device certification.

What It Costs and How Long It Takes

Traditional L3 certifications run four to six months in a reasonable scenario, longer if the queue is slow or test failures require rework. The primary cost drivers are engineering time and processor fees.

SoftPOS certification is harder to generalize because of the additional layers. The PCI MPoC evaluation alone adds timeline and cost before the L3 process starts. The multi-party coordination across card scheme programs, PCI, and acquirer adds complexity that translates directly to timeline. Companies that have gone through the process describe it as meaningfully more complex than a traditional device cert, not less. The finish line is further and the path to it involves more distinct milestones.

Should You Be Thinking About SoftPOS Certification?

If you're a gateway provider or ISV and your merchant base includes segments where SoftPOS makes sense (mobile service businesses, delivery, table-side restaurant payments, pop-up retail), then yes, SoftPOS certification is probably on your medium-term roadmap whether you've formally acknowledged it or not.

The strategic point from our earlier post on this topic stands: SoftPOS doesn't replace your traditional processor certifications. It sits alongside them. A gateway that supports Tap to Phone but isn't certified against Fiserv and TSYS for traditional card-present transactions isn't a complete gateway. The SoftPOS certification work is additive, not substitutional.

What it does change is the total certification workload and the skillset required to execute it. Traditional L3 experience transfers partially but not completely. The PCI MPoC requirements, the kernel SDK integration, the CDCVM handling, and the multi-party coordination are genuinely new territory for teams that have only done traditional device certs.

CertLabs is tracking SoftPOS certification developments closely as this becomes a more common requirement for our clients. If you're trying to understand what a SoftPOS certification program would look like alongside your existing processor roadmap, that's a conversation worth having before you're in the middle of it.

The Bottom Line

SoftPOS certification covers the same end goal as traditional device certification: a certified payment solution that can process transactions on a processor's network. The path to that goal is meaningfully different. L1 is waived but replaced by PCI MPoC. L2 kernel management is more complex. L3 has new wrinkles around CDCVM and UI validation. The organizational structure involves more parties and more prerequisites. And the total timeline and cost reflects that complexity. It's not harder because the technology is worse. It's harder because turning a consumer smartphone into a secure payment terminal requires solving security problems that dedicated hardware solves for free.

Visa and Mastercard: The Baseline

Visa and Mastercard are the largest networks and have put the most resources into their certification programs. Their test plans are the most mature, the most thoroughly documented, and the most consistently maintained.

Both programs are well-established and reasonably reliable. The test cases are clearly described, the expected outcomes are well-defined, and when something fails it's usually because something in your application needs fixing rather than because the test case itself is ambiguous. Neither program is frictionless. Test case updates, tool version changes, and the processor-specific variations discussed in our previous post all introduce complexity. But as a baseline for what a well-run card brand certification program looks like, Visa and Mastercard set the standard.

Mastercard's process has an additional organizational layer worth knowing: the acquirer works through an accredited service provider rather than directly with Mastercard's certification program. That adds a coordination step but also means there's an experienced intermediary who knows the process and can help navigate it.

American Express: Smaller Program, Distinct Process

Amex runs a smaller certification program than Visa or Mastercard, which shows up in the tooling and process structure. Amex uses their own testing tool (ATS) for host tests, which requires separate access and setup on the processor side. The program also tends to be less flexible about process exceptions and scheduling. If you're planning a multi-brand certification and trying to run all four card brands in parallel, Amex is often the one that disrupts the timeline through process friction rather than technical complexity.

Discover: A Category of Its Own

Discover is, to put it diplomatically, the most challenging card brand certification program to work with. And the challenge isn't primarily about Discover transactions being technically complex. It's about test plan quality.

Discover's D-PAS (Discover Payment Application Specification) test plan has a well-earned reputation among people who've been through it for test case descriptions that don't reliably match the expected results. What the test case says it's testing and what the test tool actually validates can be two different things. For anyone running their first Discover cert, this creates a specific and painful failure mode: something fails, you read the test case description, you go looking for the problem the description points to, and you don't find it. Because the problem the description points to isn't the actual problem. The test case is just poorly written.

The consequence of this plays out in slow motion. Your team spends time investigating an issue in your application that doesn't exist. When they don't find it, they look harder. Eventually someone questions whether the problem might be in the device firmware or the EMV kernel rather than the application layer. You escalate to the OEM. The OEM investigates. The OEM doesn't find a problem either, because the problem was never in your application or their firmware. It was in Discover's test plan description all along.

This isn't a hypothetical scenario. It happens regularly to teams going through Discover certification for the first time, and it happens even to experienced teams on test cases they haven't encountered before. The wild goose chase that results from misidentifying a test plan problem as your own implementation problem is one of the more expensive failure modes in the certification process, measured in engineering hours and calendar time.

The practical defense against it is knowing Discover's test plan well enough to recognize when a failure pattern doesn't match what the test case description implies, and having enough cross-brand experience to distinguish "this looks like an application bug" from "this looks like a test plan bug." That distinction is genuinely hard to make if you haven't seen it before.

JCB and CUP: The Surprising Part of the Discover Test Plan

One thing that surprises people going through Discover certification for the first time: JCB and China UnionPay (CUP) test cases are bundled into the Discover test plan. Discover, JCB, and UnionPay have a long-standing network alliance that means accepting Discover also means accepting JCB and CUP in international contexts.

The irony is that the JCB and CUP sections of the Discover test plan tend to be more reliable than the Discover-specific sections. The test case descriptions are clearer, the expected outcomes are more consistently defined, and failures in those sections more reliably point to actual issues in your application. For teams working through a Discover cert and losing confidence in the test plan, the JCB and CUP sections are usually a relative bright spot.

What This Means Practically

The most important practical implication of card brand differences is timeline planning. If you're running all four brands in parallel (which you should be, for the same reasons discussed in our post on parallel certifications), the brands don't finish at the same time. Visa and Mastercard tend to move most smoothly. Amex adds process friction that can delay their portion even when the technical work is straightforward. Discover adds unpredictability through test plan quality issues that are hard to budget for because you don't always know in advance which test cases are going to send you down a rabbit hole.

Building extra buffer into your Discover timeline specifically is not pessimism. It's experience.

The other implication is about who's running the certification. Familiarity with each brand's test plan (including knowing which parts of the Discover test plan have historically been problematic and how to recognize a test plan issue versus an application issue) is the kind of knowledge that comes from repetition. Teams doing their first multi-brand cert are essentially paying tuition on all of this. Teams working with a consultant who's been through it before aren't.

CertLabs has run certifications across all four major card brands, including the full Discover D-PAS test plan with its JCB and CUP components. Knowing where the test plan problems tend to show up and how to recognize them quickly is one of the more concrete ways that experience translates into faster certification timelines.

The Bottom Line

Visa and Mastercard set a reasonable standard for what card brand certification programs can look like. Amex adds process friction. Discover adds test plan unpredictability that can send experienced engineering teams chasing problems that don't exist in their code. The teams that know the difference going in plan their timelines accordingly and don't spend three weeks escalating to an OEM over a test case description that was wrong to begin with.

Why the Gap Exists

EMVCo publishes the EMV specification. It defines how chip card transactions should work: the data elements, the transaction flow, the cryptographic requirements, the cardholder verification logic. Every processor, every card brand, every terminal manufacturer is nominally building to the same spec. In theory, a payment application that passes one processor's certification should pass any processor's certification, because they're all testing compliance with the same standard.

In practice, each processor takes the EMV spec and writes their own test cases based on how their host system actually processes transactions. And their host system doesn't implement every edge case of the EMV spec identically to another processor's host. Two processors can both be fully EMV compliant and still have meaningfully different expectations for how your application should behave in specific scenarios.

Nobody publishes this gap. There's no document that says "here's where Fiserv diverges from TSYS." You learn it by going through the certifications, failing test cases you didn't expect to fail, and building up institutional knowledge of what each processor actually looks for versus what the spec says.

After 30+ certifications across Fiserv, TSYS, Global Payments, Chase Paymentech, Worldpay, and Elavon, the patterns are recognizable. Here's where they show up most consistently.

Fallback Transactions

The EMV spec defines how a terminal should handle a chip card that can't be read: attempt the chip read a prescribed number of times, then fall back to magnetic stripe. The logic is standardized. What isn't standardized is how each processor's test suite validates that fallback behavior.

Processors have different expectations around how many fallback attempts should be made before the terminal gives up, what error code should appear in the transaction message, what the terminal should display to the cardholder during the process, and whether certain fallback scenarios should be declined outright rather than processed. Pass Fiserv's fallback test cases and you may still fail TSYS's because they're looking for subtly different behavior in the same scenario. The underlying EMV implementation is identical. The test case expectations are not.

CVM Limits

Cardholder Verification Method (CVM) limits are configurable parameters in your payment application that determine when a transaction requires PIN, signature, or no CVM at all. Each processor's test environment is configured with specific values for these thresholds, and their test cases validate that your application handles CVM decisions correctly at those values.

The problem is that processors configure these differently in their test environments. A CVM limit scenario that passes cleanly in one processor's test environment can fail in another's because the parameter values are different, even though your application logic is identical. Teams that don't account for this end up spending time debugging what looks like a CVM implementation bug when it's actually a test environment configuration mismatch.

Partial Approvals

Partial approval is the scenario where a cardholder's account has insufficient funds to cover the full transaction amount and the issuer approves a lesser amount instead. The EMV spec defines how this should work. Not every processor tests for it with the same rigor.

Some processors include partial approval scenarios prominently in their test suite. Others treat it as a lower-priority edge case. If your application isn't coded to handle a partial approval response correctly (updating the transaction amount, prompting the cardholder for the difference, handling the decline of the remaining balance) you may not discover it until you're in a certification with a processor that tests for it heavily. At that point you're looking at a code change, a retest, and a delay you didn't budget for.

Timeout Reversal (TOR) Testing

When a transaction times out mid-flow (the authorization request goes out but no response comes back within the expected window) the terminal is supposed to send a reversal to ensure the transaction isn't left in a pending state on the host. This is timeout reversal, and it's one of the more nuanced areas of EMV certification because the timing parameters, the reversal message format, and the expected host behavior vary across processors.

Every processor tests for TOR. None of them test for it exactly the same way. The timeout window that triggers a reversal, the specific message fields required in the reversal, and how the processor's test tool simulates the timeout condition all differ. An application that handles TOR correctly for one processor can fail TOR test cases at another because the reversal message doesn't match what that processor's test tool is looking for, or because the timeout simulation behaves differently than expected.

TOR failures are particularly disruptive because they're not always obvious during development. The happy path works fine. It's only when the test tool deliberately withholds a response that the reversal logic gets exercised, and that's not something most teams test thoroughly in their own environment before the formal certification.

Transaction Flow Timing

The EMV spec defines the sequence of steps in a transaction but doesn't prescribe tight timing requirements between them. Processors can have timeout expectations baked into their test cases that aren't obvious from reading the spec. An application that is technically EMV compliant can fail test cases because a particular step (card data processing, cryptogram generation, authorization message construction) is taking slightly longer than the processor's test tool expects.

This one is particularly hard to diagnose because the failure doesn't look like a logic error. The transaction flow is correct, the data is correct, the message is correct. It just took 200 milliseconds longer than the test tool was willing to wait. You don't see this category of failure until you're in the test environment, and by then you're already in the certification queue.

What This Means Practically

The structural cause of all of these divergences is the same: each processor built their host system independently, wrote their test cases to match their own implementation, and those implementations accumulated differences over years of development without any central authority enforcing consistency. EMVCo defines the spec. Nobody enforces that processor test cases map to it identically.

For teams managing their own certification programs, the implication is that every new processor should be treated as a first certification, regardless of how many prior certifications your application has passed. The testing environment is different. The test case priorities are different. The edge cases being scrutinized are different. Assuming otherwise is the most reliable way to get surprised.

For teams considering outside help, this is precisely the kind of institutional knowledge that's hard to build internally and easy to underestimate the value of. Knowing that Processor A tests TOR differently than Processor B, that Processor C's partial approval test cases are more comprehensive than Processor D's, and that a specific CVM edge case that never came up in your first three certs will definitely come up in your fourth: that knowledge comes from repetition across processors, not from reading the spec.

CertLabs has run certifications across Fiserv, TSYS, Global Payments, Chase Paymentech, Worldpay, and Elavon. The processor-specific test case patterns are familiar territory. If your team is heading into a certification with a processor you haven't worked with before, that's exactly the kind of engagement where outside experience pays for itself quickly.

The Bottom Line

Passing one processor's EMV certification means your application is EMV compliant and that you understand that processor's test case expectations. It does not mean you're ready for the next processor. The spec is shared. The test cases are not. The teams that know the difference go into new certifications with realistic timelines and appropriate preparation. The teams that don't find out the hard way.

What's Actually Happening in the Queue

Processor certification teams are internally funded and internally prioritized. There's no published policy that says "we process our own integrations first." There doesn't need to be. It emerges naturally from how resources get allocated inside large organizations. A Clover integration gets Fiserv's attention faster than a third-party gateway's L3 cert. A Global Payments proprietary terminal moves through the queue ahead of an ISV that competes with their software portfolio. Nobody at the processor is going to tell you this directly. But if you've been through enough certifications to have a before-and-after sense of queue behavior, you've felt it.

The OEM tier sits in the middle. Processors depend on Ingenico, Verifone, PAX, and Equinox for their own certified hardware deployments. Alienating those relationships would be self-defeating, so they get treated reasonably well. Third-party gateways and ISVs are at the back of an informal pecking order that nobody officially acknowledges.

The result is that timelines that used to run four to five months now routinely stretch to six, eight, or longer for third-party submissions. When you ask the certification team why, you get polite non-answers about queue volume and resource constraints. Both of those things are technically true. They're just not the whole story.

Is This Anti-Competitive?

In spirit, almost certainly. In practice, it's complicated.

The U.S. payments industry is regulated across the Fed, OCC, and CFPB, none of whom have taken a strong stance on certification queue prioritization specifically. The argument that processors are using control of their certification queues to disadvantage competing software and gateway providers is structurally similar to arguments made against Apple's App Store and Google's Play Store. Those cases have moved slowly and inconsistently. Payment processing is a less visible industry and gets even less regulatory scrutiny.

The FTC blocked the Visa/Plaid acquisition, which showed some appetite for policing payments consolidation. But queue behavior is subtler than an outright acquisition and harder to prove as deliberate policy. For now, it's a market reality that third-party providers have to navigate rather than a problem anyone is rushing to fix.

What You Can Actually Do About It

Complaining about the queue doesn't move you up in it. Here's what does.

The single most important variable in how quickly a processor certification team engages with your submission is the quality and completeness of what you send them. Certification teams deal with a high volume of incomplete, poorly organized submissions from vendors who don't fully understand the format requirements. A complete, well-structured submission package that anticipates the team's questions doesn't just move faster through review; it signals that the submitter knows what they're doing, which affects how the team prioritizes their responses.

Understanding each processor's specific submission format and documentation requirements matters more than most people realize. Those requirements vary significantly across Fiserv, TSYS, Global Payments, Chase Paymentech, and Elavon, and they change more often than the documentation reflects. Knowing what a given processor's certification team actually wants to see (versus what their published specs say) comes from having been through the process with them repeatedly. That's institutional knowledge of the process, not personal relationships, and it doesn't evaporate when a certification team rotates its staff.

Being responsive when the certification team reaches out is also more consequential than it sounds. Even a 24-hour delay in answering a clarification question can push you back significantly in a queue that moves in batches. Having someone dedicated to managing processor communication (someone who knows the context of every open question and can respond the same day) is one of the most underrated factors in keeping a certification on schedule. It's also exactly the kind of thing CertLabs handles as part of every engagement, including our same-business-day response commitment that extends to processor communication on your behalf.

Starting earlier than you think you need to is the last piece. If your product roadmap calls for a certification complete by Q4, you need to be in the queue by Q1. The buffers that used to work no longer do in an environment where third-party submissions are moving more slowly than they once did.

The Parallel Certification Angle

There's one more lever worth understanding in this context. If you're certifying against multiple processors and doing it sequentially, slower queues compound painfully. Six months becomes eight, and then you multiply that by three or four processors and suddenly you're looking at years of sequential certification work to achieve full processor coverage.

Parallel certification programs are even more valuable in a slow-queue environment than they are in a fast one. The calendar time savings are real regardless of queue speed, but when queues are slow the cost of sequential processing is even higher. Getting into three processor queues simultaneously (through a third-party partner who can hold certifications under a separate organizational entity, since most processors won't allow the same organization to hold multiple concurrent certs) is the most effective hedge against queue slowdowns that exists right now. It's the core of what CertLabs was built to do.

The Bottom Line

The queue slowdown for third-party certifications is real, it's structural, and it's probably not going to reverse as processors continue investing in their own vertically integrated solutions. The companies that navigate it successfully will be the ones that treat certification as a process requiring institutional expertise, not just technical execution; start earlier than they think they need to; and use every available tool to compress timelines on their end even when the processor's end is moving slowly.

If your certification timelines have been stretching and you're trying to figure out what to do about it, that's exactly the conversation CertLabs exists for.

What SoftPOS Actually Changes

Let's be clear about what SoftPOS genuinely disrupts. For merchants doing low-to-medium volume in environments where a dedicated terminal is inconvenient; pop-up shops, service businesses, delivery drivers, table-side restaurant payments; SoftPOS is a real and growing alternative to traditional hardware. The friction of buying, deploying, and certifying a dedicated terminal disappears. That's meaningful.

For the ISV or gateway provider serving those merchants, SoftPOS also changes the integration story. Instead of certifying a hardware terminal against a processor, you're certifying a software kernel. The certification is still required; it just targets a different layer of the stack. Visa's Tap to Phone program requires its own certification process. Apple Tap to Pay has its own approval requirements. These are not lighter-weight processes than traditional L3 certs. In some ways they're more complex, because the security requirements for running payment acceptance on a general-purpose consumer device are substantially higher than for dedicated hardware.

So SoftPOS doesn't eliminate certification. It shifts what you're certifying.

What SoftPOS Doesn't Change

Here's what tends to get lost in the SoftPOS enthusiasm: the vast majority of card-present transaction volume in the U.S. runs through dedicated hardware, and that is not changing on any near-term timeline.

Retail point-of-sale systems, fuel pumps, ATMs, kiosks, transit fare gates, hotel check-in terminals, healthcare payment systems. None of these are candidates for SoftPOS. The use cases that require a fixed, ruggedized, purpose-built payment device are enormous, and they represent the bulk of where EMV L3 certification matters. A fuel pump is not going to become an iPhone. A pharmacy checkout lane is not going to run on a consumer Android device. These environments require dedicated certified hardware, and they will for a long time.

For terminal manufacturers, this means your existing certified product lines are not going obsolete because of SoftPOS. The merchants who need your hardware still need your hardware. The processors who require L3 certification for those environments still require it.

For gateway providers, the picture is similar. Supporting SoftPOS may become a requirement for certain merchant segments, but it sits alongside your traditional processor certifications, not in place of them. A gateway that supports Tap to Pay on iPhone but isn't certified against Fiserv and TSYS for traditional card-present transactions is not a complete gateway.

The Coexistence Period Is Long

Even in the scenarios most favorable to SoftPOS, the transition away from dedicated terminal hardware will take decades, not years. The U.S. payment infrastructure is enormously capital-intensive. Terminals have multi-year depreciation cycles. Processor certification programs are built around hardware assumptions that won't be unwound quickly. Merchants who invested in certified terminal fleets are not replacing them with smartphones next quarter.

What's more likely is a long coexistence period where SoftPOS captures new merchant segments and certain use cases, while traditional certified hardware continues to dominate the environments where it's already entrenched. Gateway providers and terminal manufacturers that navigate this well will be the ones who have both: a complete traditional certification portfolio and the ability to support SoftPOS where the market demands it.

The companies that lose ground will be the ones who use SoftPOS as a reason to defer their traditional certification roadmaps. That's a bet that the disruption arrives faster and more completely than any reasonable forecast supports.

What This Means If You're Mid-Roadmap

If you have traditional processor certifications still to complete, SoftPOS is not a reason to slow down. If anything, the emergence of SoftPOS as an additional certification requirement makes the total certification workload larger, not smaller. You're not trading one cert type for another; you're adding a new category of certification to an existing roadmap.

CertLabs is already working with clients on both sides of this. Traditional L3 certification programs across Fiserv, TSYS, Global Payments, Worldpay, and Elavon remain the core of what we do. But the SoftPOS certification questions are coming up in more conversations, and the answers aren't simple. If you're trying to figure out how SoftPOS fits into your certification strategy alongside your existing processor roadmap, that's a conversation worth having sooner rather than later.

The Bottom Line

SoftPOS is real, it's growing, and it will capture meaningful market share in certain segments. It is not a reason to stop certifying against traditional processors, and it's not going to make your existing certified terminal portfolio irrelevant anytime soon.

The most likely outcome for the next decade is more certification complexity, not less. New payment modalities mean new certification requirements layered on top of existing ones. The companies best positioned for that world are the ones that get their traditional certification house in order now, while simultaneously building a strategy for what comes next.

Probably not the last cert you'll need. Almost certainly not.