For independent software vendors handling payments, security is not a checkbox. It is the architecture you inherit the moment you start processing transactions through your software. It shapes your merchant relationships, your liability profile, and your operating complexity for years.

Most ISVs evaluating a payment platform underestimate this. They focus on the headline capabilities. They look at the API. They negotiate on fees. Security and compliance get treated as a vendor problem.

It is not a vendor problem. It is your problem, with the vendor’s architecture as the starting point.

This is a framework for thinking about payment security and compliance the way ISVs actually need to. It covers what to look for in a payment provider, what you remain responsible for, and where the real risk sits when you embed payments into your software.

Why payment security is different for ISVs

When you embed payments into a vertical software platform, you are not just a payments user. You are part of the payment infrastructure your merchants depend on. The security model becomes a stack.

The payment provider handles transaction-level security: encryption, tokenization, fraud detection, PCI scope.

You inherit the security posture of how you integrate that provider into your platform: where card data touches your systems, how you authenticate API calls, how you store sensitive tokens, how you handle merchant verification.

Your merchants depend on both layers working together. A breach in either one damages their business and yours.

This stacked responsibility is the structural reason ISVs need a different evaluation framework than the one a single-merchant SaaS company would use. You are evaluating security architecture for an entire downstream merchant base, not just for your own operations.

The seven layers of a payment security framework

A complete payment security framework for ISVs covers seven layers. Each addresses a specific threat surface. Each is a structural choice that compounds over time.

1. Encryption

Every payment platform encrypts data. The question is where and how.

End-to-end encryption (E2EE) means card data is encrypted at the point of capture and stays encrypted until it reaches the payment processor. The card data never lands unencrypted on your servers. This is the architectural decision that most meaningfully reduces your PCI scope.

Transport Layer Security (TLS 1.2 or higher) protects data in transit between your systems and the payment platform. This is standard, but the version matters. TLS 1.0 and 1.1 are deprecated and should not appear anywhere in your payment stack.

Encryption at rest covers tokens, customer records, and any payment-adjacent data your platform stores. AES-256 is the standard.

2. Tokenization

Tokenization replaces sensitive card data with a non-sensitive token your system can store and reference without holding actual card information.

There are two main types: provider tokens and network tokens.

Provider tokens are issued by your payment platform and work within that platform’s ecosystem. They are useful for recurring charges, refunds, and account updater flows.

Network tokens are issued by the card networks (Visa, Mastercard) directly. They survive across processors, automatically update when cards are reissued, and lower interchange because the networks treat them as lower risk than primary account numbers. Network token adoption is becoming the new baseline for any payment platform serious about both security and acceptance rates.

3. Authentication

Authentication covers two distinct surfaces: how you authenticate API calls to the payment platform, and how the cardholder is authenticated during a transaction.

API authentication: API keys, OAuth, and signed requests. Multi-tenant API key architecture matters here. If your platform serves hundreds of merchants, your authentication model needs to scope access cleanly so a breach of one merchant’s credentials cannot cascade.

Cardholder authentication: 3D Secure (3DS) and the newer 3DS2. These are challenge protocols that verify the cardholder during a transaction. The major impact is the liability shift. When 3DS authentication succeeds, the liability for fraudulent chargebacks moves from the merchant to the card issuer.

For ISVs whose merchants face high card-not-present fraud exposure (subscription billing, ecommerce, telehealth, fitness memberships), 3DS is not optional. It is the structural defense.

4. Fraud detection

Fraud detection is moving from rule-based systems to AI-driven risk models. The shift is not cosmetic.

Rule-based systems catch patterns someone has already coded into the rules. They are good at known fraud. They miss anything that does not match the rule structure.

AI risk models identify pattern anomalies in real time. They catch fraud the rule engine would have approved. They learn from your transaction history, your merchant base, and the broader network of activity across the platform.

The CSIPay Fraud and Risk Model flags transactions a rule-based engine would approve, and it does so without adding latency to the approval flow.

For ISVs, the practical impact shows up in two places. Fewer chargebacks, because more fraud is caught before authorization reaches the issuer. Fewer false positives, because the model is better at distinguishing legitimate merchants from synthetic fraud patterns.

5. Access controls

Access controls cover who inside your organization and your merchants’ organizations can see, change, or extract payment data.

Role-based access control (RBAC) lets you define what different user types can do. A finance team member needs access to settlement reports. A support agent might need to see transaction status but not card details. A developer might need API access in a sandbox but not production. RBAC is how you make those distinctions structural rather than informal.

Defining roles answers what someone can do. Authentication answers whether the person logging in is actually who they claim to be. That is where multi-factor authentication comes in.

Multi-factor authentication (MFA) combines something the user knows (a password) with something they have (a one-time code or hardware key) or something they are (a biometric). Requiring both means a stolen password alone is not enough to get into the payment dashboard. Single-factor authentication is the structural risk that MFA exists to remove, and it is the reason MFA is non-negotiable for any admin-level access to the payment stack.

The remaining controls sit underneath authentication. Session management defines how long an authenticated session lasts and how it terminates. IP allowlisting limits where admin access can originate. Audit logs record every consequential action taken inside the payment dashboard. Together they make sure that even after a user is authenticated and authorized, every meaningful action leaves a trace.

6. Monitoring and detection

Monitoring covers continuous visibility into the security posture of the payment stack. It includes transaction monitoring for unusual patterns, infrastructure monitoring for system health, and security monitoring for threats.

Transaction monitoring looks at sudden spikes, geographic anomalies, and velocity issues. Infrastructure monitoring covers uptime, latency, and error rates. Security monitoring covers intrusion attempts, suspicious access patterns, and anomalous API behavior.

The 99.9 percent uptime SLA that CSIPay maintains is a function of this monitoring layer. Uptime is not just about availability. It is about catching problems before they become outages. The same monitoring data also powers the analytics layer covered in our Payment Analytics for SaaS pillar.

7. Incident response

The first six layers are about prevention. The seventh is about what happens when something goes wrong.

An incident response framework defines how breaches are detected, who is notified, how merchants are communicated to, what the regulatory reporting timeline is, and how the platform recovers.

For ISVs, the incident response capability of your payment provider is something you inherit. If your provider takes 72 hours to communicate a breach, your merchants find out from you 72 hours late. That is your problem.

PCI DSS Level 1 v4.0.1: what changed and why it matters

PCI DSS Level 1 is the highest tier of compliance for payment platforms, required for organizations processing more than 6 million transactions per year. Version 4.0.1 is the current enforced standard, with significant changes from previous versions.

The main shifts:

Risk-based scoping. Organizations are now expected to identify and document their specific risk profile and implement controls tailored to those risks, rather than apply a one-size-fits-all checklist.

Stronger authentication requirements. MFA is required for all access into the cardholder data environment, not just remote access.

Increased focus on third-party risk. Payment platforms are accountable for the security posture of their integration partners. This affects ISVs directly. If your integration with the payment platform is poorly secured, the payment platform’s compliance is affected.

Customized validation. Organizations can demonstrate compliance through either defined approaches (the traditional checklist) or customized approaches that meet the underlying intent. This is more flexibility but also more documentation burden.

For ISVs, the practical impact is twofold. Your payment platform must be Level 1 compliant under 4.0.1. Your integration with the platform also needs to be designed in a way that does not increase PCI scope unnecessarily. CSIPay maintains Level 1 certification under the current standard, meaning you inherit a compliant foundation rather than building one from scratch.

PCI scope reduction is the architectural goal. The less of your platform that handles card data, the less of your platform is subject to PCI audit and oversight. Tokenization, hosted payment pages, and clean API design are the three primary tools for scope reduction.

AML and KYC compliance for SaaS

Anti-Money Laundering (AML) and Know Your Customer (KYC) compliance has historically been a bank concern. For ISVs distributing payments to merchants, it has become an ISV concern.

The regulatory shift is straightforward. When an ISV brings merchants onto a payment platform, the ISV is part of the distribution chain. Regulators expect that chain to verify merchant identity, monitor for suspicious activity, and report when patterns suggest illicit use.

The practical implementation has four parts.

Know Your Customer (KYC) covers identity verification for individual cardholders and merchant principals. Government ID matching, sanctions screening, and address verification establish that the person opening an account is who they claim to be.

Know Your Business (KYB) is business-level verification of the merchant entity itself. It includes tax ID validation, business registration, ownership disclosure, and beneficial ownership tracking.

Ongoing monitoring covers periodic re-verification, transaction-pattern monitoring for suspicious activity, and sanctions list updates over the life of the merchant relationship.

Suspicious Activity Reporting (SAR) is the documented process for flagging and reporting transactions that suggest money laundering, terrorism financing, or other illicit use to the relevant regulator.

Most ISVs underestimate how much of this they are responsible for. The payment platform handles the underlying compliance. The ISV is responsible for not undermining it through how merchants are onboarded and how the platform is used.

CSIPay handles the platform-side complexity: identity verification, AML screening, ongoing monitoring, sanctions list updates. The ISV remains responsible for using the platform consistent with its compliance design.

Fraud prevention: the structural defenses

Fraud prevention is not a feature. It is a set of structural defenses layered into the payment architecture. Three layers matter most for ISVs.

Pre-authorization fraud screening. Transactions are scored against a risk model before authorization is sent to the issuer. High-risk transactions can be challenged, denied, or routed to additional verification.

3DS authentication. As described above, this shifts liability and adds a verification layer for high-risk transactions.

Velocity and pattern monitoring. Continuous monitoring catches patterns that emerge over time: a single card used across multiple merchants in unusual sequences, sudden spikes in transaction volume, geographic anomalies.

The structural choice for ISVs is to pick a payment platform whose fraud prevention runs in real time, learns from your merchant base, and exposes the controls you need to tune the model to your specific risk profile.

The ISV-specific threat surface

ISVs face a different threat surface than direct merchants. Three things are unique.

The first is merchant onboarding fraud. Synthetic businesses apply to use your platform, and stolen identities are used to open merchant accounts. The fraud happens before any transactions are processed, which means the defense has to live in the onboarding flow itself. Strong KYB and AI underwriting are how that gets handled.

The second is account takeover at the merchant level. A legitimate merchant’s account is compromised and used to process fraudulent transactions, withdraw funds, or change settlement banking. Strong authentication, change-control workflows, and anomaly monitoring are the layered defense.

The third is card-not-present exposure across the merchant base. Most ISV merchants are CNP-heavy, and CNP fraud represents 68 percent of gross fraud losses in payments. The defense is layered across tokenization, network tokens, 3DS, and AI fraud detection working together.

A complete framework addresses all three. Generic payment platforms address the first two as basic capabilities. The third requires the kind of depth horizontal processors rarely build.

What to look for in a payment provider

When evaluating a payment platform from a security and compliance perspective, look for evidence in seven areas.

PCI DSS Level 1 certification under the current version (4.0.1). Ask for the Attestation of Compliance.

Documented encryption architecture. End-to-end encryption at point of capture. AES-256 at rest. TLS 1.2 or higher in transit.

Network token support. Either live or on the near-term roadmap. Network tokens are becoming standard, and a payment platform without them will fall behind on both security and acceptance rates.

AI-driven fraud detection. Not rule-based fraud screening alone. Real-time risk scoring with model-based decisioning.

3DS2 support. Standard for ecommerce. Required for high-CNP verticals.

KYC and KYB processes documented and operational. Not just ‘we have it.’ Specific evidence: identity verification flow, sanctions screening cadence, KYB depth.

99.9 percent uptime SLA or better. Documented incident response. Clear breach communication protocol.

The CSIPay security framework

CSIPay’s security framework is built around the seven layers above. It is designed for the operating realities of vertical SaaS companies in the Constellation Software ecosystem, not adapted from a horizontal platform that serves everyone.

On certification, CSIPay is PCI DSS Level 1 v4.0.1 certified, audited annually, with documentation available to partners on request.

On the encryption and tokenization layers, the platform applies end-to-end encryption from point of capture, AES-256 encryption at rest, and TLS 1.2 or higher in transit. Every card stored is tokenized rather than held as primary account data, and network token processing is part of the interchange optimization rollout in the launch wave.

For fraud prevention, the AI Fraud and Risk Model runs in real time with continuous learning across the partner base. 3DS2 support is built into ecommerce flows, with liability shift available for partner-enabled transactions.

For onboarding and AML, KYC and KYB processes are integrated with AI-driven merchant onboarding. Identity verification, sanctions screening, business registration validation, and beneficial ownership tracking run on every new merchant, and AML monitoring continues across the merchant relationship rather than ending at activation.

For access controls, multi-factor authentication is required for all admin access. Role-based access control, full audit logging, and configurable session timeouts are standard. IP allowlisting is available for partners that need it.

For operations and reliability, CSIPay maintains a 99.9 percent uptime SLA. Incident response is documented, with defined breach notification timelines and partner communication procedures that mean partners hear about issues immediately, not days later.

The framework is documented, audited, and built for vertical SaaS distribution. The broader product capability set is covered in our CSIPay launch blog.

Choosing a payment platform is a security decision

Security and compliance are architectural decisions, not feature lists. The framework you adopt today shapes your liability, your merchant trust, and your operational complexity for years.

For ISVs operating in the Constellation Software ecosystem, the right choice is the one designed for that operating reality. CSIPay’s security framework is built around the seven layers above, certified at the highest tier, and designed specifically for vertical SaaS distribution.

Review the CSIPay security framework. Reach out to your CSIPay representative or contact us at [email protected].